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

[Daniel Vetter]

On Tue, Jun 16, 2015 at 10:14:46AM +0100, Chris Wilson wrote:
> 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

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.
    
    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 ;-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch