Adam Jackson On The State Of The X.Org Server In 2020

[oiaohm]

stop talking bullshit. None of that is true, all of that is false. X11 is not network transparent. Repeating this wrong claim doesn't make it more true. And nobody is working on "X12" and there will never be "X12". Wayland is the successor of X. Period.

Sorry really go back in check your history. Wayland lead developer does reference X12. Wayland as successor to X11 does not start in a vacuum or from no where.

https://www.linux-magazine.com/Online/Features/Is-Wayland-the-New-X

Historic X11 was network transparent then with collected changes it ceased to be functional that way. Yes due to early X12 being early reference of Wayland leads to the lead developer of Wayland making the first proto example that leads to waypipe.

X12 design ideas is where Wayland comes from. Also the never will be X12 means you did not read the X12 page. The reality is X12 is able to be assigned to a solution that does everything that is X12 document in future. That is the way it designed. Nobody working on X12 is the way X12 development is as X12 will be a rubber stamp on the solution at the end.

Reality Wayland can be the success to X and also be what in future gets rubber stamped as part of X12.

[karolherbst]

Seeing them is not that straight forwards with the wrong ideas.

https://www.x.org/wiki/Development/X12/

First thing you need to be aware of is that Wayland is part of process to get to X12. Note part. X12 requires that network transparency be supported but must be secure.

One of the things Wayland brings back even that the protocol itself does not support network transparency is functional network transparency.

https://gitlab.freedesktop.org/mstoeckl/waypipe/

Yes this is true functional network transparency with opengl and vulkan support.

If you be realistic you are not going to use X11 native network transparency because if a network connection drops out for any reason you application dies.

https://xpra.org/trac/wiki/Usage/OpenGL

stop talking bullshit. None of that is true, all of that is false. X11 is not network transparent. Repeating this wrong claim doesn't make it more true. And nobody is working on "X12" and there will never be "X12". Wayland is the successor of X. Period.

I wished people not having any insights and any clue would just stop continue to speak about things they just have no frigging idea about.

[oiaohm]

I tried with kubuntu.

Without pkexec there is no access to the disks (as when using X).

On am on debian testing and under X11 and I run partitionmanager without pkexec I have to do a polkit agent to allow "org.kde.kpmcore.externalcommand.init". Then the complete partitionmanager GUI runs as non root and it using that org.kde.kpmcore.externalcommand to run what it needs to as root. So on my system I have full access to disks without the main GUI parts running as root. Yes I still need pkagent

Your code above does work, better then expected, apart from the problems of becoming root. But with a fantastic amount amount of errors:
~$ waypipe ssh ferry@kalamata partitionmanager -platform wayland
Error: could not determine $DISPLAY.
Could not load plugin for core backend "" : "The shared library was not found."
Loaded backend plugin: "pmsfdiskbackendplugin"
Using Wayland-EGL
Using the 'xdg-shell' shell integration
QDBusError("org.freedesktop.DBus.Error.UnknownObje ct", "No such object path '/Helper'")
...
QDBusError("org.freedesktop.DBus.Error.UnknownObje ct", "No such object path '/Helper'")
"Gebruiken van backend-plugin: pmsfdiskbackendplugin (1)"
"Apparaten aftasten..."
QDBusError("org.freedesktop.DBus.Error.UnknownObje ct", "No such object path '/Helper'")
QDBusError("org.freedesktop.DBus.Error.UnknownObje ct", "No such object path '/Helper'")
"Aftasten voltooid."
qt.qpa.wayland: Non-toplevel surfaces can't request window states
...
qt.qpa.wayland: Non-toplevel surfaces can't request window states
S466280: 18.082986 [src/mainloop.c:866] application has closed

I can see this all will be a fantastic thing, in the future, when it's completely ready.

The QDbusErrors that kind of a generic issue. Since you have not started all the desktop stuff remote items are missing.

"Non-toplevel surfaces can't request window states" that is a code issue in the application that comes out when something is used that use to use xcb that has not been cleaned up. Under X11 you really are not meant to request windows status from non-toplevel surfaces as X11 windows managers by specification are not required answer those requests correctly but most windows managers do(depending on not to specification behaviour). So that is not a bug in waypipe that a bug in partitionmanager code that has gone not noticed. This is something that happens a bit porting application to wayland is non X11 specification conforming code in a lot of cases comes error.

