On Thu, 2010-10-07 at 10:49 +0300, Pasi Kärkkäinen wrote: > > 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.
Not really; the driver isn't able to detect if connected monitors are turned on. It's not clear if this is really *theoretically* possible, which is why the report's been closed. And it doesn't cover the case where a connected monitor is powered on but not actually being used for the computer. > 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. In theory, yeah, but in practice, we can't take this to extremes if it means we wind up with people staring at blank screens with no apparent explanation. > 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? No, not really, parameters aren't magic, they can only do things if the drivers / userspace utilities are written with these parameters in mind. I don't believe there's any such framework at present, and besides, we want to have *fewer* icky bootloader menu workarounds, really, not more. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
