On Wed, Oct 06, 2010 at 02:31:22PM -0700, Adam Williamson wrote: > On Wed, 2010-10-06 at 23:32 +0300, Pasi Kärkkäinen wrote: > > > What's the worst thing that can happen when trusting the ACPI lid state? > > > > Think about this: > > > > - Laptop lid open (so internal lvds enabled), and also external monitor connected. > > - lid state is wrong at boot, so it says lid closed. > > - Scripts check: "lid closed, external display enabled -> use only external monitor". > > > > That gives you a working setup, you can login using the external display, > > and use the system perfectly fine. You can then manually enable the > > internal lvds display, or possibly enable some workaround, > > as you have a buggy laptop/driver/bios. > > > > That doesn't sound bad at all. > > However, it's not the worst case. The worst case is if someone has an > external monitor connected which they're not actually using (it may be > hidden or being used with some other input or just turned off). This > does happen: > > https://bugzilla.redhat.com/show_bug.cgi?id=582525 > > that bug is already inconvenient for some people; if they have laptops > with bad lid switches it'd be much more inconvenient. The only active > display would be the external display they weren't actually using. I read that bugzilla as it's a driver bug.. so it'll get fixed at some point. We should define "policy" based on wanted behaviour, not based on various bugs out there.. Bugs need to be fixed, and then the policy works like it's expected. atm we're lacking a policy regarding these laptop lid/dock things. Ie. there's no daemon/script even trying to do the right thing.. (drm/kms driver guys have made it clear the "policy" has to be decided and set up by userspace). For the "transition period" we could have a boot/grub menu item that automatically enables the "old behaviour" for people who have hardware with buggy bios/drivers. Just like we have the "safe (vesa) graphics" boot option on install CDs. Does this make sense? -- Pasi -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
