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

Reply via email to