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

[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 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]

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]

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.

[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]

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.