[Intel-gfx] drm i915 weirdness with /sys/class/drm/card0*/status

[Daniel Vetter]

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 at ffwll.ch) 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 at chris-wilson.co.uk>
> > 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 at chris-wilson.co.uk>
> >     Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
> >     Cc: David Herrmann <dh.herrmann at gmail.com>
> >     Cc: Dave Airlie <airlied at redhat.com>
> >     Cc: Alex Deucher <alexdeucher at gmail.com>
> >     Reviewed-by: David Herrmann <dh.herrmann at gmail.com>
> >     Reviewed-by: Alex Deucher <alexander.deucher at amd.com>
> >     Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> > 
> > 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