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@xxxxxxx> 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
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
