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

[Daniel Vetter]

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.

> This actually has a weird effect, as systemd-logind nowadays will
> inhibit suspend on lid close when an external screen is plugged in,
> and it checks that with these files, counting DRM card outputs with a
> state != disconnected. With the issue described above it will then
> suddenly count 4 instead of just one screen and hence the lid switch
> will be without effect. Which is kinda annoying, of course...
> 
> lspci info for the card is:
> 
> 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller])
>           Subsystem: Lenovo Device 3977
> 
> xorg.log says:
> 
> [  9567.487] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics 4000
> 
> This didn't use to be an issue with older kernel versions, such as
> various 4.0 kernels. Not sure though since when it is really borked.
> 
> This appears to be something to fix in the kernel drivers, but I am
> also wondering if I should reconsider the display counting code I
> added to logind, which currently counts all displays with a state !=
> disconnected. Should that be different, for example count displays
> with state == connected only?

Yes, there's piles of machines and cases where outputs can be unknown
because we can't probe them correctly. unknown has two use cases:
- At boot up use the unknown ones as a fallback to light up if there are
  no connected outputs.
- Otherwise it's kinda policy, but the sanest thing when seeing an unknown
  is to assume it's unchanged.

But given how pretty much no one in userspace gets this right I wonder
whether we should just do this clamping in the kernel ourselves ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch