linux-kernel - Re: [PATCH v2 1/2] drm/input_helper: Add new input-handling helper

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YZfMm3GkFereYPTZ@phenom.ffwll.local>
Date:   Fri, 19 Nov 2021 17:11:07 +0100
From:   Daniel Vetter <daniel@...ll.ch>
To:     Simon Ser <contact@...rsion.fr>
Cc:     Daniel Vetter <daniel@...ll.ch>,
        Pekka Paalanen <ppaalanen@...il.com>,
        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, 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.

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