Hi, >From a user-space point-of-view, we discussed about this patch on IRC a few days ago [1]. Since this adds a policy decision we think it'd be best to allow user-space to control this behavior.
Also cc Pekka. Thanks, Simon [1]: https://oftc.irclog.whitequark.org/dri-devel/2021-11-07#1636276286-1636273745; > A variety of applications have found it useful to listen to > user-initiated input events to make decisions within a DRM driver, given > that input events are often the first sign that we're going to start > doing latency-sensitive activities: > > * Panel self-refresh: software-directed self-refresh (e.g., with > Rockchip eDP) is especially latency sensitive. In some cases, it can > take 10s of milliseconds for a panel to exit self-refresh, which can > be noticeable. Rockchip RK3399 Chrome OS systems have always shipped > with an input_handler boost, that preemptively exits self-refresh > whenever there is input activity. > > * GPU drivers: on GPU-accelerated desktop systems, we may need to > render new frames immediately after user activity. Powering up the > GPU can take enough time that it is worthwhile to start this process > as soon as there is input activity. Many Chrome OS systems also ship > with an input_handler boost that powers up the GPU. > > I implement the first bullet in this series, and I also compared with > some out-of-tree patches for the second, to ensure this could be useful > there too. > > Past work on upstreaming a variety of Chromebook display patches got > held up for this particular feature, as there was some desire to make it > a bit more generic, for one. See the latest here: > > > https://lore.kernel.org/all/20180405095000.9756-25-enric.balle...@collabora.com/ > [PATCH v6 24/30] drm/rockchip: Disable PSR on input events > > I significantly rewrote this to adapt it to the new common > drm_self_refresh_helpers and to add a new drm_input_helper thin library, > so I only carry my own authorship on this series. > > Admittedly, this "drm_input_helper" library is barely DRM-specific at > all, except that all display- and GPU-related input-watchers are likely > to want to watch similar device behavior (unlike, say, rfkill or led > input_handler code). The approximate consensus so far seems to be that > (a) this isn't much code; if we need it for other subsystems (like, > cpufreq-boost), it's easy to implement similar logic > (b) input subsystem maintainers think the existing input_handler > abstraction is good enough > So, I keep the thin input helper in drivers/gpu/drm/. > > v1: > https://lore.kernel.org/all/20211103234018.4009771-1-briannor...@chromium.org/ > > Changes in v2: > - Honor CONFIG_INPUT dependency, via new CONFIG_DRM_INPUT_HELPER > - Remove void*; users should use container_of() > - Document the callback context > - Delay PSR re-entry, when already disabled > - Allow default configuration via Kconfig and modparam > - really CC dri-devel@lists.freedesktop.org (oops!) > > Brian Norris (2): > drm/input_helper: Add new input-handling helper > drm/self_refresh: Disable self-refresh on input events > > drivers/gpu/drm/Kconfig | 22 ++++ > drivers/gpu/drm/Makefile | 2 + > drivers/gpu/drm/drm_input_helper.c | 143 ++++++++++++++++++++++ > drivers/gpu/drm/drm_self_refresh_helper.c | 98 ++++++++++++--- > include/drm/drm_input_helper.h | 41 +++++++ > 5 files changed, 292 insertions(+), 14 deletions(-) > create mode 100644 drivers/gpu/drm/drm_input_helper.c > create mode 100644 include/drm/drm_input_helper.h > > -- > 2.34.0.rc1.387.gb447b232ab-goog
