On Mon, Nov 22, 2021 at 11:43:42AM +0200, Pekka Paalanen wrote: > On Fri, 19 Nov 2021 17:11:07 +0100 > Daniel Vetter <daniel@xxxxxxxx> 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@xxxxxxxx> 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.) Yeah I was a bit sloppy, but I knew. > 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. Yeah I think just allowing to internall poll on any arbitrary fd sounds like a neat interface. Userspace should then be able to do whatever it wants to. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
