Building the Plasma6 for Slackware-current in the KTown style - a build based on the AlienBOB's KTown

ctrlaltca · 05-09-2024, 03:47 AM

I noticed that screencast is not working here.
Window thumbnails are not shown when hovering icons on the panel, and a "screen capture" test fails at https://mozilla.github.io/webrtc-landing/gum_test.html
The error i get is a generic "Can't connect the Pipewire context".
I checked and pipewire seems to be running fine, audio works etc:

Code:

➜  ~ ps x |grep wire 
 7041 tty8     S+     0:00 /usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire /usr/bin/pipewire
 7043 tty8     S+     0:00 /usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire-pulse /usr/bin/pipewire-pulse
 7049 tty8     S+     0:00 /usr/bin/daemon -frB --pidfiles=~/.run --name=wireplumber /usr/bin/wireplumber
 7073 tty8     Sl+    0:00 pipewire-pulse: /usr/bin/pipewire-pulse
 7074 tty8     Sl+    0:00 pipewire: /usr/bin/pipewire
 7075 tty8     Sl+    0:00 wireplumber: /usr/bin/wireplumber

Is it just me? Anyone can confirm/deny this on their installation please?

mumahendras3 · 05-09-2024, 04:12 AM

Quote:

Originally Posted by ctrlaltca

I noticed that screencast is not working here.
Window thumbnails are not shown when hovering icons on the panel, and a "screen capture" test fails at https://mozilla.github.io/webrtc-landing/gum_test.html
The error i get is a generic "Can't connect the Pipewire context".
I checked and pipewire seems to be running fine, audio works etc:

Code:

➜  ~ ps x |grep wire 
 7041 tty8     S+     0:00 /usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire /usr/bin/pipewire
 7043 tty8     S+     0:00 /usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire-pulse /usr/bin/pipewire-pulse
 7049 tty8     S+     0:00 /usr/bin/daemon -frB --pidfiles=~/.run --name=wireplumber /usr/bin/wireplumber
 7073 tty8     Sl+    0:00 pipewire-pulse: /usr/bin/pipewire-pulse
 7074 tty8     Sl+    0:00 pipewire: /usr/bin/pipewire
 7075 tty8     Sl+    0:00 wireplumber: /usr/bin/wireplumber

Is it just me? Anyone can confirm/deny this on their installation please?

I encountered a similar problem quite a while ago in Plasma 5. It seemed like the KWin plugin that handles screen castings (I forgot what its called) were not loaded when running the normal Plasma Wayland session. However, if I used the Full Plasma Wayland session, that plugin was loaded and screen castings finally worked.

LuckyCyborg · 05-09-2024, 04:42 AM

Quote:

Originally Posted by ctrlaltca

I noticed that screencast is not working here.
Window thumbnails are not shown when hovering icons on the panel, and a "screen capture" test fails at https://mozilla.github.io/webrtc-landing/gum_test.html
The error i get is a generic "Can't connect the Pipewire context".
I checked and pipewire seems to be running fine, audio works etc:

Code:

➜  ~ ps x |grep wire 
 7041 tty8     S+     0:00 /usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire /usr/bin/pipewire
 7043 tty8     S+     0:00 /usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire-pulse /usr/bin/pipewire-pulse
 7049 tty8     S+     0:00 /usr/bin/daemon -frB --pidfiles=~/.run --name=wireplumber /usr/bin/wireplumber
 7073 tty8     Sl+    0:00 pipewire-pulse: /usr/bin/pipewire-pulse
 7074 tty8     Sl+    0:00 pipewire: /usr/bin/pipewire
 7075 tty8     Sl+    0:00 wireplumber: /usr/bin/wireplumber

Is it just me? Anyone can confirm/deny this on their installation please?

This behavior is also with my Plasma6 build:

Code:

