[TESTING REQUEST] Xorg in -current (yes, again)

grissiom · 07-29-2009, 10:07 AM

Quote:

Originally Posted by rworkman

How did you check it?

Running "groups" from a terminal is not sufficient - you need to check the /etc/group file instead.

Oh? Really? Why "groups" is not sufficient?
(Sorry to hijack the thread...)

rworkman · 07-29-2009, 10:12 AM

Quote:

Originally Posted by grissiom

Oh? Really? Why "groups" is not sufficient?
(Sorry to hijack the thread...)

If you boot to runlevel 3, your user account gets added to four groups automatically:

Code:

liberty $ grep CONSOLE_GROUPS /etc/login.defs
CONSOLE_GROUPS          floppy:audio:cdrom:video

The output of "groups" will reflect that as well.

When you boot to runlevel 4 (to log in via kdm/gdm/whatever), then your user account is *not* added to any groups automatically, so if you don't have your user explicitly added to a group in /etc/group, then you won't be in that group.

eviljames · 07-29-2009, 11:39 AM

ACK! My original reply appears to have been flushed down the intert00bz. Here goes... I did a bunch of different tests, I recognize that the numbers may not be reflective to benchmark between users, but I figured grabbing some metrics on the same hardware might be useful.

Hardwares:
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) [laptop]
00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 10) [desktop]

Results are pretty much consistent on both - the numbers were a little different, but within a deviation of around 5-8%.

Stock -current up to date as of yesterday:
EXA works ok, comes up by default with no xorg.conf, and desktop effects can be enabled, using the KDE "Show FPS" monitor under compositing shows around 60 fps. When moving a wobby, semi-transparent window that drops to around 23 and becomes choppy and jagged in the motions. glxgears output is sort of scrambled, but for the most part invisible and just shows a black flickering box on the screen, it shows an output of exactly 29.97 fps.

UXA works if enabled in xorg.conf, desktop effects do not work at all under KDE4. glxgears output is very scrambled but exists and claims around 800 fps. Logging out caused a hard UI lockup, Magic SysRq key could not be used, Xorg would not die even when killed from ssh session seemed that reboot was required.

Same setup, except with Robby's packages EXCLUDING intel-2.8
EXA works and comes up by default with no xorg.conf, enabling desktop effects works, again appears to run around 60 fps, moving the wobbly window around it appears to drop to around 45 fps - this pretty much resolves the jagged motion experienced before. glxgears output flickers badly, claims to produce around 75 fps.

UXA works when enabled in xorg.conf and works well, shows exactly 100 fps which appears to be the maximum that the KDE meter will show. Drops to exactly 60 fps when moving wobbly windows. glxgears output is normal and claims around 150 fps.

Same setup, with Robby's packages INCLUDING intel-2.8
UXA comes up by default with no xorg.conf, and works very well. Compositing fps chart again is topped out at 100 fps, drops to exactly 60 when moving transparent wobbly windows. glxgears output is as it should be, no flickering and claims to produce around 600 fps.
EXA, of course, has been removed.

Hope this helps.

andersjjesnsen · 07-29-2009, 04:28 PM

01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01)

Everything seems to work exactly the same in both test cases. Composite works, and is enabled in KDE by default, but it is dreadfully slow on this 1.6GHz P4. Glxgears shows roughly the same output in both cases.

I am not using an xorg.conf, stock huge-smp, stock everything else put the packages in question.

/macavity

andersjjesnsen · 07-29-2009, 05:41 PM

01:00.0 VGA compatible controller: ATI Technologies Inc RV710 [Radeon HD 4350]

This one does not work neither before nor after this stuff.. it just falls back to swrast, so no DRI, no composite and glxgears around 115fps on a 3.2GHz P4 Prescott with HT...

/macavity

andersjjesnsen · 07-29-2009, 06:55 PM

00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL Integrated Graphics Controller (rev 04)

This one works 100% as advertised on both stock and testing packages. No xorg.conf in either case. 60fps flat in both cases.

Update: for those who care: xf86-video-intel-2.8.0 works *very* nicely with this one! +350fps and exceptionally smooth composite - WTG! :P
I suspect the above would work just as nice if I enabled UXA, but i have more cards to test, so I don't have time right now.

/macavity

andersjjesnsen · 07-29-2009, 07:28 PM

01:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)]

This one also works in both configs.. though slightly faster with rworkman's version. Composite is smooth enough in stock -current, but very fast with Mesa-7.5. About 1575fps on stock config, and about 1640 on test config.

Observe: I have only tested with glxgears and KDE effects on all of the above.. i don't have too much time, and a laundry list of cards/chips to try, so if you would like additional info, or testing with other apps, feel free to ask or post URLs to ready made i486 packages.

/macavity

niels.horn · 07-29-2009, 08:04 PM

