From: Lennart Poettering <lennart@poettering.net>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>,
Daniel Vetter <daniel.vetter@intel.com>,
intel-gfx@lists.freedesktop.org
Subject: Re: drm i915 weirdness with /sys/class/drm/card0*/status
Date: Tue, 16 Jun 2015 23:08:25 +0200 [thread overview]
Message-ID: <20150616210824.GA28290@gardel-login> (raw)
In-Reply-To: <20150616102507.GQ23637@phenom.ffwll.local>
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
next prev parent reply other threads:[~2015-06-16 21:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-15 23:45 drm i915 weirdness with /sys/class/drm/card0*/status Lennart Poettering
2015-06-16 7:47 ` Daniel Vetter
2015-06-16 8:12 ` Jani Nikula
2015-06-16 9:14 ` Chris Wilson
2015-06-16 10:25 ` Daniel Vetter
2015-06-16 11:22 ` Lennart Poettering
2015-06-16 11:47 ` Daniel Vetter
2015-06-16 21:25 ` Lennart Poettering
2015-06-17 8:29 ` David Herrmann
2015-06-17 11:11 ` Daniel Vetter
2015-06-17 16:41 ` Lennart Poettering
2015-06-16 21:08 ` Lennart Poettering [this message]
2015-06-16 22:39 ` Dave Airlie
2015-06-16 11:17 ` Lennart Poettering
2015-06-16 11:37 ` Chris Wilson
2015-06-16 21:28 ` Lennart Poettering
2015-06-17 7:45 ` Chris Wilson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150616210824.GA28290@gardel-login \
--to=lennart@poettering.net \
--cc=airlied@linux.ie \
--cc=daniel.vetter@intel.com \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox