Re: Making Fedora work with laptops on docking station with external monitor

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux