From: Daniel Vetter <daniel@ffwll.ch>
To: Simon Ser <contact@emersion.fr>
Cc: Daniel Vetter <daniel@ffwll.ch>,
Pekka Paalanen <ppaalanen@gmail.com>,
Rob Clark <robdclark@chromium.org>,
Brian Norris <briannorris@chromium.org>,
Andrzej Hajda <andrzej.hajda@intel.com>,
David Airlie <airlied@linux.ie>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
Doug Anderson <dianders@chromium.org>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>,
"Kristian H . Kristensen" <hoegsberg@google.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
linux-input@vger.kernel.org
Subject: Re: [PATCH v2 1/2] drm/input_helper: Add new input-handling helper
Date: Fri, 19 Nov 2021 17:11:07 +0100 [thread overview]
Message-ID: <YZfMm3GkFereYPTZ@phenom.ffwll.local> (raw)
In-Reply-To: <98236dpcx39iOz8xAYrwGLfiLdwgUlljrbBgHL3wd8A0Wz4KzRk3PR8s_tb5Rxu4eScKI4483kB6Vhv-T64CJYOeQqwXlqo2c-64HvoS5cg=@emersion.fr>
On Fri, Nov 19, 2021 at 04:04:28PM +0000, Simon Ser wrote:
> On Friday, November 19th, 2021 at 16:53, Daniel Vetter <daniel@ffwll.ch> wrote:
>
> > Random idea ... should we perhaps let userspace connect the boosting? I.e.
> > we do a bunch of standardized boost targets (render clocks, display sr
> > exit), and userspace can then connect it to whichever input device it
> > wants to?
>
> On IRC we discussed having user-space hand over a FD to the kernel. When the FD
> becomes readable, the kernel triggers the boost.
>
> This would let user-space use e.g. an input device, an eventfd, or an epoll FD
> with any combination of these as the boost signal.
Can userspace filter eventfd appropriately like we do here? And can they
get at that maybe 2nd eventfd from logind or whatever there is on distros
where /dev access is locked down for compositors/users.
I do agree that if we can do this generically maybe we should, but also
the use-case for input boosting is pretty well defined. I think it's just
about making sure that compositors is in control, and that we don't make
it worse (e.g. with the sr exit adding latency when the compositor can
redraw quickly enough).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2021-11-19 16:11 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-17 22:48 [PATCH v2 0/2] drm: Support input-boosted panel self-refresh exit Brian Norris
2021-11-17 22:48 ` [PATCH v2 1/2] drm/input_helper: Add new input-handling helper Brian Norris
2021-11-18 9:05 ` Daniel Vetter
2021-11-18 19:30 ` Brian Norris
2021-11-19 10:01 ` Daniel Vetter
2021-11-19 19:07 ` Brian Norris
2021-11-25 15:25 ` Daniel Vetter
2021-11-18 10:39 ` Pekka Paalanen
2021-11-18 23:30 ` Rob Clark
2021-11-19 9:54 ` Pekka Paalanen
2021-11-19 15:53 ` Daniel Vetter
2021-11-19 16:04 ` Simon Ser
2021-11-19 16:11 ` Daniel Vetter [this message]
2021-11-22 9:43 ` Pekka Paalanen
2021-11-25 15:30 ` Daniel Vetter
2021-11-19 16:44 ` Rob Clark
2021-11-19 16:50 ` Doug Anderson
2021-11-19 1:46 ` Brian Norris
2021-11-19 10:38 ` Pekka Paalanen
2021-11-19 15:56 ` Daniel Vetter
2021-11-22 9:25 ` Pekka Paalanen
2021-11-30 20:35 ` Brian Norris
2021-12-07 3:16 ` Peter Hutterer
2021-11-17 22:48 ` [PATCH v2 2/2] drm/self_refresh: Disable self-refresh on input events Brian Norris
2021-11-18 9:11 ` Daniel Vetter
2021-11-18 8:34 ` [PATCH v2 0/2] drm: Support input-boosted panel self-refresh exit Simon Ser
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=YZfMm3GkFereYPTZ@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=airlied@linux.ie \
--cc=andrzej.hajda@intel.com \
--cc=briannorris@chromium.org \
--cc=contact@emersion.fr \
--cc=dianders@chromium.org \
--cc=dmitry.torokhov@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hoegsberg@google.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=ppaalanen@gmail.com \
--cc=robdclark@chromium.org \
--cc=tzimmermann@suse.de \
/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;
as well as URLs for NNTP newsgroup(s).