Date:   Fri, 12 May 2023 09:14:06 +0200
From:   Thomas Zimmermann <tzimmermann@...e.de>
To:     Helge Deller <deller@....de>, Sui Jingfeng <15330273260@....cn>,
        geert@...ux-m68k.org, javierm@...hat.com, daniel@...ll.ch,
        vgupta@...nel.org, chenhuacai@...nel.org, kernel@...0n.name,
        davem@...emloft.net, arnd@...db.de, sam@...nborg.org
Cc:     linux-fbdev@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        linux-arch@...r.kernel.org, linux-snps-arc@...ts.infradead.org,
        linux-kernel@...r.kernel.org, linux-ia64@...r.kernel.org,
        loongarch@...ts.linux.dev, linux-m68k@...ts.linux-m68k.org,
        sparclinux@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-parisc@...r.kernel.org
Subject: Re: [PATCH v6 1/6] fbdev/matrox: Remove trailing whitespaces

Hi

Am 11.05.23 um 19:02 schrieb Helge Deller:
> On 5/11/23 16:27, Thomas Zimmermann wrote:
>>>> But the work I do within fbdev is mostly for improving DRM.
>>>
>>> Sure.
>>>
>>>> For the
>>>> other issues in this file, I don't think that matroxfb should even be
>>>> around any longer. Fbdev has been deprecated for a long time. But a
>>>> small number of drivers are still in use and we still need its
>>>> framebuffer console. So someone should either put significant effort
>>>> into maintaining fbdev, or it should be phased out. But neither is
>>>> happening.
>>>
>>> You're wrong.
>>
> 
>> I'm not. I don't claim that these drivers are all broken. But fbdev
>> as a whole is bit-rotting and no one attempts to address this. There
>> are several recent examples of this:
>>
>> * I recently send out a 100-patches series to improve parameter
>> parsing and avoid memory leaks. That got shot down. I didn't attempt
>> to support parameter parsing for module builds.
> 
> Your work is appreciated and it wasn't shot down, but it wasn't perfect 
> either.
> 
>> * There's been a 15-yrs old bug in fbdev's read/write where they
>> return an incorrect value.
> 
> ?

This one:

https://patchwork.freedesktop.org/patch/534668/?series=116931&rev=2

> 
>> * See the other discussion on this patchset on the state of hitfb.
>>
>> * The fbdev code I recently cleaned up had bugs in how it uses some
>> of fbdev's basic building blocks (see the screen_base/screen_buffer
>> confusion).
> 
> As you said... some (little-used/outdated) drivers may have issues
> which of course show up if one starts to clean up, as you do.
> On a per-driver basis it can make sense to drop a specific driver.
> 
>> * <asm-generic/fb.h> has been in the tree since 2009 and no one
>> attempted to include it until now.
>>
>> None of this is a sign of good maintenance.

Let me add that I'm not pointing fingers at anyone. It's just the 
current status AFAICT.

>> As I've worked on DRM's fbdev emulation a lot, I try to be a good
>> kernel citizen and clean up in fbdev as well when I see a problem.> 
>> But I'd really like to see most of these drivers being moved into
>> staging and deleted soon afterwards. Users will complain about those
>> drivers that are really still required. Those might be worth to spend
>> effort on.
> 
> I'd really like to see a way forward and get the required drivers over to
> DRM, e.g. based on your simpledrm driver.
> If there is a way to get basic on-screen 2D bitblt and fillrect support,
> it would drop the need for most of the fbdev drivers.
> The current way of bitblt'ing from a buffer on regular basis istoo slow 
> for such older cards. Even on new hardware in emulators there
> is a big slowdown visible.

I'd be happy to try to drop the unused/obsolete/broken drivers. For the 
rest, I'd designate fbdev as a graphics console for systems without text 
mode. I think that was the original intention.

> 
>>> You don't mention that for most older machines DRM isn't an
>>> acceptable way to go due to it's limitations, e.g. it's low-speed
>>> due to missing 2D-acceleration for older cards and and it's
>>> incapability to change screen resolution at runtime (just to name
>>> two of the bigger limitations here).
>>
>> You can change resolution at runtime; just not through fbdev ioctls.
>> There's no technical limitation here. No one found any use for this,
>> so it's not there.
> 
> fbdev drivers would need that when ported to DRM.

Why? Userspace would then simply use DRM ioctls to set the display mode.

>>> So, unless we somehow find a good way to move such drivers over to
>>> DRM (with a set of minimal 2D acceleration), they are still
>>> important.
>>
>> 2d acceleration is mostly useful for the framebuffer console.
> 
> and X11
> 
>> You can
>> do that with DRM and drivers have (nouveau). It just didn't make a
>> meaningful difference in most cases.
> 
> if nouveau got it, can't it be done for simpledrm in a generic way too?

Probably no, as it depends on the hardware features. The DRM driver 
would have to implement it's own fbdev support. That's not too 
complicated, but still not portable among drivers.

> 
>>> Actually, I just did test matroxfb and pm2fb successfully a few
>>> days back, and they worked. For some smaller issues I've prepared
>>> patches, which are on hold due conflicts with your latest
>>> file-move-around- and whitespace-changes which are partly in
>>> drm-misc. And I do have some upcoming additional patches for
>>> console support.
> 
> Helge

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

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

Powered by blists - more mailing lists