Hi On Tue, Jun 16, 2015 at 11:25 PM, Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote: > On Tue, 16.06.15 13:47, Daniel Vetter (daniel@xxxxxxxx) wrote: > >> > But what does that actually mean? should logind ever echo "detect" >> > itself into the file? Should it follow uevents for the files? How >> > should treat this file? >> >> Ok here's how this is supposed to work: >> - If anything changes the kernel will send out an uevent and compositors/X >> or anyone else interested can listen for them. We've had a few bugs in >> the past where such events where lost in a combination of bad luck and >> bad hw, but that should all be fixed now. >> >> - Userspace should never poll these things on its own since probing is >> ridiculously expensive. Unfortunately years of closing bugs as wontfix >> hasn't lead to userspace stop polling (despite that the kernel does that >> too if it's needed) which resulted in the above patch to take away the >> those from at least system deamons. > > I find the kernel patch you applied a bit drastic, it broke userspace, > returning rubbish unless somebody echoes the "detect" into the file -- > which apparently nothing does, at least not after we came back from a > suspend... I don't think it was supposed to work this way. If I read Daniel's reply correctly, then the kernel is supposed to re-read connector state after resume (without explicit trigger from user-space). It might return 'unknown' for some time, but once it was refreshed, it should send out a uevent and the correct state should now be read. And logind works fine with this behavior. Anyway, I'm not sure why your machine doesn't work that way. I cannot see the problems here on my machine. >> > Well, but things are close enough, closing the lid, plugging in a >> > second display and then leaving it off and expecting things to suspend >> > now is probably a very exceptional case... >> > >> > That said, how would I check if the connector is both plugged *and* >> > enabled? If there's a sane sysfs API for that, I'd be happy to extend >> > the check for you. >> >> In the same sysyfs directory there's "enabled" (indicating that an output >> is logically in use) and "dpms" (which shows the dpms state, but that is >> not clamped to Off when the output isn't in use because of ABI history and >> other hilarious reasons). enabled == "enabled" && dpms == "On" is probably >> what you want. > > OK, I will change logind to check these two as well. Thanks for the hint! I don't think we should look at "DPMS" (compositors use it for runtime energy management). Otherwise, looks good to me. Thanks David _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
