LinuxQuestions.org - Plasma wayland on current

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Plasma wayland on current (https://www.linuxquestions.org/questions/slackware-14/plasma-wayland-on-current-4175677108/)

Plasma wayland on current

Plasma wayland on current with elogind:

one screenshot of the latest version of frameworks, plasma, applications, build with the 'Eric' (alienbob) scripts,

https://alien.slackbook.org/ktown/source

and with the 'Widya Walesa' elogind, polkit, sddm-qt5, scripts:

https://gitlab.com/w41l/kde-elogind,

thank to 'Eric' and 'Widya' for your work ;)

the good news is that it's usable ;)

Nice one! :thumbsup:

However, why we should not going to the Next Level? :D

In the attached screenshots you can admire the Wayland desktop of Plasma 5.19.0 with KDE Frameworks 5.71.0 and the build scripts at all borrowed from Mr. Hameleers' "elogind" branch:

https://git.slackware.nl/ktown/log/?h=elogind

Yes, Mr. Hameleers offered not only amazing good packages but also a Plasma5 build system smart enough to empower a simple user like me to build Plasma and Frameworks in an evening and almost out of headaches, while using a "ferocious" CPU like is Athlon x4 605e with its TDP of 45W.

And as can be seen in the attached screenshots, there's no need for a $1000 graphics card for running Wayland/Plasma5 just like you run the "classic" Plasma5 under X11 - yeah, even an integrated/on-board Radeon HD4250 is enough.

Very cool, guys! Looking forward to KDE5 landing in the -current branch. :)

Quote:

Originally Posted by LuckyCyborg (Post 6134601)

Mr. Hameleers' "elogind" branch:

https://git.slackware.nl/ktown/log/?h=elogind

Hah! I wondered if anyone would ever notice that the ktown repository already has all the scripts for a elogind + Wayland system. Well-spotted.

Quote:

Originally Posted by Alien Bob (Post 6134613)

Hah! I wondered if anyone would ever notice that the ktown repository already has all the scripts for a elogind + Wayland system. Well-spotted.

You wanted to hide them, but we found them, you wouldn't take us for beginners, anyway ? ;)

Nice ;-) Now, I did some preliminary tests in a QEMU VM, with only a couple of packages rebuilt (or added):
accountsservice, autoconf-archive, dbus, elogind, plasma-workspace, polkit, polkit-kde-framework, powerdevil, sddm-qt5, util-linux.

The issues I werewith the X11 sessions, not with Wayland. If started from runlevel 4 I could not logout or reboot. It looks like the polkit rules I add with the powerdevil package are parsed but not active.
If on the other hand I start in runlevel 3, login as root, and type "init4" to start SDDM, then everything works just fine.
I ran out of time to debug this. The polkit files in my git repository are the last version I tried with (and I tried with several iterations).
I never ran this on real hardware, and I also hope that a full new set of Plasma5 packages compiled against elogind will fix those issues I ran into.

Quote:

Originally Posted by Alien Bob (Post 6134629)

Well, I have a normal power control experience from init 4 and SDDM, with autologin to unprivileged user, for a full build of Frameworks 5.71.0 , then of Plasma 5.19.0 , everything against your packages modified for elogind. And this both as Wayland/Plasma5 and X11/Plasma5 .

Compared with a classic KDE4 from slackware-current, however I am unable to reboot/shutdown from init 3 logged in as user and starting the Plasma5 with "startx" , where instead of executing the power commands from Kickoff, the desktop just ends and returns in the Linux console.

However, this way behave my Plasma5 build also in the "classic" ConsoleKit2 style, as I did in another computer.

Start plasma, from the console (init 3 startx) Reboot and shutdown not work, with consolekit or with elogind, since the latests plasma releases.

Quote:

Originally Posted by gmgf (Post 6134855)

Start plasma, from the console (init 3 startx) Reboot and shutdown not work, with consolekit or with elogind, since the latests plasma releases.

