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]

Date:   Wed, 26 Jan 2022 16:54:35 +0100
From:   Helge Deller <deller@....de>
To:     Thomas Zimmermann <tzimmermann@...e.de>,
        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>,
        Lee Jones <lee.jones@...aro.org>,
        Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: [PATCH v1 0/4] fbtft: Unorphan the driver for maintenance

On 1/26/22 16:02, Thomas Zimmermann wrote:
> Hi
>
> Am 26.01.22 um 14:32 schrieb Andy Shevchenko:
>> On Wed, Jan 26, 2022 at 12:41:41PM +0100, Thomas Zimmermann wrote:
>>> Am 26.01.22 um 11:59 schrieb Helge Deller:
>>
>> ...
>>
>>
>>> It's always for the same reason: the hw is old and devs have moved on.
>>
>> It's pity to have a working system with an old hardware that no one in
>> the kernel community gives a shit about because simply they are not in
>> the same boat. Try to be on the people's position...
>
> Yes, I do care about old hardware.

Yes, I know. I saw various articles about it.

> I made helpers for converting fbdev drivers to DRM. I even made the
> initial commits for those drivers where I could find the HW on Ebay. [1]> [1] https://gitlab.freedesktop.org/tzimmermann/linux/-/tree/fbconv-plus-drivers

Just out of curiosity, does the tgui driver you patched there
is now supported by DRM? I couldn't find it (just the tridentfb fbdev driver),
so I assume it's somehow handled by simpledrm instead?

> I made sure that every single of them at least gets fbcon onto the
> screen. So interested devs could start immediately. Yet, no one ever
> showed up to convert even a single driver.
Both Geert wrote about that he was trying to convert a driver. The same
is true for Sven where he came up with a prelimarary visualizefx driver...
Both had issues which currently prevent that those drivers get finished.

> As it stands, 90s PCI hardware is currently supported by DRM's
> simpledrm as long as the device has VESA.

Good. Some of the drivers in fbdev are for non-x86 architectures
and don't have a VESA BIOS. Is is possible that simpledrm could (theoretically)
support those too?

> The performance is at least usable on AthlonXP-era computers. Now the
> owners of these devices at least have a chance of using modern
> graphics userspace.
Yes.

> That userspace is important: graphics drivers don't live in a vacuum.
> There's no point in having one if it requires extra support from all
> other components. And there's more:
>
>  * Occasionally, fbdev gets in the way of DRM. Just this week, we fixed a related bug. [2]
>
>  * Fbdev's mmap semantics is the reason why it's hard to do fast in DRM.
>
>  * Maintaining both stacks, DRM and fbdev, adds work to kernel, userspace and distro devs.
>
> Therefore, anything we do that keeps fbdev alive is a step backwards and a burden on the overall Linux graphics community.

That's understood and I don't disagree.
The earlier drivers are converted to DRM the better.
I probably don't even have any issues with dropping fbdev & drivers for the
x86, ARM64, s390x & ppc64 platforms - I think many older cards aren't used either
used (anymore),
or your simpledrm may cover the most common cards.
I think the patches we currently jointly develop to disable fbcon acceleration
is exactly going into this direction.

The problems I see are mostly on non-x86 architectures or corner-case usages
like embedded devices or special machines. They may be oldish, but still being used.
Those machines would completely loose their console without fbdev.

> Please excuse my ranting, but fbdev proponents seem to be ignorant to
> all these points. It's apparently all about 'my console is slow'.

Your ranting is fair, but I wouldn't say I'm ignorant to your arguments.
Of course performance is relevant, or would you exchange your car which
today is capable to drive 100 mph with another car which only
drives a maximum 10 mph?  (Yes, that's around the factor of speed decrease I see).
Or even worse: suddenly not being allowed/able to drive your car at all?

Helge