Created attachment 304227 [details, diff] reverts the i915 disable-opregion-lid-detection.patch Most of the time, my notebook rests on one of two docking station working places both attached to a bigger external display and complete with desktop periphery. Unfortunately, Linux spoiled the fun beginning with 2.6.33 which is why I am patching every kernel ever since. The Lenovo X200s has a GMA4500(MHD) chip. Basically, those are my two configs: 1.) X200s @ Ultrabase [DP] -> [DP] Monitor (1920x1200) 2.) X200s @ Ultrabase [DP] -> [DP]->[DVI-D] -> [DVI-D] Monitor (1920x1200) 1 & 2: Resolution of the ext. display is always set to that of the LVDS screen (1440x900) only 2: External display detection doesn't work at all (only at POST time) I was using a different (probably not ideal) patch all the time, but today I was motivated enough and found a better solution that fixes both I will attach here. Upstream doesn't care too much, either because there aren't enough docking station users, or because of the sorry state in which most vendors ship their BIOS with. Nevertheless it is a really annoying problem when you are used to the fine automagic of KMS. The ideal solution would probably be to pack it into some CONFIG_KMS option to be switched on by users with proper ACPI support.
Please do not CC: maintainers yourself unless you have been explicitly requested to.
Sorry about that, won't happen again. There's been some activity in the linked kernel bug, and while the problem isn't solved, there exists a workaround without the need for a patch on affected systems: i915.panel_ignore_lid=-1 added to the kernel command line. More testing will be needed, but resolution is now correct in case 2.)
As a workaround has been identified, closing.
Updating to "resolved upstream" because of recent developments: https://bugzilla.kernel.org/show_bug.cgi?id=27622#c29 With the new patch there's now a real solution at hand for people who can trust their lid detection magic, in contrast to comment #2 which simply disabled any LVDS activity. Which meant having to keep two separate boot entries - I never really did that. The upstream patch can be backported to older kernels. Maybe that helps someone else who is still reading this.
Thanks, updated the Whiteboard and URL fields according to http://www.gentoo.org/proj/en/kernel/maintenance.xml.
The fix was committed to 3.8 merge window, and after a friendly upstream successfully resolved new breakage in record time - https://bugs.freedesktop.org/show_bug.cgi?id=58867 - it also works for me in 3.7.1 with the additional patch.
UPSTREAM resolution is for bugs which need upstream action to fix.
> UPSTREAM resolution is for bugs which need upstream action to fix. Chí-Thanh Christopher Nguyễn: Please read "Reporting bugs on the kernel bugzilla" under "Reporting bugs upstream" at http://www.gentoo.org/proj/en/kernel/maintenance.xml because this explains in detail how UPSTREAM is to be used when bugs are reported upstream. When you remove this marking, the search used to track upstream bugs no longer shows this bug. Your status change goes against two things: 1. Mike Pagano has marked this bug as RESOLVED FIXED, it makes no sense to bring this bug back to the CONFIRMED state without any explanation as to why the bug suddenly has to be considered unresolved. If someone on the herd makes a decision, then why would someone outside the herd undo that? Under the "we aim to make genpatches as small as possible" objective listed in "General objectives" under "Maintenance style" at http://www.gentoo.org/proj/en/kernel/maintenance.xml there isn't much that can be done here, a member of the kernel herd has decided that there is no downstream action to be taken. 2. This bug does need upstream action to fix. The patch is in drm-intel-next but has yet to reach the stable kernels as it still has to merged in by a maintainer, this makes tracking preferable such that anyone who comes across this bug can be aware of its current status. Once the patch lands, we can mark this bug RESOLVED FIXED again; until then, the resolution can be tracked UPSTREAM. It seems that you are part of the x11 herd, so I assume you have applied a rule from that herd or a rule in general on a kernel@g.o assigned bug by accident; no worries, thank you for reading and have a nice day. :)