I made a change in polkit authorization files in the powerdevil package. In an earlier topic and on my blog there were some suggestions for adding .pkla files to configure the shutdown/reboot/suspend/hibernate options in KDE Plasma but the use of PKLA files has been deprecated since after polkit 0.105 (https://www.freedesktop.org/software...thority.8.html is the most recent man page for it, it was removed in 0.106).
So I removed the .pkla files in my powerdevil package and replaced them with policy rules that should do the same thing. But perhaps they are not working as they should.

Feel free to experiment with the old and the new policy files to see what happens.
New files: https://git.slackware.nl/ktown/tree/...evil?h=elogind
Old files: https://git.slackware.nl/ktown/tree/...evil?h=5_20.05

Ok Eric, with these news polkit rules 'reboot and shutdown' work with starx ;)

Quote:

Originally Posted by gmgf (Post 6134939)

Ok Eric, with these news polkit rules 'reboot and shutdown' work with starx ;)

When you built new packages, did you skip Plasma? I thought you built Plasma 5.19 and that would mean your package has these new rules on board already.

Quote:

Originally Posted by Alien Bob (Post 6134941)

When you built new packages, did you skip Plasma? I thought you built Plasma 5.19 and that would mean your package has these new rules on board already.

i have omit to update /kde/post-install/powerdevil

thanks, Eric ;)

Well, looks like there are some issues in the build system from "elogind" branch.

Long story short, apparently the powerdevil package has some config issues. I managed to build powerdevil packages which works perfectly for both elogind and ConsoleKit2 ways, with the following modifications.

post-install/powerdevil/10-enable-ck2-poweroff.rules

Code:

polkit.addRule(

  function(action, subject) {

    if ( (action.id == "org.freedesktop.consolekit.system.restart" ||

          action.id == "org.freedesktop.consolekit.system.restart-multiple-users" ||

          action.id == "org.freedesktop.consolekit.system.stop" ||

          action.id == "org.freedesktop.consolekit.system.stop-multiple-users")

          && subject.isInGroup("power") ) {

      return polkit.Result.YES;

    }

  }

);

Yeah, looks like the APIs of ConsoleKit2 and elogind are different also by names.

post-install/powerdevil.post-install

Code:

# Move the polkit dbus configuration files to the proper place:

mkdir -p $PKG/etc

mv $PKG/etc/kde/dbus-1 $PKG/etc/



mkdir -p $PKG/etc/polkit-1/rules.d



# Add upower policy allowing users in the 'power' group

# to suspend/hibernate the computer:

install -m 0644 -o root \

  $CWD/post-install/powerdevil/10-enable-upower-suspend.rules \

  $PKG/etc/polkit-1/rules.d/10-enable-upower-suspend.rules.new



if [ "$SLKELOGIND" == "no" ]; then

  # Add ConsoleKit2 policy file that allows users in the 'power' group

  # to shutdown/reboot the computer:

  install -m 0644 -o root \

    $CWD/post-install/powerdevil/10-enable-ck2-poweroff.rules \

    $PKG/etc/polkit-1/rules.d/10-enable-session-poweroff.rules.new

else

  # Add login1 policy file that allows users in the 'power' group

  # to shutdown/reboot the computer:

  install -m 0644 -o root \

    $CWD/post-install/powerdevil/10-enable-elogind-poweroff.rules \

    $PKG/etc/polkit-1/rules.d/10-enable-session-poweroff.rules.new

  # Add powerdevil policy file that allows users in the 'power' group

  # to check for existence of a discrete gpu:

  install -m 0644 -o root \

    $CWD/post-install/powerdevil/10-enable-powerdevil-discrete-gpu.rules \

    $PKG/etc/polkit-1/rules.d/10-enable-powerdevil-discrete-gpu.rules.new

fi

Without those changes, the etc/polkit-1/rules.d/10-enable-session-poweroff.rules.new are not put in packages.

doinst.sh/powerdevil

Code:

config() {

  NEW="$1"

  OLD="$(dirname $NEW)/$(basename $NEW .new)"

  # If there's no config file by that name, mv it over:

  if [ ! -r $OLD ]; then

    mv $NEW $OLD

  elif [ "$(cat $OLD | md5sum)" = "$(cat $NEW | md5sum)" ]; then

    # toss the redundant copy

    rm $NEW

  fi

  # Otherwise, we leave the .new copy for the admin to consider...

}



