drm i915 weirdness with /sys/class/drm/card0*/status

drm i915 weirdness with /sys/class/drm/card0*/status

[Lennart Poettering]

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.

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?

Lennart

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: drm i915 weirdness with /sys/class/drm/card0*/status

[Jani Nikula]

On Tue, 16 Jun 2015, Daniel Vetter <daniel@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.

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

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: drm i915 weirdness with /sys/class/drm/card0*/status

[Chris Wilson]

On Tue, Jun 16, 2015 at 11:12:22AM +0300, Jani Nikula wrote:
> On Tue, 16 Jun 2015, Daniel Vetter <daniel@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
 
> 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.

The unknown status is much more likely after boot, iirc. Unknown is not
a big problem because very, very few applications actually query the
current value without doing a probe (basically the new sysfs entry and
X during takeover). We simply have not been able to trust hotplug to
allow us to cache connector status at any level.
 
> If everyone in userspace starts forcing the reprobe we'll be doing that
> a lot...

Fortunately X is a little smarter than that, but only a little.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: 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@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@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@chris-wilson.co.uk>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: David Herrmann <dh.herrmann@gmail.com>
    Cc: Dave Airlie <airlied@redhat.com>
    Cc: Alex Deucher <alexdeucher@gmail.com>
    Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: drm i915 weirdness with /sys/class/drm/card0*/status

[Lennart Poettering]

B1;4002;0cOn Tue, 16.06.15 12:25, Daniel Vetter (daniel@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:
> 
> commit c484f02d0f02fbbfc6decc945a69aae011041a27
> Author: Chris Wilson <chris@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.

But what does that actually mean? should logind ever echo "detect"
itself into the file? Should it follow uevents for the files? How
should treat this file?

>     v3: Now with airlied's email address fixed! Requires sysfs_streq()
>     
>     Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>     Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>     Cc: David Herrmann <dh.herrmann@gmail.com>
>     Cc: Dave Airlie <airlied@redhat.com>
>     Cc: Alex Deucher <alexdeucher@gmail.com>
>     Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
>     Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>     Signed-off-by: Daniel Vetter <daniel.vetter@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 ;-)

Well, but things are close enough, closing the lid, plugging in a
second display and then leaving it off and expecting things to suspend
now is probably a very exceptional case... 

That said, how would I check if the connector is both plugged *and*
enabled? If there's a sane sysfs API for that, I'd be happy to extend
the check for you.

Lennart

-- 
Lennart Poettering, Red Hat
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: drm i915 weirdness with /sys/class/drm/card0*/status

[Daniel Vetter]

On Tue, Jun 16, 2015 at 01:22:00PM +0200, Lennart Poettering wrote:
> B1;4002;0cOn Tue, 16.06.15 12:25, Daniel Vetter (daniel@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:
> > 
> > commit c484f02d0f02fbbfc6decc945a69aae011041a27
> > Author: Chris Wilson <chris@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.
> 
> But what does that actually mean? should logind ever echo "detect"
> itself into the file? Should it follow uevents for the files? How
> should treat this file?

Ok here's how this is supposed to work:
- If anything changes the kernel will send out an uevent and compositors/X
  or anyone else interested can listen for them. We've had a few bugs in
  the past where such events where lost in a combination of bad luck and
  bad hw, but that should all be fixed now.

- Userspace should never poll these things on its own since probing is
  ridiculously expensive. Unfortunately years of closing bugs as wontfix
  hasn't lead to userspace stop polling (despite that the kernel does that
  too if it's needed) which resulted in the above patch to take away the
  those from at least system deamons.

- The kernel can hand you out an unknown status if it can't figure it out
  or if it's still trying to figure things out. Happens when you use the
  sysfs stuff since the above patch since we also had to drop the locking
  (the stalls are really terrible otherwise).

- If you want to support anything but pure digital hdmi/dp outputs you
  need to give your users some way to manually force a probe since hotplug
  interrupts are just plain unreliable. Same goes for for automatically
  reconfiguring the desktop when an output disappears, that can happen
  spuriously on crappy outputs ;-)

