I was gonna mention that since I couldn’t find information on why the screen brightness wasn’t working. worked like a charm! no flicker, no lockup, all works perfectly now. that said it does seem to only be until next reboot which I did since the brightness slider didn’t come back, however brightnessctl s 35 works perfectly
Correct, you’ll need to reload reform2_lpc every time you boot on Arch.
I’ll look into what’s going on but my guess is that the module tries to load before something is ready. I’ve already been bitten by this with the Ethernet PHY in Arch. I assume that because this Arch install is so minimal lots of things try to load much earlier in the boot process than on Debian.
I boot to the console and run a script instead of using something like gdm. That script reloads the modules that failed to load and then runs sway. You could do something similar in Gnome, though it sounds like your testing is complete.
I really appreciate you booting into Arch and trying this out. I realize the Debian install is much more user friendly, but hopefully this will help us get to the root of why some of the V2 panels have an issue.
You have the V2 panel. You can see it in your dmesg output of pocket_display_v2_init. I’ll have to look at why the sysfs doesn’t populate but probably because I’m not building the latest driver for some reason.
1 Like
Huh, no, I do see this in my Arch linux image:
[alarm@alarm ~]$ cat /sys/devices/platform/fde30000.dsi/fde30000.dsi.0/mnt_pocket_reform_panel_version
2
I am currently booting the rk3588s, so that’s probably the issue. Please run this when you have a moment:
find /sys/devices -name "mnt_pocket_reform_panel_version"
That should tell you where the sysfs attribute is located. Guessing by the dts I’d say you should find it here:
cat /sys/devices/platform/ffd07000.dsi/ffd07000.dsi.0/mnt_pocket_reform_panel_version
But best to check that I’m right. 
find /sys/devices -name "mnt_pocket_reform_panel_version" gave me /sys/devices/platform/soc/ffd00000.bus/ffd07000.dsi/ffd07000.dsi.0/mnt_pocket_reform_panel_version and cat’ing the file gives me the output 2
this is on your arch image for A311D.
Perfect, thank you for checking my guess.
Glad that works for you and confirms you’re running V2.
The names V1 and V2 are a bit misleading. They are not the same panel with different versions, they are different manufacturers. From what I can tell…
V1: JDI LT070ME05000
Japan Display Inc., model LT070ME05000. 7", 1200x1920, MIPI DSI. This panel uses standard MIPI DCS commands and has a proper public datasheet. JDI has been winding down its consumer display fabs, which is why (I’d assume) MNT eventually had to switch suppliers.
V2: Wisecoco TOP070F01A
Sold under the “Wisecoco” brand, manufactured by Shenzhen Huai Zhi (怀智) Technology. Same 7" form factor and connector as the JDI, a drop-in physical replacement (well, kinda). The display controller IC inside is the ER88477, also from Huai Zhi, a part with no public datasheet (that I know of). Initialization requires a vendor unlock sequence followed by a large table of undocumented register writes, none of which are standard DCS.
I think the ER88477 is at the core of the problems we are seeing, but this is a guess. There is no datasheet so timing requirements, register semantics, and error recovery behavior are not publicly available (again, as far as I know). My patches, when you remove all the debug junk, only change two things:
Fix 1: mdelay(100) → msleep(120) in pocket_display_v2_init()
I grew the post-exit-sleep delay before set_display_on by 20ms and changed from a busy-wait to a sleep. The ER88477 probably needs more than 100ms to be ready after exiting sleep mode; 100ms was too tight for some IC production lots, causing intermittent blank screen on reboot. (a guess)
Fix 2: jdi_panel_shutdown() now calls jdi_panel_unprepare()
Previously shutdown only called disable(), leaving the panel regulators live through a reboot. The panel IC was probably never power-cycled, so the next boot’s init sequence was running against a panel that had not been reset. Adding unprepare() was my vain attempt at a clean power-down before the kernel restarts.
Note: gpiod_set_value() was also changed to gpiod_set_value_cansleep() throughout, which eliminates a that kernel warning you were seeing.
If I slim down the patches to just those three things and we continue to see improvements it’s possible that these are actual fixes and not just poking at a misbehaving panel. I still am not convinced these are the right way to fix the problem though.
One way to fix the overarching issue is to break the driver up into 2 drivers, one for the JDI panel and the other for the, let’s call it the “Huai Zhi” panel. The issue arises when we try to boot and need to know which panel we have. U-boot would need to know about the panel if we want to load the right device tree info. The “easiest way” to do this today would probably be via the RP2040 system controller having a setting to select which panel you have. Then u-boot could use the correct dtb (or dtb overlay) and the kernel would only see 1 panel and use the correct driver. phew
I can see why MNT did it the way they did.
1 Like
@stephano I agree with your thoughts on splitting up the panel driver. The new SC+Keyboard FW will make it possible to set such variables/switches in the OLED menu (or via internal USB-ACM or via SPI/kernel driver). I only have to get to the “saving the settings in RP2040 flash” part.
1 Like
no wonder in gnome it says built in display and unknown display in display settings. that makes a lot of sense. if these can be upstreamed after the next system controller update that’d be awesome
Excellent. I’ll start playing around with u-boot. It’s been a while so I need to dust off those brain cells.
I’ll let you know how this goes. Once I have something ready to test I’d much appreciate your help, as we know you saw the same types of panel issues I did.
absolutely, when you have it ready, send me instructions and i’ll try it on my debian install. would it be possible to do it like vX.X.X-beta so i can simply do apt upgrade and it’ll check the repos to see if the full proper version is available so it’ll be a seamless swap after with a sudo apt full-upgrade? idk if so and all things considered having to do it manually is insanely easy.
that said, part of why i ask is if it can be set as a beta (maybe .deb file so it’s as simple as sudo dpkg -i?), and downloaded and installed simply using a bash script, we could get more people trying the beta driver once it’s ready, and they won’t have to touch a thing once the full version comes out meaning barrier to entry and ease of removal would be near 0. it would certainly make the results more rock solid if we can get more users like that. if that’s possible, i can absolutely write a bash script for it when i get my hands on it and install it myself.
I’ll work with the MNT folks to see if that’s possible. Long term that might be a good path to take. In the short term we’ll need testers before it even hits a repo, and an SD Card is always a safe bet for initial tests.
Thanks and I’ll keep you in the loop!
Once there are patches, @stephano can put them into a branch of reform-debian-packages and then the gitlab CI will give you a repository URL which you add into your apt sources.list and then you can just “sudo apt upgrade” to install the kernel from that custom repo with your patches.
Once you have a reform-debian-packages branch where CI ran successfully, you can trigger a reform-system-image pipeline run with the variable “reform-debian-packages-branch” set to your custom feature branch name and then the system image builder script will give you system images with that customly patched kernel.
When you do your own reform-system-image pipeline runs, maybe consider setting the “sysimages” variable to “reform-system-any” or otherwise every pipeline run will consume 35 GB of disk space.
1 Like
awesome, and I assume when changes are merged/upstreamed I sudo apt upgrade again then remove the special branch from apt sources.list or similar to get back to a “normal” configuration?
Kernel versions in the MNT Debian repository are constructed by adding the +reform suffix to the Debian kernel version and after that, adding the date of the top git commit in the format +%Y%m%dT%H%M%SZ. This means, that when you switch back from the gitlab CI repository to https://mntre.com/reform-debian-repo then you will automatically apt upgrade back to whatever is in the MNT repo once a commit lands which is later than on the custom branch you installed from before.
1 Like
Quick update on the display issue.
I had seen this bug report, but my panel’s issue seemed different. A complete failure of the display, not 1/2 a display.
@minute’s comment here peaked my interest. I thought I had tried this by hacking the firmware’s call to “turn_som_power_on” to call the reset even on warm boot. Since that didn’t work I assumed it wasn’t the issue. But looking into the call stack, that function isn’t invoked on warm boot.
I hadn’t thought about wiring the reset into the bootloader. After some research into why a reset was needed on the Huai Zhi (V2) panel, I decided to try it in barebox and the rk3588s. I happen to be hacking around in barebox anyway, enabling the rk3588s. I’ve been able to get the firmware and barebox chatting over SPI and the reset now runs on every boot, warm or cold.
So far, the results are positive. The display seems to be working without any issue, and without any patches to the driver. That part is a bit confusing, but it’s not bad 
. I’ll update u-boot so that the same reset can be asserted on warm/cold boot for the A311D and i.MX SoCs.
To be clear, this doesn’t mean we shouldn’t still go the 2 driver route. This bootloader update simply ensures that when we split up the Linux driver, the Huai Zhi panel functions correctly.
2 Likes