Support for other devices?

[rembo10]

Hey - could this be generalized to support other devices? I have a Boox Nova Pro which uses the Maxim 17135 pmic (which I thought was also used on the Remarkable 2 but I guess not?).... but if it's purely software based, and not using the imx epdc, wouldn't it also work?

[matteodelabre]

Hi! I’m open to this idea, and I think it could very well be feasible. The first goal will be to bring full support for the reMarkable, since it’s the only E-Ink device I own and can test things on.

[rembo10]

Sounds good! Thanks! I think I'll test it on my device, it doesn't seem like too many changes are necessary. It seems like only the path to the temperature sensor and the imx specific framebuffer?

[matteodelabre]

Pretty much, yes. You’ll also need to supply a path to the waveform file (.wbf) for the EPD panel of your device.

[rembo10]

Cool, thanks for the help. I'll give it a try today

[rembo10]

Hey so just to double check something... waved is interacting with the framebuffer.... which interacts with the hardware epdc? I believe my device (rockchip 3288 based), and doesn't have a hardware epdc (everything is done in software from what I can tell).... so maybe it won't be able to be adapted so easily?

[matteodelabre]

Hi! waved is not using the hardware EPDC but instead directly drives the EPD (through the mxsfb driver). So it should be possible to make it work with your device. Do you have any details on how the EPD is wired to the SoC? We would need to investigate whether it can be driven the same way as the reMarkable’s EPD.

[rembo10]

Thanks so much for the reply. I know you're mostly focused on the remarkable, so I don't want to detract to much from that.

I'm not 100% sure how it all works, which is probably why I was confused about what waved was doing. I think the panel is hooked up through an LVDS interface. In the decompiled dtb, I see the panel was just being driven by the "panel-simple" driver.

And then there is the maxim 17135 e-ink pmic (that's another reason I was confused - I couldn't see where waved was interacting with the eink pmic except for getting the temperature).

I really appreciate your replies, it's giving me a lot of insight into how the hardware works. And I am hopeful again that it will work! If there's any more information I can give you, please just ask and I'd be happy to provide it.

[matteodelabre]

Thank you! Even though I’m focused on the reMarkable, I think considering other devices might give us more insight as to how all of this works, so the information you’re sharing is really useful.

I'm not 100% sure how it all works, which is probably why I was confused about what waved was doing. I think the panel is hooked up through an LVDS interface. In the decompiled dtb, I see the panel was just being driven by the "panel-simple" driver.

Alright, this seems pretty similar to the reMarkable then. Except from what I can tell, “panel-simple” is DRM-based while the “mxsfb” driver which waved currently interacts with is fbdev-based, so we may need some tweaks there.

And then there is the maxim 17135 e-ink pmic (that's another reason I was confused - I couldn't see where waved was interacting with the eink pmic except for getting the temperature).

I’m not 100% sure here, but I think the PMICs are only used for temperature readings and VCOM control. On the reMarkable, the VCOM value seems to be set to -1.45 V somewhere along the boot sequence so waved does not need to set it itself (although it wouldn’t hurt I guess).

[rembo10]

I appreciate that you're looking at it from this angle.

So once the vcom value is set (I think it's set in the dts) - the e-ink IC doesn't need to be interacted with from userspace/the driver? I think that's where I was confused - I thought maybe some signal had to be sent to update the display or something.

On my device, an fb device is registered (maybe the rockchip drm driver does this?), so I think the only thing that might need to be modified is the path.

I was just trying to understand how it all worked before I tried it out...

[alistair23]

Alright, this seems pretty similar to the reMarkable then. Except from what I can tell, “panel-simple” is DRM-based while the “mxsfb” driver which waved currently interacts with is fbdev-based, so we may need some tweaks there.

Correct! But the mainline rM2 kernel will also use the DRM "panel-simple" backend, so it'd be great to support it

[matteodelabre]

So once the vcom value is set (I think it's set in the dts) - the e-ink IC doesn't need to be interacted with from userspace/the driver? I think that's where I was confused - I thought maybe some signal had to be sent to update the display or something.

At least on the reMarkable, using the display interface is enough. We actually directly drive the individual cells of the display through that interface: for each frame, we choose between applying a negative charge, a positive charge, or no charge to each cell. Sorry that there’s no proper documentation for all of this yet, I plan on writing some when a first working version is ready.

On my device, an fb device is registered (maybe the rockchip drm driver does this?), so I think the only thing that might need to be modified is the path.

Interesting, we’d have to investigate more on that. Do you know whether the “panel-simple” driver used on your device has any changes as compared to the mainline version?

[rembo10]

That's awesome.

Alright, so... I've modified waved to look for the rockchip framebuffer, and it's manually pointing to the max17135 temp sensor and wbf file (for now)... But I got this error:
The framebuffer has invalid dimensions
So I started digging a bit. Do you know what's up with the weird framebuffer resolutions on the rm2?

[matteodelabre]

Oops, sorry I forgot to get back to your message! So, as you’ve probably noticed, there are a bunch of hardcoded sizes in display.hpp. (I’d like to clean these up in the future and get them directly from fb_varinfo/fb_fixinfo, but I’m not sure if it’s a reliable source for the dimensions we need to know about in waved.) Could you share what the fb_varinfo/fb_fixinfo looks like for your device? On the rM2 it looks like this, as seen from gdb:

(gdb) p display.var_info
$1 = {xres = 260, yres = 1408, xres_virtual = 260, yres_virtual = 23936, xoffset = 0, yoffset = 1408,
  bits_per_pixel = 32, grayscale = 0, red = {offset = 16, length = 8, msb_right = 0}, green = {
    offset = 8, length = 8, msb_right = 0}, blue = {offset = 0, length = 8, msb_right = 0}, transp = {
    offset = 0, length = 0, msb_right = 0}, nonstd = 0, activate = 0, height = 0, width = 0,
  accel_flags = 0, pixclock = 28800, left_margin = 1, right_margin = 1, upper_margin = 1,
  lower_margin = 143, hsync_len = 1, vsync_len = 1, sync = 0, vmode = 0, rotate = 0, colorspace = 0,
  reserved = {0, 0, 0, 0}}
(gdb) p display.fix_info
$2 = {id = "mxs-lcdif\000\000\000\000\000\000", smem_start = 2848980992, smem_len = 33554432,
  type = 0, type_aux = 0, visual = 2, xpanstep = 0, ypanstep = 1, ywrapstep = 1, line_length = 1040,
  mmio_start = 0, mmio_len = 0, accel = 0, capabilities = 0, reserved = {0, 0}}

[rembo10]

Hey, no it's all good, I also got a little bit sidetracked. I'm trying to do all this crazy cross compilation with NixOS to get everything running and am having a little issue at the moment that I need to sort out. But once that's done I'll start testing again.

But I think maybe something worked a little bit.... I noticed a few pixels in the very upper right corner had changed. So even that is a start!