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. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1337467181.77226.yahoomail...@web162603.mail.bf1.yahoo.com
