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.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c13dab8.3040...@comcast.net