org.kde.startup: not a reply org.freedesktop.locale1 QDBusMessage(type=Error, service="org.freedesktop.DBus", error name="org.freedesktop.DBus.Error.ServiceUnknown", error message="The name org.freedesktop.locale1 was not provided by any .service files", signature="s", contents=("The name org.freedesktop.locale1 was not provided by any .service files") )
dbus-daemon[4967]: [session uid=1001 pid=4967] Activating service name='org.kde.KSplash' requested by ':1.0' (uid=1001 pid=4968 comm="/usr/bin/startplasma-wayland")
dbus-daemon[4967]: [session uid=1001 pid=4967] Activating service name='org.freedesktop.portal.Desktop' requested by ':1.4' (uid=1001 pid=4976 comm="/usr/bin/kwin_wayland --wayland-fd 7 --socket wayl")
dbus-daemon[4967]: [session uid=1001 pid=4967] Activating service name='org.freedesktop.portal.Documents' requested by ':1.6' (uid=1001 pid=4985 comm="/usr/libexec/xdg-desktop-portal")
dbus-daemon[4967]: [session uid=1001 pid=4967] Activating service name='org.freedesktop.impl.portal.PermissionStore' requested by ':1.8' (uid=1001 pid=4992 comm="/usr/libexec/xdg-document-portal")
No backend specified, automatically choosing drm
dbus-daemon[4967]: [session uid=1001 pid=4967] Successfully activated service 'org.freedesktop.impl.portal.PermissionStore'
dbus-daemon[4967]: [session uid=1001 pid=4967] Successfully activated service 'org.freedesktop.portal.Documents'

(/usr/libexec/xdg-desktop-portal:4985): xdg-desktop-portal-WARNING **: 11:19:17.592: Failed to load RealtimeKit property: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.RealtimeKit1 was not provided by any .service files

(/usr/libexec/xdg-desktop-portal:4985): xdg-desktop-portal-WARNING **: 11:19:17.592: Failed to load RealtimeKit property: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.RealtimeKit1 was not provided by any .service files

(/usr/libexec/xdg-desktop-portal:4985): xdg-desktop-portal-WARNING **: 11:19:17.593: Failed to load RealtimeKit property: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.RealtimeKit1 was not provided by any .service files
dbus-daemon[4967]: [session uid=1001 pid=4967] Activating service name='org.freedesktop.impl.portal.desktop.kde' requested by ':1.6' (uid=1001 pid=4985 comm="/usr/libexec/xdg-desktop-portal")
kwin_screencast: Failed to connect PipeWire context
...

Aparently, the xdg-desktop-portal wants org.freedesktop.locale1 and org.freedesktop.RealtimeKit1. Still wondering how to avoid them.

Ideas? My bet is on org.freedesktop.RealtimeKit1 .

rizitis · 05-09-2024, 05:31 AM

Quote:

Originally Posted by LuckyCyborg

Aparently, the xdg-desktop-portal wants org.freedesktop.locale1 and org.freedesktop.RealtimeKit1. Still wondering how to avoid them.

Ideas? My bet is on org.freedesktop.RealtimeKit1 .

Install systemd

I think you must patch xdg-desktop-portal-kde...but first rebuild xdg-desktop-portal just in case...
EDIT: -Dsystemduserunitdir="/usr/lib/systemd/user" \

ctrlaltca · 05-09-2024, 05:58 AM

Quote:

Originally Posted by LuckyCyborg

Aparently, the xdg-desktop-portal wants org.freedesktop.locale1 and org.freedesktop.RealtimeKit1. Still wondering how to avoid them.

Ideas? My bet is on org.freedesktop.RealtimeKit1 .

I don't get the error related to RealTimeKit1 and locale1:

Code:

