On Sun, Aug 15, 2021 at 10:31 PM Marek Vasut <marex@xxxxxxx> 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.