> >     v3: Now with airlied's email address fixed! Requires sysfs_streq()
> >     
> >     Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> >     Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> >     Cc: David Herrmann <dh.herrmann@gmail.com>
> >     Cc: Dave Airlie <airlied@redhat.com>
> >     Cc: Alex Deucher <alexdeucher@gmail.com>
> >     Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
> >     Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> >     Signed-off-by: Daniel Vetter <daniel.vetter@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 ;-)
> 
> Well, but things are close enough, closing the lid, plugging in a
> second display and then leaving it off and expecting things to suspend
> now is probably a very exceptional case... 
> 
> That said, how would I check if the connector is both plugged *and*
> enabled? If there's a sane sysfs API for that, I'd be happy to extend
> the check for you.

In the same sysyfs directory there's "enabled" (indicating that an output
is logically in use) and "dpms" (which shows the dpms state, but that is
not clamped to Off when the output isn't in use because of ABI history and
other hilarious reasons). enabled == "enabled" && dpms == "On" is probably
what you want.

This would also be more reliable since it indicates what the compositor is
actually using. With manual setups (see the note above about hpd status
and interrupts being unreliable) you may very well be driving a
disconnected output and the user sees something.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: drm i915 weirdness with /sys/class/drm/card0*/status

[Lennart Poettering]

On Tue, 16.06.15 13:47, Daniel Vetter (daniel@ffwll.ch) wrote:

> > But what does that actually mean? should logind ever echo "detect"
> > itself into the file? Should it follow uevents for the files? How
> > should treat this file?
> 
> Ok here's how this is supposed to work:
> - If anything changes the kernel will send out an uevent and compositors/X
>   or anyone else interested can listen for them. We've had a few bugs in
>   the past where such events where lost in a combination of bad luck and
>   bad hw, but that should all be fixed now.
> 
> - Userspace should never poll these things on its own since probing is
>   ridiculously expensive. Unfortunately years of closing bugs as wontfix
>   hasn't lead to userspace stop polling (despite that the kernel does that
>   too if it's needed) which resulted in the above patch to take away the
>   those from at least system deamons.

I find the kernel patch you applied a bit drastic, it broke userspace,
returning rubbish unless somebody echoes the "detect" into the file --
which apparently nothing does, at least not after we came back from a
suspend...

It makes a lot of sense to cache data here, and I think it's even fine
returning out-of-date data. But returning rubbish is wrong...

logind already subscribes to all uevents from drm devices. It will
hence notice already when the plug status changes. However due to your
kernel changes the plug status changes to "unknown" for all displays
after a resume. And it then stays in that state forever since nothing
ever asks for "detect" afterwards.

I see three options to fix this:

a) fix the kernel, and make it reprobe the plugs on its own, either
   immediately after returning from suspend, or the first time the
   state is queried after coming back from suspend.

b) work around the changed kernel API and make X11 reprobe all plugs
   after coming back from a suspend

c) I could also do the same from logind: reprobe all plugs after
   coming back from a suspend.

I am pretty sure the right fix is a), but I am fine with b) and c) too...

> > Well, but things are close enough, closing the lid, plugging in a
> > second display and then leaving it off and expecting things to suspend
> > now is probably a very exceptional case... 
> > 
> > That said, how would I check if the connector is both plugged *and*
> > enabled? If there's a sane sysfs API for that, I'd be happy to extend
> > the check for you.
> 
> In the same sysyfs directory there's "enabled" (indicating that an output
> is logically in use) and "dpms" (which shows the dpms state, but that is
> not clamped to Off when the output isn't in use because of ABI history and
> other hilarious reasons). enabled == "enabled" && dpms == "On" is probably
> what you want.

OK, I will change logind to check these two as well. Thanks for the hint!

Lennart

-- 
Lennart Poettering, Red Hat
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: drm i915 weirdness with /sys/class/drm/card0*/status

[David Herrmann]

Hi

