Kernel Bug Tracker – Bug 16035
Incorrect initial resolution of (external) vga monitor with KMS
Last modified: 2010-08-03 12:25:06 UTC
Thinkpad T43, i915 graphics
Initial console after booting has the resolution of the laptop's display at 1024x768 instead of the monitor's 1680x1050, using the top left corner of the screen. When X starts, it uses a scaled-up 1024x768 resolution. I saw this behavior when KMS became part of the kernel (2.6.29 I think) but it was fixed a few versions later (perhaps 2.6.31).
Still occurs as of kernel 2.6.35-rc3, please don't invalidate.
I won't, but please don't change the kernel version. It should be the one
the bug first appeared in.
Bug still present as of 2.6.35-rc4
Can you attach the dmesg output with drm debug=4? Maybe we're misdetecting a mode somewhere, or possibly the drm_fb_helper code is picking the wrong config.
Created attachment 27233 [details]
dmesg output for 2.6.33
Created attachment 27234 [details]
dmesg output for 2.6.35-rc6
In your 2.6.33 log it shows the LVDS output as disconnected, do you get a display on it at all?
It looks like the current code tries to find the smallest native mode and use that everywhere, so this may be intended behavior and not really a bug in current code.
Isn't the intended behaviour to clone the fbcon across all outputs? The regression appears to have been in 2.6.33 which was misdetecting your SDVO LVDS panel as a TV and the current behaviour correct.
[At least I think that is the case ;-]
Yes, it should be cloning. I didn't notice the SDVO bug, there's definitely an SVIDEO device getting detected in the .33 case vs an LVDS in the .34 case though, so yes this is probably intended behavior you're seeing.
In both cases, the external monitor is connected via VGA to my laptop, and the lid is closed, so that LVDS is disconnected in .33 seems sensible to me.
I guess it is possible to manually configure the kernel to only display on the external monitor?
It probably is, but why would I want that? I think the .33 behavior is as it should be: If the lid is closed, use external monitor resolution, if it is open, use LVDS resolution.
Indeed, that seems like a sensible approach. What happens on .33 when you open the lid?
(Why was this closed as "code fix"?)
If I open the lid, the laptop screen just stays off. But I daresay one could program different behavior with a little acpid+xrandr magic, so that's OK as far as I'm concerned.
We no longer use lid state for LVDS detection, it was too unreliable. So now you'll have to disable it manually when you close the lid if you want different behavior.
Well this sucks. To work around this at startup, I'd need a tool to trigger a mode change _before_ X starts up, so xrandr is right out. Is there such a tool? Can I do this via sysfs somehow? Or alternatively, if someone (i. e. me) was to write a patch to change the priority display device (LVDS/VGA/DVI/...) to determine initial resolution via kernel parameter, would that patch stand a chance of being accepted?
There is a magic kernel cmdline that let's you force a mode..
i think it is video=* ... ah yes just googled it:
http://nouveau.freedesktop.org/wiki/KernelModeSetting (the part about "Forcing Modes" applies to all kms drivers)
perhaps something along the lines: video=LVDS-1:d ?
But forcing a mode would take away flexibility. I'm using my laptop in two locations, with monitors that have different resolutions, and sometimes I use it stand-alone with the internal display. I'm aiming for a solution that gives me the best available resolution on my screen automatically.
So you need a commandline-option to use the crtc with the largest resolution instead of trying to clone across all available crtcs...