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

Lennart Poettering lennart at poettering.net
Tue Jun 16 14:08:25 PDT 2015


On 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:

So, there's definitely a bug here somewhere: the status field stays at
"unknown" continously on mylaptop after coming back from a
suspend. X11 doesn't do the "echo detect", the kernel doesn't do it,
and neither does logind. Nothing apparently does. But something really
should.

It appears really wrong to me to even propagate "unknown" to
userspace, if the kernel could actually check connectivity and then
know. It's fine to return cached information, it's fine to return
"unknown" if the hw is of the kind where we it cannot be known whether
something is connected. But returning "unknown" if there's really no
reason is just borked. (also, it's quite an ABI break, and it broke
userspace... I mean, I am not a ABI stability fanatic, but I hear that
among kernel developers it's a big thing...)

>     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!

David indicated to me that the behaviour of returning "unknown" on
purpose was certainly not what he intended. David?

Lennart

-- 
Lennart Poettering, Red Hat


More information about the Intel-gfx mailing list