xdp-kde-wayland-integration: failed to start streaming ScreencastingStream(0x27cc2c0) "Impossibile connettere il contesto PipeWire"
xdp-kde-screencast: Invalid window! QMap((0, QVariant(QString, "~ : tail — Konsole"))(1, QVariant(QIcon, QIcon("utilities-terminal",availableSizes[normal,Off]=QList(QSize(16, 16), QSize(22, 22), QSize(32, 32), QSize(48, 48), QSize(64, 64), QSize(128, 128), QSize(256, 256)),cacheKey=0x400000000)))(257, QVariant(QString, "org.kde.konsole"))(258, QVariant(bool, false))(259, QVariant(bool, true))(260, QVariant(bool, false))(261, QVariant(bool, true))(262, QVariant(bool, true))(263, QVariant(bool, true))(264, QVariant(bool, false))(265, QVariant(bool, false))(266, QVariant(bool, false))(267, QVariant(bool, false))(268, QVariant(bool, false))(269, QVariant(bool, false))(270, QVariant(bool, false))(271, QVariant(bool, false))(272, QVariant(bool, true))(273, QVariant(bool, true))(274, QVariant(bool, true))(275, QVariant(bool, true))(276, QVariant(QRect, QRect(0,0 1536x832)))(277, QVariant(uint, 29519))(278, QVariant(bool, false))(279, QVariant(QStringList, QList("5d2bbbd2-f0aa-4a72-ab99-2543544ae557")))(280, QVariant(QByteArray, "{d5d4d463-b3f4-4036-a607-9d8327b81827}")))
Service  ":1.83" unregistered
error creating screencast "Impossibile connettere il contesto PipeWire"

Tried to install rtkit from SBo anyway, no change

gmgf · 05-09-2024, 06:26 AM

https://www.freedesktop.org/software...p.locale1.html
This error message has been present in Slackware for a long time, in principle it does not cause any real problem.

rizitis · 05-09-2024, 06:53 AM

I have one question: are you sure that pipewire-{pulse} & wireplumber start before plasma session starts?

ZhaoLin1457 · 05-09-2024, 07:20 AM

Quote:

Originally Posted by rizitis

I have one question: are you sure that pipewire-{pulse} & wireplumber start before plasma session starts?

I think this is a good question.

rizitis · 05-09-2024, 07:33 AM

Quote:

Originally Posted by ZhaoLin1457

I think this is a good question.

I just remembered that we had similar issues when we started building Gnome before 2-3 years. I dont remember the fix... it was not me who fixed it. But you can add a delay to plasma start 10" or something similar and check... also this tool is very good and simple to see what is connecting to what... I think similar tools are in SBo also...

EDIT: if i remember right problem was wireplumber started after gnome session.
EDIT2: the gnome record-desktop app is builded in gnome-shell is the same for kwin_screencast in plasma6?

ctrlaltca · 05-09-2024, 08:57 AM

So, attached is a patch for plasma/kwin fixing the issue.
Now trying to get it upstreamed..
EDIT: https://invent.kde.org/plasma/kwin/-..._requests/5706

LuckyCyborg · 05-09-2024, 10:52 AM

Quote:

Originally Posted by ctrlaltca

So, attached is a patch for plasma/kwin fixing the issue.
Now trying to get it upstreamed..
EDIT: https://invent.kde.org/plasma/kwin/-..._requests/5706

I confirm that your (minimally invasive) patch does REALLY fixes the PipeWire support on KWin. Many thanks!

However, that bug report (which you linked in the pull request) makes me wonder if the situation isn't nastier than this...

I talk about this:

https://bugs.kde.org/show_bug.cgi?id=483668

