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
I’ve been looking into a similar issue, though it only happens to me on warm reboots.
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.
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.
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.
I’m curious if you’ve tried using the keyboard menu to select “power on” to resolve the blank screen after idle. IIRC from the firmware that may toggle the enable line on the panel and possibly fix a “bad state” the panel got itself into.
#!/usr/bin/env bash
# Issue dpms command on external hdmi monitor.
# Adjust brightness on internal monitor
case "${1}" in
"suspend")
# External monitor
swaymsg "output HDMI-A-1 dpms off"
# Internal monitor
brightnessctl -s # Store current brightness
brightnessctl s 0 # Set brightness to zero
;;
"resume")
# External monitor
swaymsg "output HDMI-A-1 dpms on"
# Internal monitor
brightnessctl -r # Restore previously stored brightness
;;
esac
Note that instead of asking swayidle to run an external script, it could probably be done with a single line with all commands embedded on the swayidle invocation, but I find this easier to understand and manipulate.
I am using Debian Trixie too, and even this method has served me very well, I just tested issuing dpms on/off to the internal panel and within the few tries I did it seems to work correctly. I am sorry to say I can’t remember at which point I had to use this trick and don’t know at which point I could use dpms again.
this is the first thing i tried, since it seems like the logical solution but the panel was still stuck
i use Gnome on my Pocket Reform, so i don’t think this is really an option? as is it seems like a driver issue, so the root cause (the driver) really should get fixed, but thank you for including your workaround
been leaving my pocket off lately (since the screen crash kept making it effectively unusable) and found there was a mesa update waiting for me. after installing and rebooting i found that this same error was perpetually sent in dmesg every time the screen is off
which seems to be near identical but this time it appears to be coming back on after, and not being fatal. maybe it’s fixed? not sure. anyone else test this more?
edit: it still crashed, just took longer this time. weirdly enough it only crashed after I started waydroid.
looks near identical to me and no gamma timeouts, so probably not that after all.
if anyone at MNT or in the community can come up with a fix that’d be great since i frankly have no idea what i’m looking at here, and the above mentioned issues with the driver that stephano brought up have stagnated.
Sorry I haven’t been able to look into this any further. My hope was with Stephano or my RK board coming since it looks like that has more community interest. Neither of which has come true so I am just never locking the screen or doing a reboot… once boot text start coming up I always feel better. I just wonder what happened because when I first switched the board I don’t remember this happening before kernel 6.18 when a few things got more complicated.
no apology needed, it’s just really frustrating that things stagnated since I can’t get the rk3588 yet, and also since I feel like all the boards should be functional at a base level and not have issues like this that make them unusable for some. /neu
if you get time to look into this I am more than happy to mess around with mine and instigate the issue to get more logs and data /pos
reason I haven’t done anything is because I just haven’t done much coding things before (just bash and a hint of python) and haven’t touched something as low level as firmware/drivers so I have no clue what i’m doing, hence the “dmesg logs into the void” as seen above lol /lh
Hi @Nebula-System I’m afraid I am unable to give any professional input on this topic but as a data point, if you have the time, can you confirm that the issue does not happen if you use sway with a swayidle as it was posted by @amospalla or more trivially:
exec swayidle -w timeout 300 'brightnessctl set 0%' resume 'brightnessctl set 100%'
Could you also remind me whether you use Debian unstable from MNT or whether you use Debian stable from reform.debian.net?
testing this now, i’ll report back in a bit with fresh dmesg and instigate it a bit (log out, in, lock, repeat a bunch of times)
i use the stable one, since it’s required for Waydroid and since i’m eventually moving my phone functions to my Pocket Reform i need Waydroid. which is another reason this issue is so frustrating for me, i need it to be reliable and can’t simply roll back the kernel update due to dirty frag (difficulty aside)
that said, i don’t see how the stable vs unstable would make a difference? the drivers are backported and it’s a driver issue as i understand it. unless the drivers that are backported aren’t the most up to date? i am also curious, why does MNT use unstable anyway? it it just ease of rapid development? and will stable become the default in a later release, for example forky?
Most of the time swayidle seems to set brightness to 0% successfully. Sometimes I see:
Jun 23 23:23:52 mntbear /usr/libexec/gdm-wayland-session[17106]: Updated device 'mnt_pocket_reform_backlight':
Jun 23 23:23:52 mntbear /usr/libexec/gdm-wayland-session[17106]: Device 'mnt_pocket_reform_backlight' of class 'backlight':
Jun 23 23:23:52 mntbear /usr/libexec/gdm-wayland-session[17106]: Current brightness: 0 (0%)
Jun 23 23:23:52 mntbear /usr/libexec/gdm-wayland-session[17106]: Max brightness: 100
but the screen is still on normally.
My details:
I: `uname -a` output: Linux mntbear 7.0.10-mnt-reform-arm64 #1 SMP PREEMPT Debian 7.0.10-1+reform20260602T222813Z (2026-06-0 aarch64 GNU/Linux
I: Version of linux-image-mnt-reform-arm64: 7.0.10-1+reform20260602T222813Z
I: Version of reform-tools: 1.87-1+reform20260529T225830Z+1
I: Version of system image: System Image v5: 2025-12-21
I: Version of system controller firmware: 20251118
I: Version of keyboard firmware: 20251118
I: Version of LPC firmware: PREF1SYS R1 20251118
nothing good in dmesg or journalctl when it doesn’t blank.
so it seems we may have isolated the issue to something with the gnome lock screen. gonna set idle timeout to 3 seconds and have a mini rave and see if i can get the issue to happen now, if not then it’s definitely gnome
edit: ok after letting it set to 0 brightness and back on over 50 times and resulting in nothing in dmesg i think it’s 100% something to do with gnome’s handling of setting screens to off when locking. maybe on the Pocket include in the reform-check or something an edit to the relevant config in gnome if it detects gnome is installed? that’ll be once we figure out what the exact mishandling thing is and if the way gnome handles it can be changed or if it’s even gnome’s fault and it’s not a driver issue as initially suspected
i’m gonna do some poking around in gnome on my end, let me know if there’s anything anyone needs (other than using sway ideally, i seriously dislike it lol)
