On Thu, Oct 07, 2010 at 10:17:11AM -0700, Adam Williamson wrote: > 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. >
Hmm... things seem to work always ok on Windows, so it should be possible.. > > 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. > Well, I'm staring at blank screens with the current behaviour.. :) > > 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. > Ok. But yes, we need some daemon that monitors ACPI lid state, and kms/drm output states, and enables/disables displays based on those. We're clearly lacking that atm. Driver developers have made it clear userspace needs a component that takes care of that. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
