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'm not sure where else this would belong though -- either in the > producing subsystem (input) or the consuming one(s) (drm, cpufreq). We > could make up some odd middle ground I suppose (lib/?), but that seems > pretty artificial. > > I guess one question is, what is this abstracting, and is that > abstraction actually a shared need for multiple subsystems? I think > the abstraction is, "impending user activity; <component X> should > prepare itself". That general need is exactly the same for the cases > I'm aware of. And if there is any tuning needed (e.g., ignore input > device Y; or turn the whole thing off, because we're ignoring input > for now), that would also seem to be a shared need. > > Anyway, back to my first paragraph: I'll plan on keeping this as-is > (as a DRM helper) unless I hear otherwise from input folks. > > Brian > > [1] https://lore.kernel.org/all/20180416174117.GA77055@dtor-ws/ Thanks. -- Dmitry
