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

[David Herrmann]

Hi

On Tue, Jun 16, 2015 at 11:25 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Tue, 16.06.15 13:47, Daniel Vetter (daniel at 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