Bug 16035
| Summary: | Incorrect initial resolution of (external) vga monitor with KMS | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Andreas Eckstein (andreas.eckstein) |
| Component: | Video(DRI - Intel) | Assignee: | drivers_video-dri-intel (drivers_video-dri-intel) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | chris, florian, jbarnes, rjw |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.34 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 15310 | ||
| Attachments: |
dmesg output for 2.6.33
dmesg output for 2.6.35-rc6 |
||
|
Description
Andreas Eckstein
2010-05-23 12:28:49 UTC
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... hm.. |