Sooo, if the PipeWire daemons crashes (and from my long experience with them, they crashes sometimes, even it's a rare case) and even if our daemon supervisor promptly does its duty and restarts them on place, seems like the KWin link will be lost. It's not even an issue specific to our daemon supervisor usage, as may happen well even on a systemd driven system.

What do you think about this point?

ctrlaltca · 05-09-2024, 12:13 PM

David Edmundson came up with a better patch that fixes also the reconnect on pipeware crash:
https://invent.kde.org/plasma/kwin/-...cebd6b62fce5dc

LuckyCyborg · 05-10-2024, 12:49 AM

Quote:

Originally Posted by ctrlaltca

David Edmundson came up with a better patch that fixes also the reconnect on pipeware crash:
https://invent.kde.org/plasma/kwin/-...cebd6b62fce5dc

I confirm that the patch made by Mr. Edmundson works quite well, and indeed it keep the KWin's link active after a Pipewire daemons sudden disappearance, which forces the daemon supervisor instances to restart them.

sombragris · 05-10-2024, 11:04 AM

Quote:

Originally Posted by LuckyCyborg

@sombragris

Regarding the issue with the characters, I am really sorry, but I cannot confirm it. My system insists to display properly the name of Michał Klauza, both on Konsole and Dolphin, also the files looks like being extracted properly. I believe that's either an issue with your language setup, either your system is really "dirty" and a clean install may be necessary. Please note that my -current installation used to experiment with Plasma6 is no longer than a month old. I have did a clean install for building "clean" the packages for the first build from this thread.

Thanks. I imagined that something is b0rked on my system just as well. But I think I found the issue and the solution.

Whenever I had a filename / directory name with international characters, my terminal would show after a "ls" command:

Code:

Barrios\ Mangor\303\251\ Leyenda\ -\ Ozan\ Saritepe

While the proper spelling es Mangoré. Then, after typing "cd" and letting autocomplete do its job, the international (accented) character showed well.

My first hint came when I started a Plasma 6 app from the terminal. I got this message:

Code:

Detected locale "C" with character encoding "ANSI_X3.4-1968", which is not UTF-8.
Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead.
If this causes problems, reconfigure your locale. See the locale(1) manual
for more information.

Here, "ANSI_X3.4-1968" is some minor revision of standard ASCII, so the terminal told me that basically Qt was objecting that my locale was configured to ASCII. That was funny because I remember configuring everything to UTF-8.

Examining the output of 'locale' told me that everything was set up correctly, except LC_ALL, which was not set at all.

I edited /etc/profile.d/lang.sh and added EXPORT LC_ALL=en_US.UTF-8 and rebooted.

Result: Now the filenames display properly in the terminal.

This is what seems to have happened:

1. This was never picked up by Qt5.
2. Maybe, just maybe, my LC_ALL was never set to anything; or
3. Perhaps my regional personalization in Plasma6 System Settings messed up that localization.
4. Qt6 is very picky about locales, and objected to my unset LC_ALL.
5. Now that I'm using Qt6 to render the whole desktop, then this issue showed its ugly head.

So my takeaway from all this is that Qt6 and thus Plasma6 is much pickier about locales than Qt5; check that your locale structure is properly set.

And we can tentatively consider this particular issue as settled.

LuckyCyborg · 05-10-2024, 06:54 PM

Well, when I started this Plasma6 build, I was fully aware that I will enter in Kazachok, soo ...

There is a patch for the second Plasma6 build of mine, in the form of a tarball named plasma6-patch-20240510.tar and sized as 185.38MB . Yep, this is a relative small one and you can find it there for the next 30 days:

https://easyupload.io/fpsf8j

And its checksum is:

Code:

9113053d4c0e3609711a25b42bf89fdc4450457acbc6ad2a6201ac492bc74a86  plasma6-patch-20240510.tar

This tarball contains both updated packages and a patch for the source tree. The packages includes the new KDE Frameworks 6.2.0 , also kirigami-addons-1.2.0 and 2 rebuilds for KWin and plasma-workspace.

The KWin package was rebuilt for patching the Pipepire issue on KWin, by using the upstreamed !5708 patch (aka the one made by Mr. Edmundson and based on the work of our fellow @ctrlaltca) . This fixes the PipeWire issue on Wayland/Plasma6 sessions and everything related works again. Many thanks again, @ctrlaltca!

In other hand, I have noticed that Mr. Hameleers patched the Wayland/Plasma6 session in something which is roughly similar with the Plasma (Full Wayland) session as we know on Plasma5. Well, honestly I wanted to see Plasma6 acting as intended, without forcing "wayland" for every little application. So, in a way similar to Plasma5, I have "restored" the Full Wayland sessions, while leaving the stock Wayland sessions alone, as they are intended by upstream.

Finally, the kirigami-addons-1.2.0 is an update made upstream - but I for one I consider it an important one, worth to be particularly shipped in a patch.

PS. For those who wonder what's Kazachok, well ... it's a popular fast paced (and rather acrobatic) dance, practiced by the young ones of several Slavic nations. Supposedly, it was invented by and for the Cossack Cavalry - who hundreds of years ago was an elite force of the Tsarist Empire.