On Mon, Aug 16, 2021 at 5:55 PM Marek Vasut <marex@xxxxxxx> wrote:
On 8/16/21 9:34 AM, Alistair Francis wrote:
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.
Do you have fbdev emulation enabled ? Does /dev/fbX exist ?
I do and /dev/fb0 exists
What sort of messages do you get and from where ?
This is the error I get:
xochitl[252]: Error writing variable information: Invalid argument...
xochitl is the proprietary userspace code. I don't really have a good
idea of what that error would mean.
I also see this:
Framebuffer has wrong id: "mxcfb"
You could run strace on the application to see how it communicates with
the old driver via the ioctl interface and compare it with the fbdev
emulation on the new driver, maybe there is some odd ioctl which is not
emulated.
I had a quick look at this.
xochitl does a lot more than just controls the display, it interacts
with lots of other hardware and strace produces a lot of logs. I also
don't see the error when manually starting it, only at boot (but it
still doesn't work).
A quick run with
strace -f xochitcl
and I don't even see an access to /dev/fb0, so I'm not sure where the
accesses are coming from.