On Tue, 16 Jun 2015, Daniel Vetter <daniel@xxxxxxxx> 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. 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. If everyone in userspace starts forcing the reprobe we'll be doing that a lot... BR, Jani. > >> 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 -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
