Message-ID: <20211122114342.0d23890f@eldfell>
Date:   Mon, 22 Nov 2021 11:43:42 +0200
From:   Pekka Paalanen <ppaalanen@...il.com>
To:     Daniel Vetter <daniel@...ll.ch>
Cc:     Simon Ser <contact@...rsion.fr>,
        Rob Clark <robdclark@...omium.org>,
        Brian Norris <briannorris@...omium.org>,
        Andrzej Hajda <andrzej.hajda@...el.com>,
        David Airlie <airlied@...ux.ie>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Doug Anderson <dianders@...omium.org>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
        "Kristian H . Kristensen" <hoegsberg@...gle.com>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        linux-input@...r.kernel.org
Subject: Re: [PATCH v2 1/2] drm/input_helper: Add new input-handling helper

On Fri, 19 Nov 2021 17:11:07 +0100
Daniel Vetter <daniel@...ll.ch> wrote:

> On Fri, Nov 19, 2021 at 04:04:28PM +0000, Simon Ser wrote:
> > On Friday, November 19th, 2021 at 16:53, Daniel Vetter <daniel@...ll.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.

(Mind, eventfd is a specific thing, see 'man eventfd', and evdev/input
device fd is different.)

I don't think any of that is any problem when userspace prepares an
epoll fd to be given to the boosting machinery. The boosting machinery
could have several different targets as well, PSR vs. GPU clocks and
whatnot.

I envision a compositor to maintain an epoll fd for boosting by
adding/removing the same device fds to it that it already uses in its
operations. I don't see any need to open new device fds just for
boosting. It's only the epoll fd given to the kernel and after that the
epoll set can still be changed, right?

The boosting machinery would never actually read or write the
registered fd(s), so it would not interfere with the normal operations.
But it also means the fd will remain readable until userspace services
it. Userspace may need to set up that epoll set very carefully to have
it work right (e.g. edge-triggered?).

If your input handling is in a different process than the DRM poking
for some reason, the epoll fd should still work if:
- it is possible to use SCM_RIGHTS to pass the epollfd from the
  input process to the DRM process, and
- you cannot extract the watched fds from an epoll fd.

Do we have those assumptions today?

Then the attack surface in the DRM process is limited to changing the
epoll set of which fds can trigger boosting, but the DRM process can do
that anyway. I also presume the input process can still add and remove
fds from the epoll set even afterwards.

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

The epollfd design sounds very good to me. One can register an
arbitrary set of fds with it, and use even eventfds in the set to have
purely software triggers.


Thanks,
pq

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists