On Wed, May 14, 2025 at 5:22 AM Jani Nikula <jani.nik...@linux.intel.com> wrote:
> On Tue, 13 May 2025, Maxime Ripard <mrip...@kernel.org> wrote: > > Is it really surprising you get some pushback when you are using a > > design that is the complete opposite to what every user of it for the > > last decade has been doing? > > The opposite is also true. > > If you create a design that does not cleanly fit the model of the > biggest drivers in the subsystem, and expect massive refactors just for > the sake of conforming to the design to be able to use any of it, you'll > also get pushback. > > > This one is usable, but you rule out the way you could use it. > > I think you're off-hand and completely dismissing the amount of work it > would be. And still I'm not even ruling it out, but there has to be a > way to start off in small incremental steps, and use the parts that > work. And it's not like we're averse to refactoring in the least, > everyone knows that. > > > I guess it's clear now that you won't consider anything else. I wonder > > why you started that discussion in the first place if you already have > > a clear mind on how to get things moving forward. > > I pointed out what I think is a bug in drm_panel, with nothing but good > intentions, and everything snowballed from there. > > There has to be a middle ground instead of absolutes. Otherwise we'll > just end up in deeper silos. And more arguments. > > BR, > Jani. > > Jani, Maxime, Thinking out loud of different solutions we can have to make sure we take this forward. Is it possible to have a variant of drm_panel_follower for the non ARM devices? That way if at any point in the future, the drm_panel_follower infrastructure has to be used, the refcounting allocation can be bypassed? Adding Uma and VIlle to the thread here. Thanks! Anusha > -- > Jani Nikula, Intel > >
