It is in the AUR, but it is also in the main Manjaro repositories.
In general yes. But some/most packages will fail to build, because they don’t have the correct architecture (aarch64) set.
Thanks, but it’s tricky.
In Pamac, if you type raspberry or raspberry pi or raspberry pi imager, you don’t get it at all.
But if you just type rpi or rpi imager, bingo it’s listed and you can get it!
Well understood for the AUR repo.
A question regarding my other issues with HDMI, JACK/ALSA, Pure Data and GPIO:
Is it here the right place for discussing them or do I have to go somewhere else in the forum or proceed by an other way?
I do reconfirm that on my RPi 400 Manjaro-Arm is performing much better than RPi OS 32-bit including playing videos. In add with Manjaro the users are getting the latest and up-to-date software packages which really make a significant difference, especially for me in the Audio/MIDI area.
Outstanding job done by the developers and contributors! 
Best,
That’s because the package name is rpi-imager, not raspberrypi-imager. 
1 Like
Well… but my point was either the developers/contributors name it “rpi” or “raspberrypi” or “something else”… but they keep always the same prefix for everything related to the Raspberry Pi!
Back to Raspberry Pi 400 and GPIO not working, see my above June 5th post.
GPIO: I installed all the 4 available packages from the software center;
i.e. gpio/utils, libgpiod, python-gpiozero and python-raspberry-gpio.
Then running ‘pinout’ in a terminal prints:
....
....
....
ModuleNotFoundError: No module named ‘colorzero’
So I cannot access to the GPIO.
After further investigations, I found that the “GPIO” group doesn’t exist, when it’s supposed to be created and the current user added to it during the installation of above 4 packages.
[joe@RPi-400 ~]$ groups joe
sys network power wheel audio input lp storage video users joe
[joe@RPi-400 ~]$ cat /etc/group
root:x:0:root
sys:x:3:bin,joe
mem:x:8:
ftp:x:11:
....
....
joe:x:1000:
cups:x:209:
saned:x:969:
rpc:x:32:
But no GPIO!
So, what is Manjaro-Arm right procedure for installing GPIO on RPi 4/400 (I’m not authorized to included any link) and having it working?
Thanks.
This package has not worked for a while, not without modifying the pkgbuild for version 0.7.1a3 or newer. There are threads about building this, some about gpio and some about the argonone case which uses the gpio to control the fan.
You did not mention needing to do anything special for the installation, so thought I would mention it.
The python-raspberry-gpio version in our repo and Python’s latest version 0.7.0 are the same but since our python upgrade our package will not build and they have not changed their code to be compatible. If you can not run as root (if you have not made the changes in /etc/group) then it is most likely a python version issue.
@Darksky
Thanks, well understood.
It’s still a shame that developers are not standardizing their packages prefixes naming. It’s just confusing the std users.
@0n0w1c Thanks for your reply.
I installed with Pamac (GUI) python-raspberry-gpio in version 0.7.0-2 compiled in 2020/09/11.
So, at least this package is not at the needed version.
Unfortunately I’m not enough expert to compile it.
The installation of the 4 available packages; i.e. gpio/utils, libgpiod, python-gpiozero and python-raspberry-gpio, went well without any error alert.
It’s only when trying to do basic testing with “pinout” (part of the GPIO ZeroPython library) I had the above mentioned errors. The installed version is 1.6.2-1.
This command is working well out of the box with RPi OS (32-bit).
@Darksky Thanks for your answer.
I’m just a standard user, with some experience, but not an expert and each distribution has its own rules and behaviors which are not obvious to follow and sometime to understand.
So, with the stable branch of Manjaro-Arm for the RPi I was expecting to have a system which is +/- working.
This is almost the case with Manjaro when used as a general purpose OS.
But unfortunately not when it’s specific to the RPi 400.
So, even if Manjaro-Arm is a great distribution and I like it, I can’t fully use it with my RPi 400.
I’m sorry for myself but for the time being I have to return to RPi OS where everything is working well.
This U-boot update seems to have fixed some issues I’d been having w/ Sway community edition on PBP. Previously, boot would hang after reboot (as opposed to full power off/power on), and would also hang if I closed laptop, opened it, and then turned off and on. Both issues are gone now!
2 Likes
So, I’m responding to myself…
I’m currently testing Ubuntu MATE 20.10 (21.04 not available yet) for ARM 64-bit on my new RPi 400 (Ubuntu Mate 20.04.1 LTS for Arm 64 is not booting at all).
Regarding GPIO, it’s definitively much easier than with Manjaro-Arm. It’s working almost out-of-the-box. Just need to install the “python3-gpiozero” v.1.4.1 which will also install the following 2 packages: “rpi.gpio-common:arm64” v. 0.7.0 & “python3-rpi.gpio” v. 0.7.0, with current Python v.3.8.6 already installed.
As by default… The “gpio”, “i2c”, “input” and “spi” groups are directly pre-created by the distribution and the User created using the first-boot wizard is automatically added to the groups above… The user is ready to go with GPIO and to build on top of it!
joe@rpi-400:~$ groups joe
joe : joe adm cdrom sudo dip video plugdev input lxd lpadmin gpio i2c spi sambashare
“pinout” in a terminal gives the expected output (still for RPi 4 but not for RPi 400 yet).
- It would be very helpful that Manjaro-Arm could achieve the same for at least the RPi 4 & 400.
Thanks
PS: On at least RPi 400, the ARM 64-bit OSs (Manjaro MATE - Xfce & Ubuntu MATE) are definitively much reactive-faster than their 32-bit counterparts !
Those are groups that do not exist on a linux system by default. So we would first have to create them. In general we don’t create extra groups.
Regarding the gpiozero package. I’m pretty sure we have the latest release packaged. Seems like Ubuntu packages a pre-release of that software, probably because the Ubuntu ARM thing only has Raspberry Pi to support, so it would make sense for them to go out of their way to packages Raspberry Pi specific software, before it has a proper release.
On my PBP after the uboot update, my kernel wouldn’t boot anymore. I was able to boot from a USB thumb drive and remove a second output kernel parameter from my extlinux.conf, after which the PBP booted fine.
What line was that? And what do you have now?
I misremembered, in fact, I removed two things:
video=HDMI-A-1:1920x1080@60 bootsplash.bootfile=bootsplash-themes/manjaro/bootsplash
It might have been the bootsplash aswell, but it didn’t cause problems before, so I doubt that.
Now, this is my initrd line:
APPEND initrd=../initramfs-linux.img console=tty1 <encryption stuff removed> rw rootflags=subvol=@ rootwait suspend initcall_debug video=eDP-1:1920x1080@60
1 Like
On Pinebook Pro in KDE Plasma the graphics problems appeared in KDE applications, e.g. Konsole and Kate, if there is a lot of text in either of them, scrolling up would cause appearing contents from other application e.g. in Kate or Konsole window instead of text there are fragments of the page from Firefox. This is something new.
This could be an issue in mesa 21.1.1. Should be fixed in 21.1.2, which is currently in testing.