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

Lennart Poettering lennart at poettering.net
Tue Jun 16 04:17:29 PDT 2015


On Tue, 16.06.15 10:14, Chris Wilson (chris at chris-wilson.co.uk) 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

The way people "dock" their laptops these days is apparently that
they plug in an external keyboard+mouse and a display, close the lid
and stash the laptop away somewhere. logind hence counts the displays
connected, and if its >= 2 it doesn't suspend the machine even if the
lid is closed. Before logind, GNOME implemented the very same
logic. It's hence hardly "illogical", it's just how this works...

> > We don't really depend on the userspace doing the reprobe, do we? On
> > resume, we reprobe the HPD capable connectors and schedule a poll for
> > the rest. Is it even possible the userspace sees unknown status for HPD
> > capable connectors on resume? Makes me wonder if there's something going
> > wrong with the hotplug irqs.
> 
> The unknown status is much more likely after boot, iirc. Unknown is not
> a big problem because very, very few applications actually query the
> current value without doing a probe (basically the new sysfs entry and
> X during takeover). We simply have not been able to trust hotplug to
> allow us to cache connector status at any level.

Well, logind does not probe right now. I was not aware one has to do
this.

Is there any reason the kernel doesn't automatically probe the
connectors when userspace asks for it and would return "unknown"
otherwise?

I can also implement a logic like that in logind, but then again,
maybe logind should leave the probing the connectors to X or the
kernel to figure out on their own?

Is the API of these files documented anywhere?

Lennart

-- 
Lennart Poettering, Red Hat


More information about the Intel-gfx mailing list