On Tue, Jun 16, 2015 at 11:25 PM, Lennart Poettering
<lennart@poettering.net> wrote:
> On Tue, 16.06.15 13:47, Daniel Vetter (daniel@ffwll.ch) wrote:
>
>> > But what does that actually mean? should logind ever echo "detect"
>> > itself into the file? Should it follow uevents for the files? How
>> > should treat this file?
>>
>> Ok here's how this is supposed to work:
>> - If anything changes the kernel will send out an uevent and compositors/X
>>   or anyone else interested can listen for them. We've had a few bugs in
>>   the past where such events where lost in a combination of bad luck and
>>   bad hw, but that should all be fixed now.
>>
>> - Userspace should never poll these things on its own since probing is
>>   ridiculously expensive. Unfortunately years of closing bugs as wontfix
>>   hasn't lead to userspace stop polling (despite that the kernel does that
>>   too if it's needed) which resulted in the above patch to take away the
>>   those from at least system deamons.
>
> I find the kernel patch you applied a bit drastic, it broke userspace,
> returning rubbish unless somebody echoes the "detect" into the file --
> which apparently nothing does, at least not after we came back from a
> suspend...

I don't think it was supposed to work this way. If I read Daniel's
reply correctly, then the kernel is supposed to re-read connector
state after resume (without explicit trigger from user-space). It
might return 'unknown' for some time, but once it was refreshed, it
should send out a uevent and the correct state should now be read. And
logind works fine with this behavior.

Anyway, I'm not sure why your machine doesn't work that way. I cannot
see the problems here on my machine.

>> > Well, but things are close enough, closing the lid, plugging in a
>> > second display and then leaving it off and expecting things to suspend
>> > now is probably a very exceptional case...
>> >
>> > That said, how would I check if the connector is both plugged *and*
>> > enabled? If there's a sane sysfs API for that, I'd be happy to extend
>> > the check for you.
>>
>> In the same sysyfs directory there's "enabled" (indicating that an output
>> is logically in use) and "dpms" (which shows the dpms state, but that is
>> not clamped to Off when the output isn't in use because of ABI history and
>> other hilarious reasons). enabled == "enabled" && dpms == "On" is probably
>> what you want.
>
> OK, I will change logind to check these two as well. Thanks for the hint!

I don't think we should look at "DPMS" (compositors use it for runtime
energy management). Otherwise, looks good to me.

Thanks
David
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: drm i915 weirdness with /sys/class/drm/card0*/status

[Daniel Vetter]

On Wed, Jun 17, 2015 at 10:29:48AM +0200, David Herrmann wrote:
> Hi
> 
> On Tue, Jun 16, 2015 at 11:25 PM, Lennart Poettering
> <lennart@poettering.net> wrote:
> > On Tue, 16.06.15 13:47, Daniel Vetter (daniel@ffwll.ch) wrote:
> >
> >> > But what does that actually mean? should logind ever echo "detect"
> >> > itself into the file? Should it follow uevents for the files? How
> >> > should treat this file?
> >>
> >> Ok here's how this is supposed to work:
> >> - If anything changes the kernel will send out an uevent and compositors/X
> >>   or anyone else interested can listen for them. We've had a few bugs in
> >>   the past where such events where lost in a combination of bad luck and
> >>   bad hw, but that should all be fixed now.
> >>
> >> - Userspace should never poll these things on its own since probing is
> >>   ridiculously expensive. Unfortunately years of closing bugs as wontfix
> >>   hasn't lead to userspace stop polling (despite that the kernel does that
> >>   too if it's needed) which resulted in the above patch to take away the
> >>   those from at least system deamons.
> >
> > I find the kernel patch you applied a bit drastic, it broke userspace,
> > returning rubbish unless somebody echoes the "detect" into the file --
> > which apparently nothing does, at least not after we came back from a
> > suspend...
> 
> I don't think it was supposed to work this way. If I read Daniel's
> reply correctly, then the kernel is supposed to re-read connector
> state after resume (without explicit trigger from user-space). It
> might return 'unknown' for some time, but once it was refreshed, it
> should send out a uevent and the correct state should now be read. And
> logind works fine with this behavior.
> 
> Anyway, I'm not sure why your machine doesn't work that way. I cannot
> see the problems here on my machine.

Yes there seems to be something amiss with the reprobing. Does the below
kernel patch help?
-Daniel

diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c
index 04203c0d2ecb..aa0fae2f24d1 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -497,10 +497,6 @@ bool drm_helper_hpd_irq_event(struct drm_device *dev)
 	mutex_lock(&dev->mode_config.mutex);
 	list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
 
-		/* Only handle HPD capable connectors. */
-		if (!(connector->polled & DRM_CONNECTOR_POLL_HPD))
-			continue;
-
 		old_status = connector->status;
 
 		connector->status = connector->funcs->detect(connector, false);
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: drm i915 weirdness with /sys/class/drm/card0*/status

[Lennart Poettering]

On Tue, 16.06.15 23:25, Lennart Poettering (lennart@poettering.net) wrote:

> > In the same sysyfs directory there's "enabled" (indicating that an output
> > is logically in use) and "dpms" (which shows the dpms state, but that is
> > not clamped to Off when the output isn't in use because of ABI history and
> > other hilarious reasons). enabled == "enabled" && dpms == "On" is probably
> > what you want.
> 
> OK, I will change logind to check these two as well. Thanks for the hint!

This is implemented now, btw:

https://github.com/systemd/systemd/commit/602a41c22ac2df33b4b5e5083719c1cfaf58acf9

This patch will also now consider eDP and LVDS internal plugs, and
won't consider them when detecting whether the system is docked.

Lennart

-- 
Lennart Poettering, Red Hat
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: drm i915 weirdness with /sys/class/drm/card0*/status

[Lennart Poettering]