But now you have seen waypipe. You should be able to now see the that a missing feature with Wayland there needs to be the question asked should this be in Wayland or should this be some third party part. Those wanting remote usage with wayland really should be up their distribution ribs to have waypipe included. More users more testing more maintainers all will help waypipe development speed.

Hard reality Wayland protocol should not be expected todo everything X11 protocol does. But a wayland desktop should be expected that you can get the right third parties for it so you can. Annoying items like waypipe don't have enough coverage.

[ferry]

waypipe ssh ferry@kalamata partitionmanager -platform wayland

The -platform bit there is to force wayland backend usage out of qt. Minor distribution and configuration differences can be a pain.

I tried with kubuntu.

Without pkexec there is no access to the disks (as when using X).

Your code above does work, better then expected, apart from the problems of becoming root. But with a fantastic amount amount of errors:
~$ waypipe ssh ferry@kalamata partitionmanager -platform wayland
Error: could not determine $DISPLAY.
Could not load plugin for core backend "" : "The shared library was not found."
Loaded backend plugin: "pmsfdiskbackendplugin"
Using Wayland-EGL
Using the 'xdg-shell' shell integration
QDBusError("org.freedesktop.DBus.Error.UnknownObje ct", "No such object path '/Helper'")
...
QDBusError("org.freedesktop.DBus.Error.UnknownObje ct", "No such object path '/Helper'")
"Gebruiken van backend-plugin: pmsfdiskbackendplugin (1)"
"Apparaten aftasten..."
QDBusError("org.freedesktop.DBus.Error.UnknownObje ct", "No such object path '/Helper'")
QDBusError("org.freedesktop.DBus.Error.UnknownObje ct", "No such object path '/Helper'")
"Aftasten voltooid."
qt.qpa.wayland: Non-toplevel surfaces can't request window states
...
qt.qpa.wayland: Non-toplevel surfaces can't request window states
S466280: 18.082986 [src/mainloop.c:866] application has closed

I can see this all will be a fantastic thing, in the future, when it's completely ready.

[oiaohm]

No, that was with X. Synaptic won't work with sudo, it needs pkexec.

Depends you your distribution. Some distributions it will work with sudo. There are a few distributions where it would not work with pkexec but works with sudo. One of those fun things. Do note you were on X and when it could not connect to X11 server for any reason it goes and blames wayland. Reality if wayland you are seeing that message running Synaptic the problem is normally xhost not set to allow root with Xwayland. That is a security issue.

That was with wayland. But I guess that it was to be expected that it didn't work.

Wayland crossing users you are expecting issues.

Under X this works. And you need to do it like this (with a 2nd window with pkagent), otherwise you will not get the dialog for root privileges.

Some the horrible even it it still works does not mean it should.

I see that on my machine I have pkexec for local access as well, probably because it's a very old installation that has been upgraded many times. For local access I should probably remove pkexec from the starter.

If on you system is the newer version of partitionmanager using kauth and you are still using pkexec it can cause a random partition alteration failure as privilege assignments can go kind of wrong even under X11. So this is something that is just bad be you use it under X11 or Wayland. pkexec on partitionmanager under wayland will lead to failure unless you have xhost allowed root(so Xwayland accepts root user connection) and partitionmanager stubborn deciding to use xcb. This is a case you don't want partitionmanager to work with pkexec and if it working it could be nicely lining up to cause you harm.

~$ waypipe ssh ferry@kalamata partitionmanager
qt.qpa.xcb: could not connect to display
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: wayland-org.kde.kwin.qpa, eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.

Have you even tried this yourself?

Yes I have tried it myself. When I have used it over waypipe I am using the wayland platform backend in qt when I do that and it doing it automatically for me and its not for you for some reason. xcb is for X11 and that means you need to spin up Xwayland with waypipe and export a X11 display value point to Xwayland or it not going to work. waypipe at this stage does not have automatically start Xwayland. Basically for some reason partitionmanager choosing the wrong qt backend yet it telling you it has the backends for wayland.

waypipe ssh ferry@kalamata partitionmanager -platform wayland

The -platform bit there is to force wayland backend usage out of qt. Minor distribution and configuration differences can be a pain.

[ferry]

You are using Wayland environment, Synaptic will continue without administrative privileges.
To make Synaptic fully functional, please restart your session without Wayland.

