Pocket screen off after idle and can't get on again?

rpm · April 1, 2026, 4:22am

If I get interrupted and go do something else around the house (in gnome sometimes locked with mnt+l) I am finding that more often than not the pocket screen turns off and I can’t get it on again without a forced restart. Has happened on both 6.18 and tonight now 6.19

Reviewing the logs everything seems normal, but the following:

Mar 31 23:50:26 mntbear kernel: ------------[ cut here ]------------
Mar 31 23:50:26 mntbear kernel: WARNING: drivers/gpio/gpiolib.c:3903 at gpiod_set_value+0x4c/0x80, CPU#3: KMS thread/2746
Mar 31 23:50:26 mntbear kernel: Modules linked in: sd_mod scsi_mod scsi_common aes_ce_ccm realtek rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device dwmac_meson8b stmmac_platform evdev joydev stmmac pcs_xpcs mdio_mux_meson_g12a mdio_mux algif_hash algif_skcipher af_alg cdc_acm bnep rtw88_8822cs rtw88_8822c rtw88_sdio rtw88_core qrtr sunrpc mac80211 hci_uart btqca btrtl btintel btbcm bluetooth ecdh_generic cfg80211 pwrseq_core rfkill snd_soc_tlv320aic31xx libarc4 reform2_lpc(OE) meson_saradc meson_rng snd_soc_meson_axg_tdmin industrialio snd_soc_meson_g12a_tohdmitx snd_soc_meson_axg_sound_card snd_soc_meson_axg_tdmout snd_soc_meson_axg_frddr snd_soc_meson_card_utils snd_soc_meson_axg_tdm_interface leds_gpio snd_soc_meson_axg_tdm_formatter dm_mod binfmt_misc i2c_dev nvme_fabrics efi_pstore configfs nfnetlink autofs4 ext4 mbcache jbd2 crc32c_cryptoapi mali_dp cdns_mhdp_imx cdns_mhdp_drmcore snd_soc_meson_codec_glue mxsfb mux_mmio panel_edp imx_dcss ti_sn65dsi86 drm_dp_aux_bus nwl_dsi mux_core pwm_imx27 hid_generic usbhid hid
Mar 31 23:50:26 mntbear kernel:  onboard_usb_dev meson_gxl smsc crc16 xhci_plat_hcd xhci_hcd dwc2 dwc3 meson_vdec(C) snd_soc_meson_axg_toddr udc_core snd_soc_meson_axg_fifo videobuf2_dma_contig snd_soc_hdmi_codec snd_soc_core reset_meson_aux dw_hdmi_i2s_audio ulpi usbcore reset_gpio aes_ce_blk videobuf2_memops nvme meson_dw_mipi_dsi v4l2_mem2mem aes_ce_cipher snd_compress rtc_pcf8523 videobuf2_v4l2 ghash_ce snd_pcm_dmaengine gf128mul snd_pcm axg_audio nvme_core dw_mipi_dsi videodev nvme_keyring snd_timer videobuf2_common sclk_div nvme_auth meson_gxbb_wdt ao_cec_g12a snd hkdf soundcore reset_meson_audio_arb clk_phase rtc_meson_vrtc mc meson_dw_hdmi panfrost spi_gpio meson_drm drm_shmem_helper dwc3_meson_g12a phylink gpu_sched clk_pwm meson_canvas gpio_regulator usb_common nvmem_meson_efuse pwm_regulator spi_bitbang cpufreq_dt [last unloaded: pcs_xpcs]
Mar 31 23:50:26 mntbear kernel: CPU: 3 UID: 1000 PID: 2746 Comm: KMS thread Tainted: G        WC OE       6.19.10-mnt-reform-arm64 #1 PREEMPTLAZY  Debian 6.19.10-1+reform20260321T104947Z 
Mar 31 23:50:26 mntbear kernel: Tainted: [W]=WARN, [C]=CRAP, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Mar 31 23:50:26 mntbear kernel: Hardware name: MNT Pocket Reform with BPI-CM4 Module (DT)
Mar 31 23:50:26 mntbear kernel: pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
Mar 31 23:50:26 mntbear kernel: pc : gpiod_set_value+0x4c/0x80
Mar 31 23:50:26 mntbear kernel: lr : jdi_panel_prepare+0xbc/0x178
Mar 31 23:50:26 mntbear kernel: sp : ffff800088b53730
Mar 31 23:50:26 mntbear kernel: x29: ffff800088b53730 x28: 0000000000000028 x27: 0000000000000000
Mar 31 23:50:26 mntbear kernel: x26: 0000000000000001 x25: 0000aaab19cda290 x24: ffff00000343e000
Mar 31 23:50:26 mntbear kernel: x23: ffff0000166cd200 x22: ffff000002d34a80 x21: ffff800081b62600
Mar 31 23:50:26 mntbear kernel: x20: ffff00000343ec08 x19: ffff00000085a080 x18: 0000000000000003
Mar 31 23:50:26 mntbear kernel: x17: ffff0000e47099d0 x16: 0000000000000000 x15: ffff8000820844b8
Mar 31 23:50:26 mntbear kernel: x14: ffff800081f81480 x13: 00000000000000c0 x12: 0000083eacee685f
Mar 31 23:50:26 mntbear kernel: x11: 00000000000000c0 x10: 0000000000000c80 x9 : ffff800080d012ac
Mar 31 23:50:26 mntbear kernel: x8 : ffff00002d34e320 x7 : 0000000000000000 x6 : 0000000000000010
Mar 31 23:50:26 mntbear kernel: x5 : ffff8000627fc000 x4 : 0000000000800000 x3 : 0000000000000000
Mar 31 23:50:26 mntbear kernel: x2 : ffff0000009cfae0 x1 : 0000000000000001 x0 : 0000000000000001
Mar 31 23:50:26 mntbear kernel: Call trace:
Mar 31 23:50:26 mntbear kernel:  gpiod_set_value+0x4c/0x80 (P)
Mar 31 23:50:26 mntbear kernel:  jdi_panel_prepare+0xbc/0x178
Mar 31 23:50:26 mntbear kernel:  drm_panel_prepare+0x48/0x100
Mar 31 23:50:26 mntbear kernel:  panel_bridge_atomic_pre_enable+0x5c/0x80
Mar 31 23:50:26 mntbear kernel:  drm_atomic_bridge_call_pre_enable+0x2c/0x60
Mar 31 23:50:26 mntbear kernel:  drm_atomic_bridge_chain_pre_enable+0xe8/0x148
Mar 31 23:50:26 mntbear kernel:  drm_atomic_helper_commit_encoder_bridge_pre_enable+0xc8/0x118
Mar 31 23:50:26 mntbear kernel:  drm_atomic_helper_commit_tail_rpm+0x7c/0xe8
Mar 31 23:50:26 mntbear kernel:  commit_tail+0xc0/0x200
Mar 31 23:50:26 mntbear kernel:  drm_atomic_helper_commit+0x180/0x1b0
Mar 31 23:50:26 mntbear kernel:  drm_atomic_commit+0x94/0xe0
Mar 31 23:50:26 mntbear kernel:  drm_mode_atomic_ioctl+0xb1c/0xe40
Mar 31 23:50:26 mntbear kernel:  drm_ioctl_kernel+0xc8/0x138
Mar 31 23:50:26 mntbear kernel:  drm_ioctl+0x260/0x580
Mar 31 23:50:26 mntbear kernel:  __arm64_sys_ioctl+0xac/0x108
Mar 31 23:50:26 mntbear kernel:  invoke_syscall.constprop.0+0x64/0xe8
Mar 31 23:50:26 mntbear kernel:  el0_svc_common.constprop.0+0x40/0xe8
Mar 31 23:50:26 mntbear kernel:  do_el0_svc+0x24/0x38
Mar 31 23:50:26 mntbear kernel:  el0_svc+0x3c/0x198
Mar 31 23:50:26 mntbear kernel:  el0t_64_sync_handler+0xa0/0xe8
Mar 31 23:50:26 mntbear kernel:  el0t_64_sync+0x198/0x1a0
Mar 31 23:50:26 mntbear kernel: ---[ end trace 0000000000000000 ]---
Mar 31 23:50:26 mntbear kernel: panel-mnt-pocket-reform ffd07000.dsi.0: [display] init in prepare...
Mar 31 23:50:26 mntbear kernel: rtw88_8822cs mmc2:0001:1: failed to send h2c command
Mar 31 23:50:26 mntbear kernel: panel-mnt-pocket-reform ffd07000.dsi.0: [display v2] sent tables OK
Mar 31 23:50:26 mntbear kernel: panel-mnt-pocket-reform ffd07000.dsi.0: [display v2] OK

