Messages in this thread | | | Date | Wed, 26 Jan 2022 12:41:41 +0100 | Subject | Re: [PATCH v1 0/4] fbtft: Unorphan the driver for maintenance | From | Thomas Zimmermann <> |
| |
Hi
Am 26.01.22 um 11:59 schrieb Helge Deller: > On 1/26/22 11:02, Andy Shevchenko wrote: >> On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann <tzimmermann@suse.de> wrote: >>> Am 25.01.22 um 21:21 schrieb Andy Shevchenko: >>>> Since we got a maintainer for fbdev, I would like to >>>> unorphan fbtft (with the idea of sending PRs to Helge) >>>> and move it out of staging since there is no more clean >>>> up work expected and no more drivers either. >>>> >>>> Thoughts? > > Personally I'm in favour of this proposal and would be happy > to take patches for it through the fbdev git tree. > Reasoning below... > >>> But why? We already have DRM drivers for some of these devices. >> >> No, we do not (only a few are available). > > seems to be 2 out of 10 (according to the other mails)
FYI it's ili9163 and hx8357d. Both of those are of the same size ('wc -l') on DRM and fbdev: 200 to 300 loc.
>>> Porting the others to DRM is such a better long-term plan. OTOH, >>> as no one has shown up and converted them, maybe they should be >>> left dead or removed entirely. >> >> As I mentioned above there are devices that nobody will take time to >> port to a way too complex DRM subsystem. But the devices are cheap and >> quite widespread in the embedded world. I'm in possession of 3 or 4 >> different models and only 1 is supported by tiny DRM. >> >> On top of that the subtle fact people forgot about FBTFT is that it >> does support parallel interface (yes, I know that it's not performant, >> but one of the displays I have is with that type of interface). > > I don't know those devices, but it seems they are still being used. > > And the reasons why they have not been ported to DRM yet is > likely because either lack of man-power, a slow-down with DRM (due to > slow bus connections or increased memory usage with DRM), or > simply that it's used in embedded-like scenarios with a limited > set of userspace applications for which existing fbdev access is sufficient. > > Again, I don't know the reason for this specific devices, but I know > of other devices for which those reasons above are valid. > Just the example I posted yesterday where a simple "time dmesg" needed > unaccelerated 19 seconds compared to 2 seconds with acceleration. > So, as long as acceleration isn't possible with that driver in > DRM, DRM isn't a preferred target where the driver should be ported. > > So, I'd be fine to take it into fbdev tree. > > Interestingly there is another fbdev driver in staging (sm750fb) with > similiar issues. The TODO mentions a porting to DRM which happens at > https://gitlab.com/sudipm/sm750/tree/sm750 > but the last commit there is 3 years ago. I don't know why it wasn't > continued yet.
It's always for the same reason: the hw is old and devs have moved on.
Best regards Thomas
-- 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 [unhandled content-type:application/pgp-signature] | |