linux-kernel - Re: [PATCH v1 0/4] fbtft: Unorphan the driver for maintenance

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fa673f9c-2654-755e-450d-d29b95c1ce9d@suse.de>
Date:   Wed, 26 Jan 2022 12:51:17 +0100
From:   Thomas Zimmermann <tzimmermann@...e.de>
To:     Helge Deller <deller@....de>,
        Javier Martinez Canillas <javierm@...hat.com>,
        Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Andy Shevchenko <andy@...nel.org>, linux-fbdev@...r.kernel.org,
        Michael Hennerich <michael.hennerich@...log.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org,
        Phillip Potter <phil@...lpotter.co.uk>,
        Carlis <zhangxuezhi1@...ong.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Lee Jones <lee.jones@...aro.org>,
        Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: [PATCH v1 0/4] fbtft: Unorphan the driver for maintenance

Hi

Am 26.01.22 um 12:31 schrieb Helge Deller:
> 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.
> 
> In the same manner there are old graphic cards or very specific devices
> (e.g. more than 3 years old or only used in niche-use cases)
> which have limitations and thus can't easily be ported to DRM.
> For those it's still acceptable to include them as legacy fbdev driver,
> because the work needed in DRM to support such cards or to be able that
> they run fast enough with DRM just doesn't pay off the efforts which are
> needed to keep them as DRM driver.
> 
> Would that be acceptable?

No. As we've said several times, there's nothing stopping any device 
from being supported by DRM. If something's missing or slow, it's 
because no one has had that issue so far. We welcome patches patches to 
fix such problems.

Best regards
Thomas

> 
> Helge

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

Download attachment "OpenPGP_signature" of type "application/pgp-signature" (841 bytes)