No, that was with X. Synaptic won't work with sudo, it needs pkexec.

You are absolutely not meant to use pkexec with partitionmanager.

That was with wayland. But I guess that it was to be expected that it didn't work.

Under X this works. And you need to do it like this (with a 2nd window with pkagent), otherwise you will not get the dialog for root privileges.

I see that on my machine I have pkexec for local access as well, probably because it's a very old installation that has been upgraded many times. For local access I should probably remove pkexec from the starter.

xpra or waypipe can be used to make stuff like this to work because you have more complete support.

I wanted to show this:

~$ waypipe ssh ferry@kalamata partitionmanager
qt.qpa.xcb: could not connect to display
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: wayland-org.kde.kwin.qpa, eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.

Have you even tried this yourself?

[oiaohm]

No that is synaptic:
~$ sudo synaptic
X11 connection rejected because of wrong authentication.
Unable to init server: Kon niet verbinden: Verbinding is geweigerd
Kon GTK niet starten.

Waarschijnlijk draait u Synaptic in Wayland met rootrechten.
Herstart a.u.b. uw sessie zonder Wayland, of draai Synaptic zonder rootrechten

You are using Wayland environment, Synaptic will continue without administrative privileges.
To make Synaptic fully functional, please restart your session without Wayland.

That message is very miss leading. Why it has failed is synaptic has attempted to run as root and connect to a Wayland running as a normal user be that XWayland or Wayland normal this is forbidden by default. Waypipe provides way around this for application. Same as running session really as root that is of course classed as bad.

https://wiki.archlinux.org/index.php/Running_GUI_applications_as_root#Using_xhost

Xwayland default will refuse any X11 application not running as your user. But you can use
xhost si:localuser:root to tell Xwayland to accept connection from root user. So there is no need to restart session without Wayland to run Synaptic. Yes you have to downgrade your security of your desktop using xhost while forcing Synaptic to use X11 on wayland or use something like waypipe to transfer it output between users.

Basically the error you just showed is you not knowing what the heck you are doing same with those writing those messages. So this is not 100 percent your fault. You did presume that the message was truthful that its not.

Also sudo synaptic does not have to work its possible for your desktop X11 server to be configured not to accept other users applications connect to it. Sudo also does not work on all systems to be used that way. Some systems you have to use special programs so X11 display information gets passed though in normal X11 mode as well. Yes there are systems where you have to use pkexec to start synaptic under X11 instead of sudo because sudo will not give synaptic access to the users X11 server.

Waypipe and xhost both say that wayland desktops could have applications on the desktop that are not running as the desktops user. Yes in theory sudo/pkexec could be extend to take advantage of both. This would not require altering wayland protocol.

Remember if sudo or pkexec works for graphically X11 applications is because they setup environmental things so it could work. Its really simple for people who don't have long term experenice to presume sudo/pkexec always work with graphical X11 applications. sudo and pkexec can be no different to ssh to a remote system without -X if that is the case graphical applications running not as your user are dead be it wayland or X11. So sudo not working here is really sudo not extended so it can work. Distribution makers will not want to extend sudo so this cases straight up work either because it is a security risk and people taking a security risk really should know they are.

With partitionmanager:
in one window: pkttyagent --process 2576936
in the other:
~$ pkexec partitionmanager
qt.qpa.xcb: could not connect to display
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb..

You are absolutely not meant to use pkexec with partitionmanager.

https://stikonas.eu/wordpress/2018/03/24/kauth-support-in-kde-partition-manager/

kauth was implemented in KDE partition manager in 2018 This means its user interface is meant to run as a normal user and it uses kauth to run the need parts at higher privilege. This is going to go badly wrong in many ways.

https://doc.qt.io/qt-5/linux-requirements.html

I see no -no-opengl so the xcb module or qt has attempted to start up with opengl. As you said opengl over wire does not work. Opengl by pkexec also commonly does not work. So yes Qt applications presume you have working opengl unless told otherwise and if you don't have working opengl spits out a bog standard message that could be 1000 other things as well. Opengl is one of the most common fail here.

xpra or waypipe can be used to make stuff like this to work because you have more complete support.

Neither of these messages from either application are what you call 100 percent truthful or useful.

According to

*repology edited so I don't go over the URL count*

