Please try to change channel 1-11 , not 12 , 13.
I’m actually using 6 and 11, so not the case, but thanks for suggestion
After the update, audio stopped to work for me on rpi4 using pipewire-pulse (no audio devices found).
Tryed to remove custom configuration (~/.config/pipewire) but issue not solved.
Solved switching back to pulseaudio.
Strange. I have been using pipewire for months with XFCE and have no issues.
Just working, no issues with performance of KDE Plasma all effects ‘wobbly’ ‘transparency’ are on. Big thanks!
The solution for providing more meaningful RPi4 audio output choice names given in post Set proper audio device names on Raspberry pi 4 - #21 by dbeach does not work after the update. The solution had lines such as these added to /etc/pulse/default.pa:
### Set meaningful output device descriptions for UI update-sink-proplist alsa_output.platform-bcm2835_audio.stereo-fallback device.description='HDMI1' update-sink-proplist alsa_output.platform-bcm2835_audio.stereo-fallback.2 device.description='HDMI2' update-sink-proplist alsa_output.platform-bcm2835_audio.stereo-fallback.3 device.description='Headphone Jack'
Following the update, this set of errors is thrown for each of the update lines because the sink names have changed:
Jun 02 05:53:29 pi002.adbuco.com pulseaudio: No sink found by this name or index. Jun 02 05:53:29 pi002.adbuco.com pulseaudio: Failed to initialize daemon due to errors while executing startup commands. Source of commands: /etc/pulse/default.pa Jun 02 05:53:29 pi002.adbuco.com systemd: Failed to start Sound Service.
Use pacmd list-sinks to find the new sink names that apply your kit and update /etc/pulse/default.pa something like this:
### Set meaningful output device descriptions for UI update-sink-proplist alsa_output.platform-fef00700.hdmi.iec958-stereo.monitor device.description='HDMI1' update-sink-proplist alsa_output.platform-fef05700.hdmi.iec958-stereo.monitor device.description='HDMI2' update-sink-proplist alsa_output.platform-bcm2835_audio.stereo-fallback.monitor device.description='Headphone Jack'
Just discovered that the issue was with wireplumber (No devices detected after update to 0.4.10 (#254) · Issues · PipeWire / wireplumber · GitLab).
Updated my custom config files and it started to work again.
I am also experiencing mouse issues with this update. My /boot/config.txt did not have
dtoverlay=vc4-fkms-v3d at all. I added
dtoverlay=vc4-kms-v3d-pi4 to the end of my config.txt and rebooted. Still experiencing poor mouse movements.
OS: Manjaro ARM Linux aarch64
Host: Raspberry Pi 4 Model B Rev 1.2
DE: Plasma 5.24.5
Post your config.txt.
dtoverlay=vc4-kms-v3d-pi4 is dated.
I removed the -pi4 and the mouse behaviour is much better, however not as precise as it was prior to the update.
root=PARTUUID=d4b3105c-02 rw rootwait console=serial0,115200 console=tty3 selinux=0 quiet splash plymouth.ignore-serial-consoles smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=serial0,115200 audit=0 dtoverlay=vc4-kms-v3d
Thank you for the assistance.
I do not know if you removed
usbhid.mousepoll=8 in your cmdline.txt trying to get things working or not but add it back and see if it makes a diff.
From the looks of things you added
dtoverlay=vc4-kms-v3d to boot/cmdline.txt. Remove it and add it to /boot/config.txt.
cmdline.txt should look like this when done:
root=PARTUUID=d4b3105c-02 rw rootwait console=serial0,115200 console=tty3 selinux=0 quiet splash plymouth.ignore-serial-consoles smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=serial0,115200 audit=0 usbhid.mousepoll=8
config.txt should have this when done (not dtoverlay=vc4-fkms-v3d):
I did remove
usbhid.mousepoll=8 to see if it would help. I have re added.
Doh you are correct I was editing cmdline.txt not config.txt.
Made the changes to the correct files and the mouse is perfect again.
Thank you very much!
I can’t update because of QEMU dependencies.
could not satisfy dependencies:
- unable to satisfy dependency ‘edk2-ovmf’ required by qemu-system-x86
- unable to satisfy dependency ‘seabios’ required by qemu-system-x86
- unable to satisfy dependency ‘qemu-system-x86’ required by qemu-desktop
- unable to satisfy dependency ‘edk2-armvirt’ required by qemu-system-aarch64
- unable to satisfy dependency ‘qemu-system-aarch64’ required by qemu-emulators-full
The previous kernel update renamed the kb151 driver, causing loss of function in the Pinephone keyboard case. I worked around this by using the userspace driver.
The good news is, this update seems to make the kernel driver functional again. The bad news is, it’s missing some keys. Shift-Fn-# combinations for extra punctuation are not functional. Worse, I can’t seem to use the userspace driver as a workaround anymore, as it seems to create a conflict that stops the keyboard from working…
A fellow Pinephone user @Ho0k and I are getting flustered… Does anyone know specifically what changed, so I can perhaps undo it? Or have we just missed something important/obvious?
[Edit: We did see megi’s blog to use a custom keymap to get these back, mapped to Pine-1…0, but this was not successful either]
Hello. Pinebook 1080p with manjaro swaywm user here.
After the last update, sometimes (once in a day or two) when I “wake up” my pinebook, the cpu indicator shows 100% and you can not launch new stuff. You can move between workspaces, close windows, but when you try to run something new via launcher, open new terminal or write some command to terminal, nothing happens. Even switching to virtual non-graphic consoles (CTRL+ALT+Fx) doesn’t work. The only thing you can do is switch workplaces, close opened windows and power down by long pressing the power button.
Does anybody experienced something similar?
Note: I don’t really put the pinebook to sleep, just turn of the monitor.
Note2: Before the last update nothing like this happened, and the pinebook didn’t need to be shut down/restarted for weeks.
I did what you said and my rasberry pi no longer boots so I had to go to another computer to re-edit the files and put fkms back so nothing changed;
Can you help me
I’ve been holding off on updating my Pinebook Pro because of this bug. Is rolling back to the old kernel the only fix/workaround?
I suggest you try. Wifi is working fine with on my PBP with 5.18.
Interesting, I still cannot get mine work, only keeping 5.17 helps…
The only error in dmesg is
brcmf_escan_timeout: timer expired
Hmm, some progress there:)
Probably what I’ve got is actually crda issue, not kernel/driver one
I’m on Ukraine regdomain, so as my access points.
Changed regdomain on PBP to US and it instantly worked!