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.) 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
Attachment:
pgpUcH4HCNMiB.pgp
Description: OpenPGP digital signature