I have one additional question...
What would be a better program to test drivers / graphics cards?

I know glxgears is not the best benchmarking tool, but is there anything better available?
Or should we use Extreme Tuxracer?

TSquaredF · 07-29-2009, 09:13 PM

I had a problem with these packages on my Toshiba laptop, Satellite P305D,

Code:

# lspci
01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200
Series]

when using VirtualBox, PUEL edition, v. 3.0.2. When I start a VM, the screen colors go to solid red, green & black. Clicking outside the VM window restores the proper colors, but clicking inside the box starts the process again. Going back to the stock packages makes all work properly. I am using the radeonhd driver. My xorg..conf is only:

Code:

# cat /etc/X11/xorg.conf
Section "Device"
        Identifier  "Card0"
        Driver      "radeonhd"
        VendorName  "ATI"
        BoardName   "Radeon X1200"
        BusID       "PCI:1:5:0"
EndSection

Regards,
Bill

grissiom · 07-29-2009, 09:37 PM

Quote:

Originally Posted by TSquaredF

I had a problem with these packages on my Toshiba laptop, Satellite P305D,

Code:

# lspci
01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200
Series]

when using VirtualBox, PUEL edition, v. 3.0.2. When I start a VM, the screen colors go to solid red, green & black. Clicking outside the VM window restores the proper colors, but clicking inside the box starts the process again. Going back to the stock packages makes all work properly. I am using the radeonhd driver. My xorg..conf is only:

Code:

# cat /etc/X11/xorg.conf
Section "Device"
        Identifier  "Card0"
        Driver      "radeonhd"
        VendorName  "ATI"
        BoardName   "Radeon X1200"
        BusID       "PCI:1:5:0"
EndSection

Regards,
Bill

I have had this problem before(without rworkman's testing packages). The only solution I tried out is run your vm in this way:

Code:

VirtualBox --startvm "your_vm_name" -rmode sdl

Then your vm will startup in a window.

ack_iix · 07-29-2009, 09:51 PM

Quote:

Originally Posted by rworkman

How did you check it?

Running "groups" from a terminal is not sufficient - you need to check the /etc/group file instead.

Part of my /etc/group file:

Code:

audio:x:17:root,kitty
video:x:18:root,kitty
cdrom:x:19:root,kitty

Yesterday I tried the new xorg on EEETop machine (intel 945 graphics) installed with slackware-current and compositing works fine. If it works in Intel or ATi graphics, maybe there's bug in current NVIDIA driver.

Thanks.

rworkman · 07-29-2009, 10:29 PM

Quote:

Originally Posted by TSquaredF

I had a problem with these packages on my Toshiba laptop, Satellite P305D,

Code:

# lspci
01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200
Series]

when using VirtualBox, PUEL edition, v. 3.0.2. When I start a VM, the screen colors go to solid red, green & black. Clicking outside the VM window restores the proper colors, but clicking inside the box starts the process again. Going back to the stock packages makes all work properly. I am using the radeonhd driver. My xorg..conf is only:

Code:

# cat /etc/X11/xorg.conf
Section "Device"
        Identifier  "Card0"
        Driver      "radeonhd"
        VendorName  "ATI"
        BoardName   "Radeon X1200"
        BusID       "PCI:1:5:0"
EndSection

Ooh, confirmed here on my radeonhd. Apparently the radeonhd driver has some issues with the new xorg-server, based on this and some other feedback with that driver.

For what it's worth, disabling the composite extension is a good workaround (you lose kde effects though, if that's important to you):

Code:

Section "Extensions"
  Option "Composite" "Disable"
EndSection

ponce · 07-29-2009, 11:27 PM

I don't remember where I found this solution (maybe vb's forums), but I was having similar problems with radeon driver and virtualbox video output for vms and I solved disabling composite only for virtualbox on a bash script before launching:

Quote:

cd /opt/VirtualBox
export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
export XLIB_SKIP_ARGB_VISUALS=1
./VirtualBox

cannot try it on radeonhd driver because it doesn't recognize the connector of the radeon hd 3450 I got at work.

TSquaredF · 07-30-2009, 02:26 PM

grissiom:
I had video problems in the VB window, which I got solved in this thread. The problem I had with the testing packages was with the entire screen, & Robbie's workaround in post 72 was the cure.
rworkman:
Thanks for the workaround. All is working fine now, as I don't care a whit about KDE desktop effects. I have installed it on this laptop, but think I prefer XFCE.
Regards,
Bill

grissiom · 07-30-2009, 08:04 PM

Quote:

Originally Posted by TSquaredF

grissiom:
I had video problems in the VB window, which I got solved in this thread. The problem I had with the testing packages was with the entire screen, & Robbie's workaround in post 72 was the cure.

Ah, sorry, I thought the "screen" you referred to was the vm screen

...