# Move over the new policy files:

config etc/polkit-1/rules.d/10-enable-upower-suspend.rules.new

config etc/polkit-1/rules.d/10-enable-session-poweroff.rules.new

config etc/polkit-1/rules.d/10-enable-powerdevil-discrete-gpu.rules.new 2>/dev/null

That's because whatever way, we have always the files: etc/polkit-1/rules.d/10-enable-upower-suspend.rules.new and etc/polkit-1/rules.d/10-enable-session-poweroff.rules.new

-------------------------------

So, the new powerdevil packages works fine, and all power control features are executed with success, as I tested in every possible way both in an elogind and a classic ConsoleKit2 builds.

So far so good, but I would like to raise to your attention another issue, rather being lousily than a show-stopper:

While starting X from runlevel 3 console in the elogind way, while load screen is active, you are simply jumped back to the console, like doing an CTRL+ALT+Fx. However, you can switch back to X11 screen with CTRL+ALT+F7 and everything works as usual.

No, it is not a new misfeature, I've seen this behavior since my own elogind experiments based on kde-elogind.

I guess that we need yet another package patched for login1 servers like elogind. Iff we manage to fix even this misfeature, I believe we have a full elogind replacement to the ol' ConsoleKit2 way.

So, could be even the X11 server? Then what we should do with it?

And, finally another question: is there a way to launch a Wayland/Plasma5 session from a runlevel 3 console, like startx?

Trying to launch from console startplasma-wayland ends in a failure with the message:

Quote:

~$ startplasma-wayland
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") )
startplasmacompositor: Could not start D-Bus. Can you call qdbus?

Quote:

Originally Posted by LuckyCyborg (Post 6135055)

Pity you did not supply diffs here, but I hope I can work out your modifications.

Quote:

While starting X from runlevel 3 console in the elogind way, while load screen is active, you are simply jumped back to the console, like doing an CTRL+ALT+Fx. However, you can switch back to X11 screen with CTRL+ALT+F7 and everything works as usual.

No, it is not a new misfeature, I've seen this behavior since my own elogind experiments based on kde-elogind.

I guess that we need yet another package patched for login1 servers like elogind. Iff we manage to fix even this misfeature, I believe we have a full elogind replacement to the ol' ConsoleKit2 way.

So, could be even the X11 server? Then what we should do with it?

I observed similar behaviour in a QEMU virtual machine but I can not recall whether that was in runlevel 3.What I did experience using the QEMU "vmware" graphics, was that elogind thought that my console did not have graphical capabilities and as a result it refused to start a graphical session through "startx". But when I switched the QEMU graphics to "virtio" everything worked as expected and the virtual console switched to the graphical console as it should.

Quote:

And, finally another question: is there a way to launch a Wayland/Plasma5 session from a runlevel 3 console, like startx?

Trying to launch from console startplasma-wayland ends in a failure with the message:

Also this I think I solved, but I can not recall what command to use. As I noted before, I am not 100% OK health-wise and this expresses itself in memory loss.

Quote:

Originally Posted by LuckyCyborg (Post 6135055)

So far so good, but I would like to raise to your attention another issue, rather being lousily than a show-stopper:

While starting X from runlevel 3 console in the elogind way, while load screen is active, you are simply jumped back to the console, like doing an CTRL+ALT+Fx. However, you can switch back to X11 screen with CTRL+ALT+F7 and everything works as usual.

No, it is not a new misfeature, I've seen this behavior since my own elogind experiments based on kde-elogind.

I guess that we need yet another package patched for login1 servers like elogind. Iff we manage to fix even this misfeature, I believe we have a full elogind replacement to the ol' ConsoleKit2 way.

So, could be even the X11 server? Then what we should do with it?

So, testing also the XFCE launching from runlevel 3 console via startx, in an elongid environment, looks like that "involuntary console jump" reported in this previous post does not manifests also with XFCE, but apparently only with Plasma5.

The XFCE desktop goes straight up, without hick-ups. Then, rather looks being a Plasma5 issue - maybe correlated with this particular elogind build.

PS. The power controls from XFCE works fine too after the latest changes in powerdevil build.