Hello! I received my MNT Pocket Reform last week and I like the device quite a bit. I’m able to suspend the device (apparently) with systemctl suspend but I haven’t been able to wake it (using the wake menu item on the system controller). Is this the current status of suspend/wake on Pocket Reform?
I was able to get kernel logs from the suspend process over serial, and I could share them here if it’s helpful, but I didn’t see anything unusual, and I don’t see anything at all from the kernel when I select the “wake” item on the system controller. I also looked into reform-standby but it’s not clear to me if that’s relevant for the pocket reform at all. I have some experience with Linux kernel development, how would people recommend investigating?
Hi, suspend/wake used to work a few months before shipping, but I need to figure out what to patch in the kernel to make it work again, or we have to wait for kernel 6.10 which finally upstreams the HDMI support. In the past it was some null pointer bug handling a HDMI related power domain that made it crash on wake. I’m currently in a perfect storm of ongoing Pocket shipments, handling support requests for Pocket, preparing the Next laptop and handling production of backlogged Reform shipments. That’s why it will take a bit of time until I can look into this again.
Addendum: I just re-read that you have experience with Linux kernel development. So if you want to take a look, you could either build a monolithic kernel 6.9 with our patches and .dts/.dtb (from reform-debian-packages/linux) or build the debian kernel package (@josch can probably give pointers on how to do that). If I were to investigate this, I would build a monolithic kernel and make an extlinux.conf or custom uboot.scr that loads it without initrd, and work via UART console. Then, I would add printks into pretty much all interesting functions in linux/drivers/pmdomain/imx/imx8mp-blk-ctrl.c at master · torvalds/linux · GitHub and see where it hangs or has weird pointers.
Yes. I think building a monolithic kernel is the way to go for building something quickly and then iterating on that with small changes without having to wait several hours for everything to build again from scratch. Without an initrd, you can boot into the system with init=/bin/bash. Once you have found the culprit, it makes sense to run the Debian linux kernel packaging machinery to verify that the fix you found for the monolithic kernel also works for the Debian kernel.
I’m guessing we also need to configure some steps or triggers to respond to closing the lid (is that possible), or add suspend to the reform-tray tool or something?
If there’s not already a sensor for detecting lid close (I assume there’s not) I’m hoping it should be possible to daisy-chain a couple of accelerometers from the i2c qwic connector, one in the lid and one in the keyboard and trigger based on the orientation being the same in software.
Happy to see this thread and see it’s known. I decided to test bringing my Pocket on the go yesterday, packed it up, had lunch, pulled out a very toasty rectangle. I’m okay with manually running suspend / wake, though it might be even nicer if in future revisions there’s a sensor for lid close. In the meanwhile, just knowing is good.
I did run suspend manually a few minutes ago and it looked like it suspended! It just didn’t wake up yet.
I’m currently in a perfect storm of ongoing Pocket shipments, handling support requests for Pocket, preparing the Next laptop and handling production of backlogged Reform shipments. That’s why it will take a bit of time until I can look into this again.
From my perspective y’all are doing a stellar job, and I definitely appreciate the amount of responsiveness I’ve gotten. You’re doing great! Make sure to reward yourself with peppermint tea or the like often.
So I got rudimentary lid closed detection working using one accelerometer (ideally we’re gonna need one in the bottom half too but that’s gonna require jumping through some hoops which I haven’t done yet).
Here’s a video of it working, I need to increase the sensor reading frequency so it’s a bit more snappy!
Your work has got me encouraged to try something similar with ICM20948 which I had at hand. I do not know how long it would take, but so far I have physically fixed the sensor inside my top case.
Grim, so you have the accelerometer trigger a sleep state, which I assume is using the shunting service that just tried to freeze the system and shut stuff off. Is that right? I’m curious how you are preventing picking the device up with the lid off from accidentally triggering a wake event?
