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

Chris Wilson chris at chris-wilson.co.uk
Tue Jun 16 02:14:46 PDT 2015


On Tue, Jun 16, 2015 at 11:12:22AM +0300, Jani Nikula wrote:
> On Tue, 16 Jun 2015, Daniel Vetter <daniel at ffwll.ch> wrote:
> > On Tue, Jun 16, 2015 at 01:45:00AM +0200, Lennart Poettering wrote:
> >> heya,
> >> 
> >> I am experiencing something weird with the i915 driver in kernel
> >> 4.1.0-0.rc8 (precisely 4.1.0-0.rc8.git0.1.fc23.x86_64 from fedora
> >> rawhide):
> >> 
> >> On my laptop, when I type this:
> >>    
> >>         grep . /sys/class/drm/card0*/status
> >> 
> >> I usually get this:
> >> 
> >>         /sys/class/drm/card0-DP-1/status:disconnected
> >>         /sys/class/drm/card0-HDMI-A-1/status:disconnected
> >>         /sys/class/drm/card0-LVDS-1/status:connected
> >>         /sys/class/drm/card0-VGA-1/status:disconnected
> >> 
> >> WHich is fine and looks correct, but sometimes I instead get this:
> >> 
> >>         /sys/class/drm/card0-DP-1/status:unknown
> >>         /sys/class/drm/card0-HDMI-A-1/status:unknown
> >>         /sys/class/drm/card0-LVDS-1/status:connected
> >>         /sys/class/drm/card0-VGA-1/status:unknown
> >> 
> >> i.e. the status of the unconnected GPU outputs changes from
> >> disconnected to unknown. It's not really clear to me when this
> >> happens, but it appears to be reproducible after the machine comes
> >> back from suspend.
> >
> > Yeah this is how the sysfs interface works. On resume we reset the
> > connector state to unknown and send out a uevent to make sure userspace
> > reprobes. Once reprobed the connector status will be udpated. sysfs
> > interface themselves never cause a probe but only print out the current
> > value. To force a probe you need to do ioctls on the drm device.
> >
> > This has been like that since forever, so I guess what changed for you is
> > that systemd reads these files before X gets around to force a probe.

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
 
> 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.
 
> If everyone in userspace starts forcing the reprobe we'll be doing that
> a lot...

Fortunately X is a little smarter than that, but only a little.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list