Thanks for any suggestions!

stephano · April 1, 2026, 4:54am

I’ve been looking into a similar issue, though it only happens to me on warm reboots.

github.com/cetola/mnt-build

Intermittent Blank Screen on A311D

opened 04:59PM - 15 Mar 26 UTC

cetola

## Summary Booting the A311D SoM on the MNT Pocket Reform sometimes results in …a blank display after boot. The system itself is still functional in many of these cases: - SSH access works - the system appears fully booted - the display simply never becomes active Once the system reaches this blank-screen state, rebooting via SSH does not fix the issue. The screen usually recovers only after power cycling the system controller, either by: - using the keyboard controller power cycle, or - using the standby switch to cut power to the system controller. This suggests the issue may involve state or timing between the system controller firmware and the panel driver. ## Environments Observed The issue occurs on both: - the stock Debian system image - Arch Linux using mnt-build ## Debug Patch As of this commit: https://github.com/cetola/mnt-build/commit/4eee60a33efa4955c3bbb59287ea43f1056c5c24 I added a small patch to the panel driver to include additional debug output. The patch: - adds debug logging to the panel init path - replaces `gpiod_set_value()` with `gpiod_set_value_cansleep()` - adds a small delay (`msleep(120)`) inside `pocket_display_v2_init()` The patch does not fix the issue — it is purely for debugging. ## Observed Behavior Comparing Debian dmesg logs between a working boot and a blank screen boot, the panel driver logs appear almost identical, with the primary difference being timing offsets. The driver sequence itself is the same: ``` prepare fbcon takeover unprepare prepare again ``` However, the timing between events diverges between the good and bad boot. ## Timing Comparison A simple alignment of the two logs shows the following offsets. ### Initial Panel Bring-Up | Event | Working Boot | Blank Boot | Delta | |------|------|------|------| | first `prepare` | 5.451s | 5.703s | +252 ms | | `[display] init in prepare` | 5.452s | 5.703s | +251 ms | | `"not sending tables this time"` | 5.502s | 5.750s | +248 ms | | `[display v2] OK` | 5.607s | 5.850s | +243 ms | | fbcon takeover | 5.648s | 5.893s | +245 ms | | `fb0` registration | 5.810s | 6.024s | +214 ms | ### Second Prepare Cycle (Hotplug Path) | Event | Working Boot | Blank Boot | Delta | |------|------|------|------| | `unprepare` phase | 6.403s | 6.527s | +124 ms | | second `prepare` | 6.814s | 7.258s | +444 ms | | `[display] init in prepare` | 7.135s | 7.616s | +481 ms | | `"sent tables OK"` | 7.277s | 7.754s | +477 ms | | final `[display v2] OK` | 7.382s | 7.857s | +476 ms | ## Interpretation Observations from the logs: - The event order is identical between working and blank boots. - The timing difference is larger than simple jitter. - The difference grows during boot, from ~250 ms initially to ~480 ms later. This suggests the two boots are not simply shifted copies of one another, and that probe ordering / workqueue scheduling / DRM hotplug timing may diverge during boot. The offsets are large enough that panel initialization race conditions are plausible. ## GPIO Warning Removed by Debug Patch The debug patch also removes this warning from dmesg: ``` WARNING: CPU: 2 PID: 217 at drivers/gpio/gpiolib.c:3880 gpiod_set_value+0x4c/0x80 ``` Backtrace: ``` pc : gpiod_set_value+0x4c/0x80 lr : jdi_panel_prepare+0xbc/0x178 ``` This appears to occur because the driver was using: ``` gpiod_set_value() ``` on a GPIO that may sleep. Replacing it with: ``` gpiod_set_value_cansleep() ``` removes the warning. This change is not believed to fix the display issue; it simply removes the GPIO API misuse warning. ## Attached Logs Working boot: ``` deb-dmesg-screen-working-v1.txt ``` Blank screen boot: ``` deb-dmesg-screen-blank-v1.txt ``` ## Hypothesis My current guess is that this is a timing/state issue between: - the system controller firmware - the panel driver - the DRM hotplug / prepare lifecycle Since the screen often recovers only after cutting power to the system controller, it seems possible that some panel state persists across reboots. ## Additional Debugging Next steps: - test additional delays in the panel driver - instrument DSI transactions - capture UART boot logs [deb-dmesg-screen-blank-v1.txt](https://github.com/user-attachments/files/26005995/deb-dmesg-screen-blank-v1.txt) [deb-dmesg-screen-working-v1.txt](https://github.com/user-attachments/files/26005996/deb-dmesg-screen-working-v1.txt)

I was able to make that warning go away by replacing gpiod_set_value() with gpiod_set_value_cansleep() in the panel driver. See the GPIO Warning Removed by Debug Patch section of that issue. The warning seems to have no effect on the panel behavior.

rpm · April 5, 2026, 11:40pm

Wow looks like you have investigated this a lot. Sad that it wasn’t something easy! I wish I knew more about that level with the hardware, but sadly doesn’t line up with my career much so hard to justify!

I have the RK3588 on order so maybe it will go away when I switch to that, but also thinking of cancelling because not loving the idea of running a Chinese chip… I’ll try to keep up with your link in case anything changes.

DrGenetik · April 7, 2026, 1:03am

Turning off the screen or disabling the display is really iffy on the Pocket. Even when it works, it often comes up flickering. I had to configure my idle service and the thing that handles the external displays so, instead of doing the equivalent of turning the display off, it just set the brightness to 0 and then, when I disconnect the external display or move the mouse, type a key, it restores the brightness. It’s my understanding this is being actively worked on and is a driver issue.