Hi,
Odroid c2 kde and odroid n2 kde up to date, they work.
How did it go with your PBP? Have you been able to solve thte issue?
Hi, I still can’t reach desktop after the last update. The desktop remains loading without finishing proposing the password. I’m on rockpi4b (manjaro 20.10) and this happens with the last update (2020/11/08)
Can somebody help me?
Alright! I got my SD card in and was able to reinstall and get OBS etc working.
Are you having odd behavior with mntray though? A left click brings up a window; right click brings up what I’d expected out of a left click.
Other than a few theme oddities (the package manager GUI being blue instead of green, etc) and that it so far seems good, and running well. I do appreciate your assistance getting me here.
EDIT: I realized immediately after posting this that I was starting with Plasma Wayland. Switching off fixed all of the oddball issues.
1 Like
I updated my PBP last week. Everything seemed fine at the time. I continued using it and then shut it down. It froze on the splash screen though next time I booted (circling dots freeze). Is there a keystroke I can use at boot to make the initialization verbose? I use KDE. I’m temporarily displaced, so creating a bootable SD card to fix it is a bit of a challenge right now.
In a manner of speaking. I loaded a fedora cinnamon SD card to troubleshoot and then decided to try it for a bit.
I was able to boot manjaro xfce from an SD yesterday without issue. So I suspect that a nuke and pave would have solved the problem.
Hi. I’m trying to log in with Xfce 20.10 release on Rockpi4. After updating the system, when I reboot, I am left with the manjaro icon without being able to start desktop. Before the first reboot, reach to get this information:
System status lightdm.service - Light Display Manager
Loaded: loaded (/usr/lib/systemd/system/lightdm.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2020-11-17 19:22:17 -03; 17min ago
Docs: man:lightdm(1)
Main PID: 648 (lightdm)
Tasks: 4 (limit: 4461)
Memory: 148.6M
CGroup: /system.slice/lightdm.service
├─648 /usr/bin/lightdm
└─654 /usr/lib/Xorg :0 -seat seat0 -auth /run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
nov 17 19:22:17 GG systemd[1]: Starting Light Display Manager…
nov 17 19:22:17 GG lightdm[648]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not prov>
nov 17 19:22:17 GG systemd[1]: Started Light Display Manager.
nov 17 19:22:18 GG lightdm[669]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not prov>
nov 17 19:22:18 GG lightdm[669]: pam_unix(lightdm-greeter:session): session opened for user lightdm(uid=972) by (uid=0)
nov 17 19:22:24 GG lightdm[718]: pam_systemd_home(lightdm:account): Not a user managed by systemd-homed: No home for user gg known
nov 17 19:22:24 GG lightdm[718]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not prov>
nov 17 19:22:25 GG lightdm[648]: g_dbus_connection_call_sync_internal: assertion ‘G_IS_DBUS_CONNECTION (connection)’ failed
nov 17 19:22:25 GG lightdm[718]: pam_unix(lightdm:session): session opened for user gg(uid=1000) by (uid=0)
I have the same problem. I’m using Raspberry Pi 4 4GB, KDE desktop, and an SSD as both boot and root partition. It’s stuck at either “started hostname service”, “starting network manager script dispatcher service” or “started network manager script dispatcher service”
@Darksky This is my config.txt:
gpu_mem=64
initramfs initramfs-linux.img followkernel
kernel=kernel8.img
arm_64bit=1
enable_gic=1
disable_overscan=1
dtparam=audio=on
hdmi_drive=2
dtoverlay=vc4-fkms-v3d
max_framebuffers=2
over_voltage=6
arm_freq=2000
hdmi_mode:0=82
hdmi_group:0=2
hdmi_force_mode:0=1
hdmi_ignore_edid:0=0xa5000080I have not tested on the pi4 4G. Will do now…
Many thanks for your time! Although I cannot go into desktop, I could SSH into it so I can start services all fine. So it’s not an urgent issue to fix 
I am at a loss right now. My pi4 4G booted ok also. Do you all have the new firmware-raspberrypi in the unstable branch?
I’m not sure… could you please give me a command to check and I’ll paste the output here?
Change over_voltage=6 to over_voltage=5 in your config.txt and see if it makes a diff. That is what I have.
Just tried over_voltage=5 but still stuck at “Started Hostname Service”…
It just sunk into my head that I thought you had an issue I was helping a member in another thread which was totally different. I have seen 2 or 3 posts with the update with people running KDE like yours which I do not run.
I don’t know if you fixed it, this is resolved in another topic:
Updated the Sway image to the most recent packages a couple of days ago. Today when trying to setup my external display configuration I noticed that the wdisplays utility is no longer working. I investigated a bit and noticed that there has been some changes in the underlying wlroots protocol. The version in the AUR already includes a patch file that updates the sources accordingly.
So I did compile the AUR variant locally and this works fine. @Strit can we eventually update the wdisplays PKGBUILD in the community repo to match the one from AUR?
Thanks a lot,
Andreas
1 Like
There are patches for ffmpeg to add v4l2_request support.
I’ve found that with ffmpeg 4.2.2 + v4l2_request, it has working HW decode for mpeg2 and h264, but not h265. With ffmpeg 4.3 the support for h264 is broken.
Unfortunately, this is not enough to get mpv working with HW decode.
libva-v4l2-request should be able to provide hwdec for applications that use vaapi (such as mpv). It needs patches to work with v4l2_request, but the Manjaro-arm package already includes these. But mpv + vaaapi + libva-v4l2-request doesn’t work either.
So all that seems to work at this point is displayless decoding with ffmpeg of mpeg2 and h264.
Exactly the reason we are not pursuing it much. It’s complicated and nothing seems to be upstream yet.
But as the stateless drivers moves away from staging (could be in 5.11), ffmpeg and others should be able to implement the changes without much issue.