Hi, On Wed, Nov 17, 2021 at 12:47 PM Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > > On Wed, Nov 17, 2021 at 10:38:58AM -0800, Brian Norris wrote: > > On Fri, Nov 12, 2021 at 4:52 PM Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > > > > (Snip other comments; they seem reasonable, and I'll factor them into > > the next version) > > > > > I guess one random thought I had is whether there would be an > > > appropriate place to put this that _wasn't_ in DRM. I still wonder > > > whether we'll ever try to upstream something like the cpufreq boost > > > driver that we're carrying around and using in Chrome OS. If so, it > > > would want to use these same helpers and it'd be pretty awkward for it > > > to have to reach into DRM. ...any chance we could just land these > > > helpers somewhere more generic? > > > > Yeah, I was torn on what to do here as well. I'd rather land something > > than nothing, and when reading past conversations, it sounded like > > Dmitry didn't want this kind of thing in drivers/input/ [1]. I'd love > > to be wrong here though. > > I simply feel that input_handler is already a very simple abstraction > and trying to specialize it to simplify users further is not productive. I guess, if nothing else, it would be nice to avoid the tables that we'd have to copy between DRM and cpufreq: the set of input devices that are likely a sign that the user is interacting with the device. It always seemed weird to copy that from place to place and if there's ever a new input device to add it would be annoying to have to update it everywhere. It would be nice to avoid some of the other boilerplate code here connecting things together when all we need is a callback, but I agree that if those were copied it wouldn't be the end of the world. -Doug
