[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Upgrade Kernel, Lose External Display

On 06/12/2010 01:42 PM, Sven Joachim wrote:
On 2010-06-12 15:38 +0200, Gilbert Sullivan wrote:

On 06/12/2010 04:03 AM, Sven Joachim wrote:

Thanks.  I don't see anything unusual in it, in particular nouveau
detects the 1680x1050 resolution of the external display:

[    7.308183] [drm] nouveau 0000:01:00.0: allocated 1680x1050 fb: 0x49000, bo f6feb600
[    7.319925] [drm] nouveau 0000:01:00.0: Output DVI-D-1 is running on CRTC 0 using output A
[    7.319929] [drm] nouveau 0000:01:00.0: Setting dpms mode 0 on tmds encoder (output 2)
[    7.319931] [drm] nouveau 0000:01:00.0: Output DVI-D-1 is running on CRTC 0 using output A
[    7.321231] Console: switching to colour frame buffer device 210x65

Yes, I saw that and wondered why, if it's detecting the resolution
properly, it isn't working. I guess the new frame buffer must be
incompatible with the card's driver.

Nouveau _is_ the card's driver.  Or are you talking about X.Org?

I tried this:

$ grep -B2 'Module class: X.Org Video Driver' /var/log/Xorg.0.log

(II) Module nv: vendor="X.Org Foundation"
	compiled for 1.7.7, module version = 2.1.17
	Module class: X.Org Video Driver
(II) Module vesa: vendor="X.Org Foundation"
	compiled for 1.7.7, module version = 2.3.0
	Module class: X.Org Video Driver

I'm not sure I understand what's going on here. Does that say I'm
using nv or vesa now?

Both will not work correctly, and the newest versions of these drivers
will refuse to load if nouveau is present.  You need to install
xserver-xorg-video-nouveau or xserver-xorg-video-fbdev, those are the
only X drivers that work with the nouveau kernel module.

I have both xserver-xorg-video-nouveau and xser-xorg-video-fbdev installed (just confirmed it in aptitude), but it doesn't appear that they are being used.

I did try using the 4-line minimal xorg.conf file suggested at the nouveau.freedesktop.org location to force nouveau to be used. When I booted I got a blue text-graphics screen which said that X had failed to start and which asked if I wanted to view the log (with a choice of yes / no). However, I didn't get a chance to answer because I was then unceremoniously dumped at the console logon prompt. I logged on as root and removed the 4-line file, and then everything was as it had been before.

I would trying turning KMS off just to see if I could learn anything, but I haven't yet found out how to do it with a grub 2 system.

Whichever one I'm using doesn't seem to like the change.

Does X even start?  I suppose it doesn't if you only have the nv and
vesa drivers.

X apparently *always* starts (except for the one time when I tried to specify use of nouveau in /etc/X11/xorg.conf). I'm showing the nv and vesa drivers in the log in both situations (docked and undocked, new kernel and old kernel). When I'm undocked and using the 1920x1200 display I can boot with the new kernel and everything works perfectly. When I'm docked, booting the new kernel, and using the 1680x1050 display all I get after the waiting for /dev to be populated message is a black screen (on the external display).

I just tried lifting the lid of the notebook while it was docked (hard to do because of the physical location of the port replicator) and saw that it, too, was black. When I lifted it further I saw the backlight come on, but no information was being displayed on the screen. I tried using the keyboard toggle to force the external screen to be used, but nothing happened.

I logged on to the notebook remotely again and was able to launch graphical applications on the system in the ssh -X session.

It looks to me as though X is always loaded, but that something about the new KMS (or whatever it is) doesn't like my docked hardware configuration and won't allow output to any screen when the system is docked. (I may be guilty of assuming more than I should, but I'll admit I'm pretty ignorant of the way all of this stuff works these days.)

I'm looking at the link you gave me to see if I can file a meaningful bug report, but so much of the documentation there concerns the process of getting nouveau to work at a time before all of the new packages were released that I'm not sure I know how to proceed without merely making a pest of myself.

In the meantime, I boot with the old kernel when docked and the new kernel when undocked, and the system behaves perfectly. I'll keep chipping away at it in the hope of learning something useful or posting a reasonably meaningful bug report.

If you have any suggestions regarding testing that I might do I'm willing to give it a shot. I'm wondering what would happen if I performed a fresh installation of Squeeze on the system. But I would *much* rather learn why it's behaving the way it is. I should point out that I have never used proprietary nvidia drivers on this system since the beginning of this netinst of Squeeze. And, as far as I knew, I was using the vesa drivers only. I would swear that the appearance of nv in that log has to be very recent.

Thank you again, Sven.

Reply to: