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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