almost nobody has it. Not even a PPA. Normally that means: it's still experimental, almost no one is using this (however good it sounds and I may try it if I find a bit of time to build).

True limited people are aware of it at this time. But when you go around saying wayland protocol need to be extended you have to be aware of items like waypipe because that was a summer of code project linked to Weston the reference compositor of wayland.

There are sometimes more than 1 way to solve a problem. Its really easy to keep on pushing for the way you know and not look at the others and consider them.

[ferry]

There is no much you can do about problem exists between keyboard and chair. KDE partitionmanager is strictly designed that GUI parts be it X11 or not don't run as root. So asking it to run as root is you being PEBKAC.

No that is synaptic:
~$ sudo synaptic
X11 connection rejected because of wrong authentication.
Unable to init server: Kon niet verbinden: Verbinding is geweigerd
Kon GTK niet starten.

Waarschijnlijk draait u Synaptic in Wayland met rootrechten.
Herstart a.u.b. uw sessie zonder Wayland, of draai Synaptic zonder rootrechten

With partitionmanager:
in one window: pkttyagent --process 2576936
in the other:
~$ pkexec partitionmanager
qt.qpa.xcb: could not connect to display
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.

2) have waypipe installed both ends that can be a little hard as not all distributions have it so you may need to build it from source.

According to https://repology.org/project/waypipe/versions almost nobody has it. Not even a PPA. Normally that means: it's still experimental, almost no one is using this (however good it sounds and I may try it if I find a bit of time to build).

[oiaohm]

OK so lets say I want to start partitionmanager (KDE's version of gparted) on a remote server. Both are running KDE. I can do that now over X as ordinary user, but as root there is an error loading an xcb plugin (sadly for a KDE user, gparted works fine).

There is no much you can do about problem exists between keyboard and chair. KDE partitionmanager is strictly designed that GUI parts be it X11 or not don't run as root. So asking it to run as root is you being PEBKAC.

So, surprise me, how do I get partitionmanager to run across waypipe? Note, I now used sddm to login using plasma (wayland).

That simple
1) don't do PEBKAC so don't use root user remote as KDE partitionmanager is particular designed to refuse that this limitation is the same if you are X11 or Wayland..
2) have waypipe installed both ends that can be a little hard as not all distributions have it so you may need to build it from source.
3) follow the instructions to use waypipe https://gitlab.freedesktop.org/mstoeckl/waypipe/

waypipe ssh user@theserver partitionmanager

This will work but I would be recommend using the spin up on socket and forward socket route.

https://gitlab.freedesktop.org/mstoeckl/waypipe/-/issues/6#note_193622

As covered here to deal with connection drop out.

Using sddm and plasma wayland or any other wayland as the desktop makes absolutely no difference to these instructions.

To be correct you can get gparted working by exploiting waypipe. Waypipe connects by sockets so you can run it locally without a network connection.

Why gparted normally will not work with a normal wayland desktop of any kind is Xwayland only accepts connections from the user its running as. Of course using waypipe server you can spin up Xwayland as root and have gparted connect to that with the output going to a socket and then run the user part of waypipe as your normal user connect to that socket and show gparted running as root on a non root wayland desktop. Of course these kind of stunts work over network and locally.

The reality I would not be recommending partition alteration tools being run by general ssh -X forward because the results can be horrible bad. You want to use xpra or waypipe(in reconnect setup) for this stuff so that network connection can disappear mid partition alteration and the partition alteration process continues while you reconnect.

Basically this is not that you cannot run root applications on wayland desktops running as a normal user its that you need something like waypipe todo it and extra steps.

The extra steps keep root user applications memory more away from your general user applications memory.

[ferry]

Waypipe and xpra does kind of solve it. Something to be aware of all the wayland implementations use xwayland and xwayland combind with any of them doing network provide at least software level opengl support to X11 application and with amd/intel gpus accelerated. So this is not potentially one of the implementations may solve that the answer is in fact all of them with a network protocol solve it.

OK so lets say I want to start partitionmanager (KDE's version of gparted) on a remote server. Both are running KDE. I can do that now over X as ordinary user, but as root there is an error loading an xcb plugin (sadly for a KDE user, gparted works fine).

So, surprise me, how do I get partitionmanager to run across waypipe? Note, I now used sddm to login using plasma (wayland).