On Tue, 16.06.15 12:25, Daniel Vetter (daniel@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@chris-wilson.co.uk>
>     Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>     Cc: David Herrmann <dh.herrmann@gmail.com>
>     Cc: Dave Airlie <airlied@redhat.com>
>     Cc: Alex Deucher <alexdeucher@gmail.com>
>     Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
>     Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>     Signed-off-by: Daniel Vetter <daniel.vetter@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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: drm i915 weirdness with /sys/class/drm/card0*/status

[Dave Airlie]

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

Real drm KMS users don't need to do this, X should just do a normal ioctl
on the device and cause it to happen, 

echoing detect is only a backdoor for external non-KMS fd opening users,

Just clarifying, clearly there is a bug here with the unknowns getting
stuck on, hopefully someone can reproduce it and fix it

Dave.

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: drm i915 weirdness with /sys/class/drm/card0*/status

[Lennart Poettering]

On Tue, 16.06.15 10:14, Chris Wilson (chris@chris-wilson.co.uk) 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

The way people "dock" their laptops these days is apparently that
they plug in an external keyboard+mouse and a display, close the lid
and stash the laptop away somewhere. logind hence counts the displays
connected, and if its >= 2 it doesn't suspend the machine even if the
lid is closed. Before logind, GNOME implemented the very same
logic. It's hence hardly "illogical", it's just how this works...

> > 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.
> 
> The unknown status is much more likely after boot, iirc. Unknown is not
> a big problem because very, very few applications actually query the
> current value without doing a probe (basically the new sysfs entry and
> X during takeover). We simply have not been able to trust hotplug to
> allow us to cache connector status at any level.

Well, logind does not probe right now. I was not aware one has to do
this.

Is there any reason the kernel doesn't automatically probe the
connectors when userspace asks for it and would return "unknown"
otherwise?

I can also implement a logic like that in logind, but then again,
maybe logind should leave the probing the connectors to X or the
kernel to figure out on their own?

Is the API of these files documented anywhere?

Lennart

-- 
Lennart Poettering, Red Hat
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: drm i915 weirdness with /sys/class/drm/card0*/status

[Chris Wilson]

On Tue, Jun 16, 2015 at 01:17:29PM +0200, Lennart Poettering wrote:
> On Tue, 16.06.15 10:14, Chris Wilson (chris@chris-wilson.co.uk) 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
> 
> The way people "dock" their laptops these days is apparently that
> they plug in an external keyboard+mouse and a display, close the lid
> and stash the laptop away somewhere. logind hence counts the displays
> connected, and if its >= 2 it doesn't suspend the machine even if the
> lid is closed. Before logind, GNOME implemented the very same
> logic. It's hence hardly "illogical", it's just how this works...

Note that a closed lid causes the internal panel to be reported as
disconnected - it always has (with the exception of a module parameter
to force otherwise to accommodate broken lid buttons). Using the number
of connected displays is thus flawed.

> > > 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.
> > 
> > The unknown status is much more likely after boot, iirc. Unknown is not
> > a big problem because very, very few applications actually query the
> > current value without doing a probe (basically the new sysfs entry and
> > X during takeover). We simply have not been able to trust hotplug to
> > allow us to cache connector status at any level.
> 
> Well, logind does not probe right now. I was not aware one has to do
> this.
> 
> Is there any reason the kernel doesn't automatically probe the
> connectors when userspace asks for it and would return "unknown"
> otherwise?

Probing is very slow and will cause flicker on some machines.
 
> I can also implement a logic like that in logind, but then again,
> maybe logind should leave the probing the connectors to X or the
> kernel to figure out on their own?

Yes. logind is only using the status to count the number of connected
outputs, when it was probing I noticed because logind was using more CPU
time during X startup/shutdown than X was itself.
 
> Is the API of these files documented anywhere?

The status is the first one we added a store attribute to, probably why
we overlooked expanding the none existent documentation. We also have not
documented the meaning of the reported string.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: drm i915 weirdness with /sys/class/drm/card0*/status

[Lennart Poettering]

On Tue, 16.06.15 12:37, Chris Wilson (chris@chris-wilson.co.uk) wrote:

> On Tue, Jun 16, 2015 at 01:17:29PM +0200, Lennart Poettering wrote:
> > On Tue, 16.06.15 10:14, Chris Wilson (chris@chris-wilson.co.uk) 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
> > 
> > The way people "dock" their laptops these days is apparently that
> > they plug in an external keyboard+mouse and a display, close the lid
> > and stash the laptop away somewhere. logind hence counts the displays
> > connected, and if its >= 2 it doesn't suspend the machine even if the
> > lid is closed. Before logind, GNOME implemented the very same
> > logic. It's hence hardly "illogical", it's just how this works...
> 
> Note that a closed lid causes the internal panel to be reported as
> disconnected - it always has (with the exception of a module parameter
> to force otherwise to accommodate broken lid buttons). Using the number
> of connected displays is thus flawed.

Hmm, if I change the algorithm to ignore the eDP and LVDS outputs and
see if any of the others is plugged + enabled should fix this, correct?

Lennart

-- 
Lennart Poettering, Red Hat
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: drm i915 weirdness with /sys/class/drm/card0*/status

[Chris Wilson]

On Tue, Jun 16, 2015 at 11:28:19PM +0200, Lennart Poettering wrote:
> On Tue, 16.06.15 12:37, Chris Wilson (chris@chris-wilson.co.uk) wrote:
> 
> > On Tue, Jun 16, 2015 at 01:17:29PM +0200, Lennart Poettering wrote:
> > > On Tue, 16.06.15 10:14, Chris Wilson (chris@chris-wilson.co.uk) 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
> > > 
> > > The way people "dock" their laptops these days is apparently that
> > > they plug in an external keyboard+mouse and a display, close the lid
> > > and stash the laptop away somewhere. logind hence counts the displays
> > > connected, and if its >= 2 it doesn't suspend the machine even if the
> > > lid is closed. Before logind, GNOME implemented the very same
> > > logic. It's hence hardly "illogical", it's just how this works...
> > 
> > Note that a closed lid causes the internal panel to be reported as
> > disconnected - it always has (with the exception of a module parameter
> > to force otherwise to accommodate broken lid buttons). Using the number
> > of connected displays is thus flawed.
> 
> Hmm, if I change the algorithm to ignore the eDP and LVDS outputs and
> see if any of the others is plugged + enabled should fix this, correct?

LVDS/eDP/DSI/MIPI + more unknown

Though even VGA/DVI have turned up in some systems to drive panels.

On a working i915 system, if there is any display connected, it means
the lid is either open or there a cable plugged in. Respond too quickly
to a hotunplug event though and you may end up suspending due to an
interrupt storm or just a single failed EDID read.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx