On Tue, Jun 16, 2015 at 01:22:00PM +0200, Lennart Poettering wrote: > B1;4002;0cOn Tue, 16.06.15 12:25, Daniel Vetter (daniel@xxxxxxxx) wrote: > > > > The biggest change here is 4.1 stopped forcing the probe from sysfs > > > precisely because systemd was hitting them so often for illogical > > > reasons (being docked depends on having the lid open and an > > > external display connected!). To force the probe, you must do > > > $ echo detect > /sys/class/drm/*/status > > > > Oh right I've forgotten about that one. For reference the commit is: > > > > commit c484f02d0f02fbbfc6decc945a69aae011041a27 > > Author: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Date: Fri Mar 6 12:36:42 2015 +0000 > > > > drm: Lighten sysfs connector 'status' > > > > Since the beginning, sysfs/connector/status has done a heavyweight > > detection of the current connector status. But no user, such as upowerd > > or logind, has ever desired to initiate a probe. Move the probing into a > > new attribute so that existing readers get the behaviour they desire. > > > > v2: David Herrmann suggested using "echo detect > /sys/.../status" to > > trigger the probing, which is a fine idea. This extends that to also > > allow the user to apply the force detection overrides at > > runtime. > > 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. - The kernel can hand you out an unknown status if it can't figure it out or if it's still trying to figure things out. Happens when you use the sysfs stuff since the above patch since we also had to drop the locking (the stalls are really terrible otherwise). - If you want to support anything but pure digital hdmi/dp outputs you need to give your users some way to manually force a probe since hotplug interrupts are just plain unreliable. Same goes for for automatically reconfiguring the desktop when an output disappears, that can happen spuriously on crappy outputs ;-) > > v3: Now with airlied's email address fixed! Requires sysfs_streq() > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: Daniel Vetter <daniel.vetter@xxxxxxxx> > > Cc: David Herrmann <dh.herrmann@xxxxxxxxx> > > Cc: Dave Airlie <airlied@xxxxxxxxxx> > > Cc: Alex Deucher <alexdeucher@xxxxxxxxx> > > Reviewed-by: David Herrmann <dh.herrmann@xxxxxxxxx> > > Reviewed-by: Alex Deucher <alexander.deucher@xxxxxxx> > > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > > > Even reviewed by systemd developer! > > > > btw small complaint about looking connector status: Just because something > > is plugged in doesn't mean it's actually enabled. Hence checking for > > connector status to decide at the system level whether lid close should > > suspend or not doesn't make a whole lot of sense imo. But that's just a > > rant aside ;-) > > 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. This would also be more reliable since it indicates what the compositor is actually using. With manual setups (see the note above about hpd status and interrupts being unreliable) you may very well be driving a disconnected output and the user sees something. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
