Messages in this thread | | | From | Alistair Francis <> | Date | Mon, 16 Aug 2021 17:34:17 +1000 | Subject | Re: Revert "video: fbdev: mxsfb: Remove driver" |
| |
On Sun, Aug 15, 2021 at 10:31 PM Marek Vasut <marex@denx.de> wrote: > > On 8/15/21 2:16 PM, Alistair Francis wrote: > > Hello, > > > > Commit f225f1393f034 "video: fbdev: mxsfb: Remove driver" removed the > > mxsfb fbdev driver. > > > > I am now working on getting mainline Linux running on the reMarkable 2 > > eInk reader [1]. Unfortunately the rM2 doesn't use the standard EPD > > controller on the i.MX SoC, but instead uses the LCD controller. > > > > eInk panels are complex to control and require writing temperature > > dependent waveforms. As these waveforms are proprietary [2] the rM > > team runs closed source software called SWTCON in userspace to control > > the panel [3]. > > > > This closed source software expects the fbdev mxsfb driver and it > > doesn't work with the DRM mxsfb driver (at least not that I can get it > > to). > > > > The NXP fork of Linux also re-adds the fbdev driver [4], so they also > > see some uses for it. > > > > I was wondering if the community would be open to re-adding the fbdev > > mxsfb driver to mainline? It could be re-added with a different > > dt-binding so that it is not used by default and only enabled for > > boards when required (like for the rM2). > > > > 1: https://remarkable.com/store/remarkable-2 > > 2: https://goodereader.com/blog/e-paper/e-ink-waveforms-are-a-closely-guarded-secret > > 3: https://remarkablewiki.com/tech/rm2_framebuffer > > 4: https://source.codeaurora.org/external/imx/linux-imx/log/drivers/video/fbdev/mxsfb.c?h=lf-5.10.35-2.0.0 > > +CC Sam. > > What sort of special thing does your proprietary userspace do that > cannot be added to the DRM driver or the fbdev emulation (if needed) ?
It's hard to tell. When using the DRM driver I get cryptic errors about the frame buffer not being available. It's difficult to know what is going on as I don't have access to any of the source. I suspect the userspace code could be updated to use the DRM driver, but we would need the reMarkable devs to do that.
There is some effort to re-implement the proprietary user space swtcon (https://github.com/timower/rM2-stuff#swtcon), but it seems to have stalled. It wouldn't be impossible to get swtcon to work with the DRM driver, but it would require a very large amount of reverse engineering, that probably will never happen.
I wanted to see what the thoughts were on re-adding the fbdev mxsfb driver. The commit message just says that because there is a DRM driver we no longer need the fbdev one, but here is a case for the fbdev driver. I was thinking that continuing to support the fbdev mxsfb driver wouldn't be too much of a maintenance burden (but that's obviously up to you). The NXP tree also seems to think the fbdev driver is worth keeping around.
Alistair
| |