Bug 16035 - Incorrect initial resolution of (external) vga monitor with KMS
Summary: Incorrect initial resolution of (external) vga monitor with KMS
Status: CLOSED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri-intel@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks: 15310
  Show dependency tree
 
Reported: 2010-05-23 12:28 UTC by Andreas Eckstein
Modified: 2010-08-03 12:25 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.34
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
dmesg output for 2.6.33 (15.27 KB, text/plain)
2010-07-23 22:41 UTC, Andreas Eckstein
Details
dmesg output for 2.6.35-rc6 (15.35 KB, text/plain)
2010-07-23 22:42 UTC, Andreas Eckstein
Details

Description Andreas Eckstein 2010-05-23 12:28:49 UTC
Thinkpad T43, i915 graphics

Kernel 2.6.34
Xorg-server 1.8.1
xf86-video-intel 2.11.0

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).
Comment 1 Andreas Eckstein 2010-06-13 19:57:58 UTC
Still occurs as of kernel 2.6.35-rc3, please don't invalidate.
Comment 2 Rafael J. Wysocki 2010-06-13 23:26:20 UTC
I won't, but please don't change the kernel version.  It should be the one
the bug first appeared in.
Comment 3 Andreas Eckstein 2010-07-06 11:49:12 UTC
Bug still present as of 2.6.35-rc4
Comment 4 Jesse Barnes 2010-07-23 20:20:37 UTC
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.
Comment 5 Andreas Eckstein 2010-07-23 22:41:36 UTC
Created attachment 27233 [details]
dmesg output for 2.6.33
Comment 6 Andreas Eckstein 2010-07-23 22:42:49 UTC
Created attachment 27234 [details]
dmesg output for 2.6.35-rc6
Comment 7 Jesse Barnes 2010-07-23 22:51:05 UTC
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.
Comment 8 Chris Wilson 2010-07-23 22:57:30 UTC
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 ;-]
Comment 9 Jesse Barnes 2010-07-23 23:07:07 UTC
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.
Comment 10 Andreas Eckstein 2010-07-24 11:24:47 UTC
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.
Comment 11 Florian Mickler 2010-07-24 12:53:19 UTC
I guess it is possible to manually configure the kernel to only display on the external monitor?
Comment 12 Andreas Eckstein 2010-07-24 13:17:22 UTC
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.
Comment 13 Florian Mickler 2010-07-24 13:33:55 UTC
Indeed, that seems like a sensible approach. What happens on .33 when you open the lid?

(Why was this closed as "code fix"?)
Comment 14 Andreas Eckstein 2010-07-24 14:22:25 UTC
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.
Comment 15 Jesse Barnes 2010-07-24 14:54:11 UTC
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.
Comment 16 Andreas Eckstein 2010-08-02 14:18:43 UTC
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?
Comment 17 Florian Mickler 2010-08-02 15:00:28 UTC
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  ?
Comment 18 Andreas Eckstein 2010-08-03 10:49:34 UTC
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.
Comment 19 Florian Mickler 2010-08-03 12:25:06 UTC
So you need a commandline-option to use the crtc with the largest resolution instead of trying to clone across all available crtcs...

hm..

Note You need to log in before you can comment on or make changes to this bug.