From: Lennart Poettering <lennart@poettering.net>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>,
intel-gfx@lists.freedesktop.org,
David Herrmann <dh.herrmann@gmail.com>,
Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: drm i915 weirdness with /sys/class/drm/card0*/status
Date: Tue, 16 Jun 2015 13:22:00 +0200 [thread overview]
Message-ID: <20150616112200.GC27803@gardel-login> (raw)
In-Reply-To: <20150616102507.GQ23637@phenom.ffwll.local>
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
next prev parent reply other threads:[~2015-06-16 11:22 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 [this message]
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
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=20150616112200.GC27803@gardel-login \
--to=lennart@poettering.net \
--cc=airlied@linux.ie \
--cc=daniel.vetter@intel.com \
--cc=daniel@ffwll.ch \
--cc=dh.herrmann@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.