VesaDriverTesting

Mike Harris has asked for testing of the Vesa video driver, which could be used for a "safe mode" in Fedora. The problem is that many BIOS's Vesa modes are broken, so he needs a good blacklist of broken situations with the Vesa driver. See his comments about this from IRC here:

<mharris> Basically, each video BIOS is in total 100% control over what video modes are available, and what
colour depths.
<mharris> You can't change refresh rate unless it is at least VBE 3.0
<mharris> One needs to look at the X logfile, to see what video modes the BIOS supports in what depths,
then test each one.
<mharris> A simple start of the X server, and fire up an app or two with no on screen corruption or crash
is a good enough quick test IMHO
<mharris> I just scribbled them here ;o)
<mharris> Then, for any failures, we need a bug report, with config file, log file, full details, and lspci
-vvn
<mharris> naw, just cut and paste what I said into the wiki ;o)
<mharris> The testing is specifically to test:
1) video driver/X server stability
2) Screen corruption/splitting/misalignment/similar
3) mouse pointer corruption/misalignment
<mharris> No X server crash, no screen corruption/misalignment, no mouse problems == WORKS
<mharris> startx, open an xterm if any commands need to be executed, run an app, move it around the screen,
fiddle. Don't do_work, fiddle.

Example Vesa Test

This example will follow the steps i did to test vesa driver functionality for my Geforce 2 Ti video card. Please read of the instructions all the way through before starting the vesa driver test. Please also backup your /etc/X11/XF86config file so you can restore it to its pre-testing state. 'cp /etc/X11/XF86config /etc/X11/XF86config.DATE'

1. Preparing for the test.

First attempt to query bugzilla.redhat.com for existing bug reports for your video hardware.
You might consider creating a test user on your system to do the following tests, as an extra precaution against accidently affecting your normal user settings.
The vesa testing is meant to do these things:
video driver/X server stability
Screen corruption/splitting/misalignment/similar
mouse pointer corruption/misalignment
No X server crash, no screen corruption/misalignment, no mouse problems == WORKS

mharris:
"In particular, it would be nice for users to test every video mode and color depth
combination that their video card supports in it's BIOS. These can be shown in the
X log file after starting up the server. It will require some minimal reconfiguration
either by hand editing the config file or using our redhat-config-xfree86 config tool
(system-config-xfree86 in rawhide). If someone doesn't have the time to test all of
that, or for some other reason can not test it all, such as hrdware limitations, what
would be nice, would be if they could at least test 640x480, 800x600, 1024x768
resolutions using color depth 24, 16, and optionally 8. That would provide the minimal
amount of testing for me to have a "safe mode" video driver matrix I believe."

Vesa is an unaccelerated driver. If your normal desktop settings and applications take advantage of video hardware acceleration, you are advised to setup an alternative default environment before starting testing. Do NOT test for 3D support as part of vesa.
Note that at low resolutions gnome and kde desktop functionality might be very limited. For example a panel object full of applets might no longer fit on screen. If you are going to test your typical desktop environment. Please be aware that loss of functionality can be expected during the test. Please don't confuse application level issues with video driver issues.
Note that laptop users and LCD/DFP users in general might have specific problems. If their BIOS does not have a built in video mode for their LCD/DFP native resolution, they'll either get a scaled ugly display, or a centered small display with black banding around it. Be aware to expect these potential problems, and please report if you see them.
Enter runlevel 3, if you are in X you will need to issue the following commands appearing in quotes, inside a terminal window.
'su -' and then enter root password when requested -> gain root login shell access in the terminal
'init 3' -> drop out of X to network enabled console mode
login as test user at the console login prompt
Now reconfigure the X server to use the vesa driver in 24bit colordepth.
'su -' and enter root password when requested -> obtain root login shell access
'redhat-config-xfree86 --set-driver=vesa' -> this should reconfigure X to use vesa
'redhat-config-xfree86 --set-depth=24' -> this should reconfigure X to use 24bit depth
'exit' -> leave root login shell and revert to test user login shell
Run first attempt at vesa X session
'startx' -> start X session

More importantly an X server log is generated with vesa driver information 3.1) if you entered X

try to open a terminal move it around, open up applications and fiddle with them looking for X stability, video artifacts or mouse corruption. Please note that application level issue like windows being too large for a small display are not relevant for the testing of the video driver.
exit the desktop session
if you can NOT enter a desktop session please make a note so you can record this in a bugzilla ticket. You might want to try another desktop session using the 'switchdesk' utility and try to continue the testing of this mode.
Examine the X server log (/var/log/XFree86.0.log) for supported vesa modes that need testing for the colordepth you are in.
note which colordepth you are in.

