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... It makes a lot of sense to cache data here, and I think it's even fine returning out-of-date data. But returning rubbish is wrong... logind already subscribes to all uevents from drm devices. It will hence notice already when the plug status changes. However due to your kernel changes the plug status changes to "unknown" for all displays after a resume. And it then stays in that state forever since nothing ever asks for "detect" afterwards. I see three options to fix this: a) fix the kernel, and make it reprobe the plugs on its own, either immediately after returning from suspend, or the first time the state is queried after coming back from suspend. b) work around the changed kernel API and make X11 reprobe all plugs after coming back from a suspend c) I could also do the same from logind: reprobe all plugs after coming back from a suspend. I am pretty sure the right fix is a), but I am fine with b) and c) too... > > 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! Lennart -- Lennart Poettering, Red Hat _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
