Can we override the screen driver part to make it 60hz?

[rtmtree]

https://gitlab.com/zephray/caster https://gitlab.com/zephray/glider

There is a promising open-source project where the guy is designing a custom display controller and driver board. This allows almost any e-ink screen to support up to 60Hz refresh rate with low input lag, though there are some trade-offs (see video).

My question is whether it's possible to port this firmware to the Pinenote, overriding the existing screen driver and increase the refresh rate to 60Hz or any lower. Would this need to be done at the kernel level, and what challenges might arise in adapting the firmware to the Pinenote's hardware?

I’m new to display drivers and any advice would be appreciated. Thanks!

[m-weigand]

Unfortunately, not. The links you provided link to a completely different hardware. We are bound to the hardware capabilities of the Pinenote, meaning the Rockchip rk3566 chip. While there probably is still quite some potential for improvements, we probably will not reach that kind of fast refreshes.

However, take look at the various videos we have of reachable PineNote performance:

• https://github.com/m-weigand/mw_pinenote_misc/blob/main/videos/20220807_firefox_video_and_surfing_small.mp4
• More videos can be found here: https://github.com/m-weigand/mw_pinenote_misc/tree/main/videos

[rtmtree]

Thanks for the reply. I looked at the videos and it shows a stunning performance.

[rtmtree]

I understand the hardware differences can pose a challenge. However, if I want to focus on improving the existing E Ink driver, where should I start? Does this lie at the kernel level, or can I override the driver from the Linux user space?

[m-weigand]

That's a complicated question ;-) Right now we are focusing on preparing the Debian image for the next PineNote batch, leaving not much time for planning with regard to the ebc driver. I think it would be best to discuss this in the PineNote chat.

Anyway, the driver resides completely in kernel space, and thus must be modified there. Probably the first thing to do would be proper profiling to identify any delays that could be improved.

Another thing would be to work on facilitating the rga2 hardware of the rk3566 chip to do Y4 and dithering in hardware, instead of software. However, this is a user space issue and must be tackled in the compositor.

[m-weigand]

For future coordination, at least within this sphere of PN software, I opened up the meta issue: https://github.com/PNDeb/pinenote-debian-image/issues/78

[rtmtree]

thanks for the process.