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.
3 Likes
hey i just was testing arch again, and was thinking about maybe trying to compile a kernel custom on arch then copying to SSD to install since arch didn’t have the screen lockup, meaning i could let it run and walk away without concern of not being able to get back access.
the issue is, i just left it for a while, and the same issue struck again, even on your arch image.
i replied to this message since before, when i tested arch, and thought the screen issue was fixed, i hadn’t done the lpc module. could that have anything to do with the issue? since that’s the only thing i did differently this time.
i’ll leave it overnight for a couple nights without running the lpc module reboot thing, and then again without and see if it crashes only with the lpc module
Thanks for the update!
It’s possible that reform2_lpc is complicating things and could cause the issue you saw. As far as I can tell (on Arch + the A311D), if you did not reload the reform2_lpc module, then it did not load correctly. If that’s the case, then as we say in the biz, “all bets are off”. (i.e. the system might do lots of crazy things and we don’t know why)
I’ve been running the rk3855s from Radxa for the past 2 weeks. This includes my updates to barebox, and a firmware fix. Together, they fix the issue in bug #51, and without any patches to the kernel, the screen issues I was seeing are gone. I think this will be the main fix, and separating out the drivers will just be “good engineering practice”, not really required.
So the work I did in barebox needs to be ported to u-boot for all the other SoMs (A311D included). I don’t think this will be a huge lift (he says).
The sysctl link is bit-banged GPIO rather than a hardware SPI driver. U-boot needs four defconfig symbols enabled (SPI, DM_SPI, SOFT_SPI, CMD_SPI), a spi-gpio node added to the board DTS with the right A311D pin numbers plus a spi0 alias, and then one can drive the reform2_lpc exchange from a preboot script as two sspi calls separated by sleep 0.05. The only real gotcha is a bug in v2024.04’s soft_spi.c that silently disables the read path, which we can sidestep by using the legacy gpio-miso property naming or cherry-picking the upstream one-liner.
So that’s where I’ve left things in my notes. Next up is to implement that. I also have an upstream MR to the firmware:
Once that goes live and I create and upstream a MR for u-boot, you should be able to boot the V2 panel without any issues.
what i’m saying is that reloading it is what seems to have caused the crash. leaving it just, however it ended up running seems to have no issue. i tested it last night and left it on without rebooting the lpc, and it’s still working this morning. i’ll leave it another night and see if it’s still working, and if so i’ll try rebooting the lpc. maybe this was a fluke but i don’t know. i’ll keep testing.
really glad to hear it, soon as you have a beta/alpha/something ready to test, lemme know as i am more than happy to do so
absolutely awesome, if you want me to help with a test version before you make the MR, i can, long as whatever potential bricking will be recoverable (since i know messing with u-boot might cause it to be soft-bricked)
Oh, okay, sorry for the misunderstanding. Yes, this isn’t surprising. The reform2_lpc module is acting on panel V2 (brightness control) which it assumes was brought up correctly. The panel was not brought up correctly. I have seen the screen fail to come back a few times after idle (swayidle) but I can fix that with the keyboard (OLED) command for “On”. If you’re seeing it go blank and nothing can bring it back I’ll make a note of that. Will be good to watch that reform2_lpc once the u-boot and firmware fixes are in.
Absolutely, will let you know. Thank you for the offer.
The updates addressing these issues is out now: https://community.mnt.re/t/important-note-about-the-new-mnt-pocket-reform-kernel-and-firmware-updates-20260808-updated
I have to say that on RK3588 with Display V2 I still get the half screen+stripes now from time to time, even with the hard reset integrated, and I believe this is a timing/delay issue that needs to be tweaked in the driver. But the good news is that it can recover now from this issue when doing another display disable/enable cycle, and I changed the panel-mnt-pocket-reform driver to now be loaded as a module again and made sure it doesn’t crash when reloading the module. This means one can now iterate much faster on this problem, by changing code, rebuilding and reloading the module in a live kernel over SSH. I first wanted to get the huge release out before spending more time on tweaking this issue, and that’s done now, so the tweaking of these things can start in the coming week.
BTW during testing I found that sway can only bring a “dpms off” display back when you do a sequence like this:
swaymsg output DSI-1 dpms on
swaymsg output DSI-1 enable
swaymsg output DSI-1 mode 1200x1920 # only this triggers the real code in the kernel to turn the panel on
In Gnome, this problem doesn’t seem to exist.
glad to see things moving, i’m currently running Trixie so reform-tools hasn’t been backported yet but when it is i’ll report back and be able to test fixes