example->(**) VESA(0): Depth 24

note which resolutions are listed as supported

example->

(II) VESA(0): Supported VESA Video Modes:
(II) VESA(0): 720x400@70Hz
(II) VESA(0): 640x480@60Hz
(II) VESA(0): 800x600@60Hz
(II) VESA(0): 1024x768@60Hz
(II) VESA(0): 1024x768@75Hz
(II) VESA(0): 1280x1024@75Hz

note the built-in modes

example->

(**) VESA(0): *Built-in mode "800x600"
(**) VESA(0): *Built-in mode "640x480"
(**) VESA(0):  Built-in mode "640x400"

Select a specific resolution listed as supported for testing.
'su -' and enter root password -> enter root shell
'redhat-config-xfree86 --set-resolution=WxH' -> select a specific mode to test

example -> 'redhat-config-xfree86 --set-resolution=640x480' to test 640x480 resolution

'exit' -> leave root shell
Test Specific resolution
'startx' -> to enter X session
start an xterminal
in xterm use the command 'xwininfo' and click on desktop away from the xterm window. This should give you information about the resolution being used.
geometry WxH should match the WxH resolution you selected in step 8. You can also check the geometry being used by the X server by checking the X log again, which gets rewritten on each Xserver startup.
make a note if startx fails to give you a twm session or if the geometry reported by xwininfo/X log is different than the one you requested in step 8
repeat step 7 and 8 for all resolutions listed in step 6 as being supported. Make notes about any resolutions that don't appear to be available..or resolutions that have obvious video problems.
Change bitdepth from 24 to 16.
'su -' enter root password -> gain root shell
'redhat-config-xfree86 --set-depth=16'
'exit' -> leave root shell
follow steps 5 through 9 for the 16bit and then the 8bit colordepth.
Reset your Xconfig to its default state and enter runlevel 5
'su -' enter root password -> gain root shell
'cp /etc/X11/XF86config.DATE /etc/X11/XF86config'
'init 5' -> restart normal X services
'ALT-CTL-F1' -> enter vt1
'exit' -> leave root shell
'exit' -> logout test user
'ALT-CTR-F7' -> return to normal gdm/kdm login prompt
Gather your notes and prepare to file a bugreport about your hardware. If a testing report is already on file for your video hardware, please review the already existing reports and add comments to the existing reports if your testing differs for the same hardware. Please file new bug reports only if a relevant report is not already open. Please when making notes about which modes have failed it is important that you save the X server log and the X server config file so they can be attached to the bug report. An X log and config file for each 'failed' mode tested is a good idea
a shot of tequila
another shot of tequila

Filing a bug report for hardware

Please first see if your hardware has been reported on already. Report back with additional information on already open test reports for the same hardware if possible.
When filing a new report please also use this Summary string when filing a bug

Vesa Failure Report: <VIDEO CARD HARDWARE VERSION>
Replace <VIDEO CARD HARDWARE VERSION> with the id string reported by 'lspci' command.
example->Vesa Failure Report: nVidia Corporation NV15DDR [GeForce2 Ti]  (rev a4)

Header field values: product: Red Hat Rawhide version: 1.0 component: XFree86
Give as much detail as you can in the description. If multiple modes have problems, please detail all of them in the description field.

Please note that the problems of interest in this test are limited to whether or not the
vesa video driver is working and gives you an X environment for the mode you request. Testing
at lower resolutions or with the vesa driver, might expose bugs in specific applications that
you try to run. Please do not file reports about issues running specific applications.  Please
also note that the initial point of this testing is not to fix hardware issues, but to create
a list of known broken hardware as part of an experimental 'safe mode' for graphical login.

Attach the output of the 'lspci -vvn' command.
Attach for each problematic mode
X config file (/etc/X11/XF86config)
X log file (/var/log/XFree86.0.log)
When filing a bug please set the tracking bug as a blocker for the bug you file. That way all relevant bugreports will show up in the dependency list for this tracking bug report. This will greatly help make sure your bugreport on this testing issue is not lost in the vast sea of bugreports. If you do not set the tracker to block, your report might not be seen by the developer who needs this information.

Search

Extras/VesaDriverTesting

VesaDriverTesting

Example Vesa Test

Filing a bug report for hardware