On Wed, Jan 26, 2022 at 12:51:46PM +0100, Helge Deller wrote: > On 1/26/22 12:38, Greg Kroah-Hartman wrote: > > On Wed, Jan 26, 2022 at 12:31:21PM +0100, Helge Deller wrote: > >> On 1/26/22 12:18, Javier Martinez Canillas wrote: > >>> On 1/26/22 11:59, Helge Deller wrote: > >>>> On 1/26/22 11:02, Andy Shevchenko wrote: > >>> > >>> [snip] > >>> > >>>>> 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. > >> > >> Good point, and yes you are right! > >> > >> I think the rule should be something like: > >> > >> New graphics devices (e.g. max. 3 years old from now) usually are > >> capable to be ported to DRM. > >> For those graphics cards we should put a hard stop and not include them > >> as new driver into the fbdev framework. Inclusion for those will only > >> happen as DRM driver. > > > > We made this rule 6 years ago already. > > Very good. > > Was there any decision how to handle drivers which can't use DRM, > or for which DRM doesn't make sense? We fix up DRM to handle such devices. > So the best way forward regarding those fbtft drivers is probably what > you suggested: Split them and move those DRM-capable drivers to DRM, > the others to fbdev, right? No, port those that work to DRM and just delete the rest as no one is using them. thanks, greg k-h
