linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Zimmermann <tzimmermann@suse.de>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Andy Shevchenko <andy@kernel.org>,
	linux-fbdev@vger.kernel.org,
	Michael Hennerich <michael.hennerich@analog.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Helge Deller <deller@gmx.de>,
	linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	Phillip Potter <phil@philpotter.co.uk>,
	Carlis <zhangxuezhi1@yulong.com>,
	Lee Jones <lee.jones@linaro.org>,
	Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: [PATCH v1 0/4] fbtft: Unorphan the driver for maintenance
Date: Wed, 26 Jan 2022 16:02:23 +0100	[thread overview]
Message-ID: <df377b35-8913-a8c6-760b-073f462780cc@suse.de> (raw)
In-Reply-To: <YfFNhsPr4kS2/LXa@smile.fi.intel.com>


[-- Attachment #1.1: Type: text/plain, Size: 2225 bytes --]

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. 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] 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.

As it stands, 90s PCI hardware is currently supported by DRM's simpledrm 
as long as the device has VESA. 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.

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.

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

Best regards
Thomas

[1] 
https://gitlab.freedesktop.org/tzimmermann/linux/-/tree/fbconv-plus-drivers
[2] 
https://lore.kernel.org/dri-devel/16f9e064-99cc-4205-d03e-ae41ed034309@redhat.com/T/#t

> 

-- 
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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

  reply	other threads:[~2022-01-26 15:02 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-25 20:21 [PATCH v1 0/4] fbtft: Unorphan the driver for maintenance Andy Shevchenko
2022-01-25 20:21 ` [PATCH v1 1/4] fbtft: Unorphan the driver Andy Shevchenko
2022-01-26  8:31   ` Greg Kroah-Hartman
2022-01-26 10:31     ` Daniel Vetter
2022-01-26 11:17       ` Helge Deller
2022-01-26 11:26         ` Greg Kroah-Hartman
2022-01-26 13:12           ` Andy Shevchenko
2022-01-26 13:46             ` Javier Martinez Canillas
2022-01-26 14:08               ` Andy Shevchenko
2022-01-26 14:10                 ` Andy Shevchenko
2022-01-26 14:15                   ` Javier Martinez Canillas
2022-01-31  8:29                     ` Javier Martinez Canillas
2022-01-31  9:18                       ` Thomas Zimmermann
2022-01-31 10:18                         ` Javier Martinez Canillas
2022-01-31 10:28                           ` Thomas Zimmermann
2022-02-01 17:00                             ` Geert Uytterhoeven
2022-02-01 17:06                               ` Daniel Vetter
2022-02-01 19:00                               ` Thomas Zimmermann
2022-01-31 11:36                       ` Andy Shevchenko
2022-01-31 12:08                         ` Javier Martinez Canillas
2022-01-31 13:23                           ` Andy Shevchenko
2022-01-31 13:24                             ` Andy Shevchenko
2022-01-31 13:55                             ` Javier Martinez Canillas
2022-01-31 14:06                               ` Andy Shevchenko
2022-01-26 17:34                 ` Jani Nikula
2022-01-26 11:27         ` Daniel Vetter
2022-01-26 13:14           ` Andy Shevchenko
2022-01-26 11:31         ` Thomas Zimmermann
2022-01-26 13:13           ` Andy Shevchenko
2022-01-26 13:07         ` Andy Shevchenko
2022-01-26 13:06       ` Andy Shevchenko
2022-01-26 13:22         ` Daniel Stone
2022-01-25 20:21 ` [PATCH v1 2/4] fbtft: Move driver out from staging Andy Shevchenko
2022-01-25 20:21 ` [PATCH v1 3/4] fbtft: Kill outdated documentation Andy Shevchenko
2022-01-25 20:21 ` [PATCH v1 4/4] fbtft: Replace 'depends on FB_TFT' by 'if FB_TFT ... endif' Andy Shevchenko
2022-01-25 20:40   ` Randy Dunlap
2022-01-26  8:54   ` Joe Perches
2022-01-26 13:02     ` Andy Shevchenko
2022-01-26  8:52 ` [PATCH v1 0/4] fbtft: Unorphan the driver for maintenance Thomas Zimmermann
2022-01-26 10:02   ` Andy Shevchenko
2022-01-26 10:04     ` Andy Shevchenko
2022-01-26 10:28       ` Dan Carpenter
2022-01-26 12:37         ` Javier Martinez Canillas
2022-01-26 12:56           ` Greg Kroah-Hartman
2022-01-26 13:18             ` Andy Shevchenko
2022-01-26 13:44               ` Javier Martinez Canillas
2022-01-26 13:19             ` Javier Martinez Canillas
2022-01-26 13:36               ` Andy Shevchenko
2022-01-26 13:17           ` Andy Shevchenko
2022-01-26 10:43     ` Daniel Vetter
2022-01-26 10:47     ` Greg Kroah-Hartman
2022-01-26 10:52       ` Daniel Vetter
2022-01-26 11:15         ` Greg Kroah-Hartman
2022-01-26 13:26           ` Andy Shevchenko
2022-01-26 13:24         ` Andy Shevchenko
2022-01-26 10:59     ` Helge Deller
2022-01-26 11:18       ` Javier Martinez Canillas
2022-01-26 11:24         ` Daniel Vetter
2022-01-26 11:38           ` Helge Deller
2022-01-26 11:45             ` Sven Schnelle
2022-01-26 13:30             ` Andy Shevchenko
2022-01-27  9:18               ` Maxime Ripard
2022-01-26 11:31         ` Helge Deller
2022-01-26 11:38           ` Greg Kroah-Hartman
2022-01-26 11:51             ` Helge Deller
2022-01-26 12:15               ` Greg Kroah-Hartman
2022-01-26 11:51           ` Thomas Zimmermann
2022-01-26 13:27         ` Andy Shevchenko
2022-01-26 13:47           ` Javier Martinez Canillas
2022-01-26 14:11             ` Andy Shevchenko
2022-01-26 14:18               ` Javier Martinez Canillas
2022-01-26 14:24                 ` Greg Kroah-Hartman
2022-01-26 14:45                   ` Dan Carpenter
2022-01-26 22:31                     ` Daniel Vetter
2022-01-27  6:29                       ` Dan Carpenter
2022-01-27 10:32                         ` Dmitry Vyukov
2022-01-27 11:11                           ` Daniel Vetter
2022-01-27 16:34                             ` Dmitry Vyukov
2022-01-26 22:37                   ` Daniel Vetter
2022-01-26 11:41       ` Thomas Zimmermann
2022-01-26 13:32         ` Andy Shevchenko
2022-01-26 15:02           ` Thomas Zimmermann [this message]
2022-01-26 15:33             ` Andy Shevchenko
2022-01-26 15:54             ` Helge Deller
2022-01-26 13:15 ` Noralf Trønnes
2022-01-26 13:21   ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=df377b35-8913-a8c6-760b-073f462780cc@suse.de \
    --to=tzimmermann@suse.de \
    --cc=andy.shevchenko@gmail.com \
    --cc=andy@kernel.org \
    --cc=deller@gmx.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hkallweit1@gmail.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=michael.hennerich@analog.com \
    --cc=phil@philpotter.co.uk \
    --cc=zhangxuezhi1@yulong.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).