Quick tip for anyone else interested in running wireguard with this image: the default wireguard package has dependencies that will end up installing the default raspberry pi kernel, which I suspect will just not boot on a devterm or uconsole, and you’ll have to reflash your SD card.
Instead, install using
sudo apt install --no-install-recommends wireguard-tools
That should only install the wg utiity.
Did you have any luck resolving the slowness issue?
I went back to the stock OS, which fixed it. Didn’t spend a lot of time on it though.
I tried to use ibus for chinese input, but seems that it only works on terminal. I don’t know if anyone has successfully added chinese input to it.
But other than that, it is really nice
ok l am new to the alternate OS scene. Love my UConsole. I watched a YouTube video talking about the image here and just tried to load it and it’s been 45 minutes and nothing but a black screen. All i did was write the image. what did my newbie self-do wrong. I have searched all over to make sure i could find an answer before asking LOL
I assume it was working before. So how did you flash the image? What program?
When you wrote the image did you apply any custom settings using the flashing software like in RPI imager?
I Flashed it as is with usb imager you suggested. This is after I used etcher and rasberry pi imager. I know I’m doing something wrong
Oh and yes it works with stock.
Are you decompressing the image? what OS are you running to do this on?
I would redownload the image in case it got corrupted and flash with usbimager without decompressing the image.
I ran it uncompressed on windows 11. I have ran with USBimager. I have tried several ways. then I saw your post to someone to use usbimager and do not decompress. It still did not boot I am running the compute module 4 with 4g module as well. sorry for the inconvenience I bought mine and got it in 2023. Really want to try your image
Have you tried with a different sd card?
Finally got around to installing this on my Devterm, and the install and experience is well done. Thanks, Rex!
I noticed an issue and I have a question though…
Mouse input and display in VNC
The VNC server can be turned on as usual via Raspberry Pi Config, and it connects (in my case with RealVNC Viewer on Windows), but the mouse input axes are mixed up:
client down == server left
client up == server right
client right == server down
client left == server up
The display is 1280x480 (wide and short), as expected.
When using the device directly, with the trackball, the axes are mapped correctly, with left being left, and so on. (I haven’t noticed the problems some people have reported with mine not being responsive, so I’m guessing that is a ball cleaning issue?)
After a little digging, it turns out this is a known issue with Wayfire, and the solution is to install Labwc, as described here:
https://forums.raspberrypi.com/viewtopic.php?p=2224483&sid=dc90792bc296efc3058d7ba179c44f73#p2224483
sudo apt install labwc
sudo raspi-config
Then in raspi-config, go to Advanced Coniguration, select Wayland, and change it to Labwc.
This fixes the mouse input, but then the display is rotated to be 480x1280) only remotely via VNC), like this:
Any idea how to get this working properly? On the actual hardware the display is fine, and the built in trackball and external mice work fine. It’s only a remote VNC connection (and possibly other remote connections that use the display?) that has this issue.
Fan control
I noticed the fan control was turned off in raspi-config. I turned it on, but was unsure if the default GPIO pin there (14) was correct. Would this setting and the associated temperature trigger be used to control the fan? Or is that handled separately? I know back in the early days we had to use the python script to control this, but I vaguely remember it working in raspi-config when the GPIO pin was set correctly. I’m just not sure what the value should be. Thanks!
Again, both of these questions are related to Devterm. Not sure if they apply to the uConsole. I’ll be building mine soon though, so can check on that later. 
With VNC I’m not sure. Probably some quirk with the rotated panel.
The fan control is still handled by a python script and ramps up at 65°c, I’m not around my computer right now but I think it’s located in /usr/local/bin
Haven’t solved the display/control rotation thing yet, but I did discover something. The same behavior happens with the default Wayfire window manager if I go to Preferences->Screen Configuration and inside the Screen Layout Editor I change the screen orientation from “Right” to “Normal”.
Before doing this, the VNC mouse input is rotated as described before, though the display orientation is correct. But after doing this, the input rotation is fixed and the screen is rotated vertically like using the Labwc window manager. So I don’t think the window manager matters at all here – the only thing that changed was the screen orientation setting. Seems like VNC maps input to the screen based on the actual orientation the screen is expected to be used at, rather than the rotated way we use it on the DevTerm.
xrandr throws errors when trying to use “right” or “left” for the rotation parameter, whether size is specified or not. Using sudo didn’t matter, as it’s not a permissions thing.
cpi@clockworkpi:~ $ xrandr --output XWAYLAND0 --size 1280x480 --rotation right
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 139 (RANDR)
Minor opcode of failed request: 7 (RRSetScreenSize)
Serial number of failed request: 22
Current serial number in output stream: 23
I’m not sure if this is just a quirky VNC thing or if something is a bit weird with how the display is being handled.
Sorry to go on about VNC, but I generally use the Devterm remotely, and only sometimes use the keyboard and display on the device. (Kind of a waste, I guess!) SSH is the main way I access it, and that’s fine since the display isn’t an issue there. If I find anything else out I’ll share here.
Yep, you were right, the fan script is here:
/usr/local/bin/temp_fan_daemon.py
Seems like pin 17 is used, so I wonder if the script could be removed entirely and that pin referenced in raspi-config instead? If that worked (along with the temperature setting there) it would be cleaner to use the built in stuff than to rely on the script, or at least easier to find and one less question for other tinkerers.
def init_fan_gpio():
os.popen(“pinctrl set 17 op”)def fan_on():
init_fan_gpio()
os.popen(“pinctrl set 17 dh”)def fan_off():
init_fan_gpio()
os.popen(“pinctrl set 17 dl”)
It would be cleaner but that’s something every DevTerm person would have to setup on a new image themselves. It’s better to have a script that I can build into the image then tell people to remember to set your fan up. Kind of like how everything for both the DevTerm and uConsole is included in the image. It would be cleaner to have to separate kernels and images but its not worth it.
I was thinking is there anyway on the client side to change the resolution to 480x1280? See if that rotates client view.
I’m not convinced the built in rasp-config fan control works for Devterm anyway. I stopped the service that was running the script. And I set the gpio to 17. Found and ran something called cpuburn that got the temperature up, cat’ed the status of the temperature device and showed it increasing beyond the limit I set, and the fan device switch and was showing as on (1), But I didn’t hear the fan spinning. Guess I should do a similar test with the script running – maybe my fan is broken or disconnected, but I know it used to work in the past. I haven’t used it much in the past year or so though.
On the plus side, this OS image seems to run cooler than I remember the stock CM4 image running at. With 100% CPU usage it wasn’t getting hot nearly as fast. (And I remember the A06 ran very hot, no matter what I did with the fan or the gearshifting util – the fan was definitely working then!)
EDIT:
The fan does turn on/off properly using the script. So I’m not sure what was going on with the built-in stuff. So I’ll stick with what works.
I don’t see anything, though it could just be this client. There are plenty of options for scaling and fullscreen (and encryption and compression, etc.), but nothing to set a specific resolution from the client. I wonder if that’s a wayland thing? I’m pretty sure I remember being able to do that from the client side before when using X11.
I had the DevTerm and an A04 and that thing ran hot too.
