On Wed, Jan 26, 2022 at 03:18:14PM +0100, Javier Martinez Canillas wrote: > On 1/26/22 15:11, Andy Shevchenko wrote: > > On Wed, Jan 26, 2022 at 02:47:33PM +0100, Javier Martinez Canillas wrote: > >> On 1/26/22 14:27, Andy Shevchenko wrote: > >>> On Wed, Jan 26, 2022 at 12:18:30PM +0100, Javier Martinez Canillas wrote: > >>>> On 1/26/22 11:59, Helge Deller wrote: > >>>>> On 1/26/22 11:02, Andy Shevchenko wrote: > > > > ... > > > >>>>>> P.S. For the record, I will personally NAK any attempts to remove that > >>>>>> driver from the kernel. And this is another point why it's better not > >>>>>> to be under the staging. > >>>>> > >>>>> I agree. Same as for me to NAK the disabling of fbcon's acceleration > >>>>> features or even attempting to remove fbdev altogether (unless all > >>>>> relevant drivers are ported to DRM). > >>>> > >>>> But that will never happen if we keep moving the goal post. > >>>> > >>>> At some point new fbdev drivers should not be added anymore, otherwise > >>>> the number of existing drivers that need conversion will keep growing. > >>> > >>> This thread is not about adding a new driver. > >> > >> It was about adding a new drivers to drivers/video/ (taken from staging). > > > > Does it mean gates are open to take any new fbdev drivers to the staging? > > If not, I do not see a point here. > > > > Good question. I don't know really. > > But staging has always been more flexible in what's accepted there and > that's why some distros avoid to enable CONFIG_STAGING=y in the kernel. And that's why if you load a staging driver, it enables TAINT_CRAP in your runtime flags :)
