I’d be curious to know how you fixed the screen rotation issue. If there are other things you configured that would be interesting to see too (if you don’t mind sharing parts of your config file or pointers.) I’ve never used Sway before, and from what I’ve see it looks interesting. But I also haven’t found any good overviews or tutorials yet (most everyone just points to the man pages, which I guess I should read!)
I did manage to rotate my screen properly after login, using the sway wiki as a guide and changing the config file to include output DSI-1 transform 90. Thing is, that only affects rotation after logging in, so the login screen is still rotated.
I’ve noticed a few other lower priority things that don’t work, like being able to use the FN and <> keys to change brightness, and the FN and volume key to change volume. There’s probably a way to set that up in a configuration file or utility somewhere, but I have no idea what I’m doing right now, so I’ll have to do a lot of stumbling around and research to find out.
Also, the battery indicator seems to be wonky. It’s showing I’m charging when I’m unplugged. And default sizes of some windows/panels have too short a height and show an error instead of displaying (like when clicking on the processor icon). I realize it’s still a work in progress and I’m not complaining – mostly just somewhat confused and interested in figuring out how to use Sway. Definitely seems fast and stable right now on DevTerm for the little bit of checking it out I’ve done. It also seems quite appropriate to run on the DevTerm, with it’s minimalistic text/icon presentation combined with speed.
that output DSI-1 transform command is exactly how i did it, and yeah it doesnt work on the login screen either. FN volume and brightness just comes down to setting the bindings in sway config
Did you ever track this down? I’ve been doing things with the printer and leaving it plugged in. I actually cut some little paper squares to drop in on top of the speakers (blocking the signal contacts) to disable them until I can get the noise killed
btw I’m running the stock OS, getting the same issue and looking to switch for unrelated reasons
Nice work! I just installed the latest test release and it seems to work smooth. However I think the screen blank issue is still there. In the xfce at least after some time the screen seems to blank and after pressing a key or moving the pointer only the backlight will turn on.
Also I found a couple of other issues (maybe not related to the Manjaro port) that I want to mention.
sometimes when switching the DevTerm on/off there is a loud “plock” coming out of the speaker. When I was running just from USB power this “plock” sometimes even switched off the device immediately.
When the device is powered off forcefully by pressing the power button until it goes off, the next time I switch it on it is not coming up. I need to switch it off again and power on again. However, I can prevent that situation when I remove the batteries after switching it off. When I plug them back again the device will come up normally.
Suspend to RAM is still not working.
When powering down the batteries still drain. You can see that when switching it off with full batteries in the evening and powering up in the morning.
I want to help if possible but last time I build the kernel with the manjaro arm tools it took more than 12hours on my laptop. I could push it down to 4 by reducing the kernel config but still this is too much. This is probably due to the qemu emulation for each build step and the weak hardware that I own.
Is there a way to cross compile the kernel for manjaro?
Maybe even somebody tried to compile it on the device itself and replace the kernel and device tree and can share the steps how to do that?
sometimes when switching the DevTerm on/off there is a loud “plock” coming out of the speaker
yeah, right now the ALSA UCM daemon is responsible for turning on/off the speaker amplifier, but on a forceful shutdown it doesn’t seem to have a chance to do that. I don’t know the audio subsystem super well, but there must be a solution to this, since I don’t think it happens with the Armbian builds using the earlier es8323 driver. I’ll have to step through that code again or look more at the datasheet.
When the device is powered off forcefully by pressing the power button until it goes off, the next time I switch it on it is not coming up. I need to switch it off again and power on again. However, I can prevent that situation when I remove the batteries after switching it off. When I plug them back again the device will come up normally.
I’ve seen this happen a few times, mostly before the Rockchip MIPI-DSI suspend/restore fix was added, but most of the time it comes back up for me still if I power back on. I suspect this might be related to (4). There’s definitely something that doesn’t get turned off all the way with the forceful power-off.
Is there a way to cross compile the kernel for manjaro?
There is! I avoid building test kernels using manjaro-arm-tools for the same reason. Instead, I create a makepkg-aarch64.conf file (based on Nadia Holmquist’s work on bringing up the Pinebook Pro) that sets CARCH, CHOST, CROSS_COMPILE, etc. to point at the relevant aarch64 tools (pacman -S aarch64-linux-gnu-gcc aarch64-linux-gnu-binutils to install the AArch64 cross-compilation toolchain) and then pointing makepkg at that config and building like you would any other PKGBUILD.
The only caveat, is I’ve needed to update the references to strip in the PKGBUILD to use the AArch64 strip from the cross-compiler binutils, which I do by replacing strip with $CHOST-strip in the PKGBUILD
(I’m in the process of moving, and the machine I’ve been using for DevTerm development isn’t set back up yet, otherwise I’d share more in the way of code to do it.)
Not sure if the RPM of 3000 is correct for the assembled fan but I think it should not matter for the topic. Also the “hot” temperature I just took 65 degrees. Maybe it is even better to lower that. But as far as I understand the above should do the trick and enable the fan if required.
I see that we also have access to the core module schematics. Maybe I will find some time and check all the regulators and such. A first wild guess is that rk808 pmu is maybe not controlled correctly but this is only a gut feeling.
Hah, great minds think alike! The gpio-fan stuff was the last thing I was playing around with, but had not found the right temp and hysteresis value for it to be smooth. It definitely works though!
Yes this can become tricky. Actually what is also missing are the operating points for the frequency scaling by the kernel. Usually they are put in the devicetree as well otherwise frequency and voltage scaling might not work. At the moment I am not sure how it works on that platform but the python tools provided by the clockwork team indicate that is something they wanted to control from the userspace and just have the fan running for 30s when 70deg is reached.
We could potentially try to add the operating points as well by checking the python tool assuming the passive cooling capabilities for the cpus increase for the kernel.
Maybe the cpu_hot temperature should be 68 (just the first passive temp - its hysteresis) and set the hysteresis to 8.
Note this is all guessing. I think 60deg might be a good operation point for the rk3399. All this is influenced by the number of cores that are enabled (big, little) and at what frequency. Some of this might be controlled by the governor selected.
There is unfortunately no pwm for the fan so there is only “all in” when we switch it on. So, as in the script from clockwork, we should switch it on when its already quite hot and let it run for quite a while hoping the cpu governor will enable/disable cpus and scale them to keep up with the performance requirement and also increasing/decreasing the temperature by this.
Update: I did not see that the operation points are included in the dts file. So all fine here. Sorry
Ok I did some experiments and the below settings in the devicetree work well for me. The normal operating temperature when just browsing and such is mostly below 60deg (~57) so the fan starts working only at 60 and above. Due to the higher polling delay it will not stop immediately when below 60. It is tricky I have to say. If you find an operation point that keeps the temp around 60 then the fan will go on/off all the time. But with the settings below it did not happen to me.
An alternative would be to write an own gpio-fan driver and add a timeout to the “disable” function. Here we could add a timeout value to the devicetree. Say 10s, so whenever the kernel switches off the fan it will keep running for another 10s before it goes off.
Also I installed “cpupower” and “cpupower-gui” and with these tools you can nicely configure profiles to your needs. So you can select various governors for the little and big cpus so the temperature stays in range unless you need max power. With these tools there is no need for the gears script so far unless you also want to set the gpu frequency.
Just wanted to say thanks to everyone who put so much effort into getting Manjaro working on the A06. I’ve been having great fun getting it all set up. You’ve done an amazing job!
The only thing I’ve not managed to do is get the thermal printer working. I’ve tried to install devterm_thermal_printer_cups, devterm_wiringpi_cpi, and thermal_printer from https://github.com/clockworkpi/DevTerm/tree/main/Code. It seems to me that they’ve all been successfully compiled and installed, but I can’t seem to get the printer to actually do anything.
Has anyone had any luck with the thermal printer on Manjaro? Am I being really idiotic and going about it completely the wrong way?
In any case, thanks again for the Manjaro port. It’s made me love this wee device even more than I did.
Wow, what a cool thing to have made! Thanks for sharing this!
I tried going through all three folders and doing makepkg -si. All three seemed to install fine, but if I echo something to /tmp/DEVTERM_PRINTER_IN nothing happens. I tried appending
FDTOVERLAYS /overlays/mtp02-a06-devterm.dtbo
to /boot/extlinux/extlinux.conf too, but still no luck. Am I forgetting to do something or misunderstanding something?
I really appreciate any help. It’s a very warm community surrounding the DevTerm.
Thanks so much for responding. I was able to add a printer and print the test page! Your mtp02 programs seem to be working as well. Not much else seems to work though. Apart from the test page, anything that I try to print gets a CUPS response of “Unable to write print data: Invalid argument”. But it’s lovely just to see it printing anything at this point. Thanks again for your help and for setting up the kernelspace driver!
Invalid argument suggests something configured in cups which driver doesn’t expect (like margins). Can you print to file and send it to me to check what is wrong?
