Bug#673496: X problems

[Paul Zimmerman <aiwanar@yahoo.com>]

Sorry I didn't save the Xorg.0.log in time from that boot of the 3.2 kernel. It might have 

been very informative.


This machine has many problems with the X system. First it apparently does not 

report  accurate screen size because the initial boot of both Lenny and Squeeze 

had a huge over-sized screen and I had to figure out how to get into a terminal 

window and edit xorg.conf to force a correct desktop size. This was done with a 

virtual screen.

Section "Screen"
    Identifier    "Default Screen"
    Monitor        "Configured Monitor"
    DefaultDepth    16
    SubSection "Display"
            Depth   16
        Virtual    1280 800
    EndSubSection
EndSection


That part at least works in both Lenny and Squeeze. I had thought that the same 

xorg.conf which worked in Lenny would work in Squeeze, but it didn't. And this is 

where things gets really weird. When I initially installed Squeeze on this laptop 

and copied the xorg.conf from the Lenny install there was a problem with the 

touchpad. X would refuse to load, dumping back to the shell prompt. Looking at  

the log, it was having an error from not being able to find the right driver for the 

Glidepoint touchpad. This makes zero sense, but that's what it was saying. Lenny 

also complained of the touchpad but loaded anyway, using some sort of  "guess"
method to use it even though it couldn't find the right driver. (The touchpad does 

work, btw.) In Squeeze it would halt on this error. After long, tedious trial and error 

I figured out the changes to make it load. It turned out to be the option to use BIOS 

to save and restore the VESA modes. Again, this makes no sense, but I don't 

know the inner workings of the Open Chrome driver.

This worked in Lenny:
Section "Device"
    Identifier    "Configured Video Device"
    Option         "SWcursor"
    Option        "EnableAGPDMA"
    Option        "VBEModes"
    Option        "VBESaveRestore"
EndSection


The SWCursor was necessary in Lenny but not in Squeeze. Apparently they figured
out how to activate the hardware cursor in later revisions of OpenChrome. So I could
drop that for Squeeze. But this is the weird, weird thing. "VBESaveRestore" is what 

causes X to barf on the Glidepoint touchpad. Remove that and X will load, 

though still complaining like it did in Lenny. Fortunately that doesn't seem to be a 

problem. If I used the OpenChrome driver without the other option, "VBEModes", 

there would be a serious problem. Running the OpenChrome driver on this machine 

without that option causes hard lockups when you try to exit the desktop. So 

something to do with resetting from graphical mode to text mode directly instead of 

using the BIOS causes a hard lock. (Constant hard locks in the video drivers is what
makes Windows completely unusable on this machine...)


These weird behaviors make it look like internal tests are being updated and made 

stricter in progressing versions of OpenChrome and making the driver fussier. And it 

seems likely that some sort of conflict occurs between OpenChrome and the 3.2 kernel 

that causes the hang when I try to load it. So I cannot yet say if the ath5k driver in that
kernel works on this machine.