What is missing in XLibre in comparison to Wayland?

[fredvs]

What features are currently missing from XLibre that would be welcome?

What does Wayland have that's actually better and could be adapted for XLibre?

Ok, I begin:

I would be happy if XLibre has:

• Native High-DPI and Fractional Scaling Support (maybe with extending the Xnamespace extension)..
• Frame-Perfect Rendering and Tearing Prevention (perhaps by modernizing the Xnest nested server).
• Adaptive Sync and Variable Refresh Rate (VRR) Support (maybe with leveraging Mesa’s state trackers).
• Modern Input Handling for Touch and Gestures (perhaps by enhancing the existing XInput protocol).
• Improved Remote Desktop Capabilities (maybe possibly extending the Xnamespace extension)
• Some minor others features but this is for later.

[SuperDuperDeou]

• Native High-DPI and Fractional Scaling Support (maybe with extending the Xnamespace extension)..

The X server already knows the exact size of the screen, both in pixels and in physical size, that should make manual display scaling simply obsolete. If it doesn't work, it's because of poor support from toolkit devs.

• Frame-Perfect Rendering and Tearing Prevention (perhaps by modernizing the Xnest nested server).

This is already a feature (TearFree, Force Full Composition Pipeline), it's a problem of bad defaults (fixed) and insufficient configuration utilities from DEs (out of scope)

• Adaptive Sync and Variable Refresh Rate (VRR) Support (maybe with leveraging Mesa’s state trackers).

Already a feature, see above.

• Improved Remote Desktop Capabilities (maybe possibly extending the Xnamespace extension)

X11 is network transparent, you can't get more remote desktop capable than that.

There are Wayland features that X11 is missing, some that should probably be added:

• HDR support
• I think I'm out of features

And some that are more questionable:

• Lock Screen: locking a session really sounds like it should fall under the competence of the session manager
• Security: the "every program is a sandbox" approach Wayland has is just a usability nightmare, there's probably happy medium between that and "every program is a keylogger". Still, all that focus on display server security makes sense on Windows, which wants to enforce DRM, and programs are installed by downloading them from a warez site that offers a crack, which may or may not actually be malware, but I'm not sure it makes as much sense in the FOSS world, where we consider DRM evil and programs are installed by vetted and signed packages that come from the distro maintainers. Still Xnamepsace is a thing added in XLibre that should improve security without having to sandbox everything.

[dec05eba]

That XLibre part (it can be session manager - but doesn't look right for me), because if screensaver dies - screen is unlocked (some random bug linuxmint/cinnamon-screensaver#354).

The x11 protocol has a security option to protect against this. Screen savers just need to use the option. It's a relatively new option. The option will make the X server crash if the screen saver crashes (which brings the user back to the session manager login or tty login).

[xgui4]

• Security: the "every program is a sandbox" approach Wayland has is just a usability nightmare, there's probably happy medium between that and "every program is a keylogger". Still, all that focus on display server security makes sense on Windows, which wants to enforce DRM, and programs are installed by downloading them from a warez site that offers a crack, which may or may not actually be malware, but I'm not sure it makes as much sense in the FOSS world, where we consider DRM evil and programs are installed by vetted and signed packages that come from the distro maintainers. Still Xnamepsace is a thing added in XLibre that should improve security without having to sandbox everything.

that the only part i 100% agree.

[smj-cc]

I have it in a lock script that kills any sensitive processes before running it, that should probably work for logging out any non X11 stuff?

When I want X to lock, it's usually either due to inactivity (the rare case), or due to specific invocation (Ctrl-Alt-L the usual case). In either case, what I actually want is to lock all local access, including other virtual consoles (which I still regularly use).

xsecurelock is actually fairly complex, at least compared to vlock, and more difficult to evaluate the security of, and it leaves other consoles unlocked.... and it's google...

I think I'm going to stick with vlock, but thanx for pointing it out! I needed to evaluate it.

[mahiro21h]

just saw this discussion today. i've been working on an extension to the xserver to fix issues with screen locking for a while. it's not perfect or in a state where it could be merged into upstream yet but it's usable. i'd appreciate any feedback. im mostly active in the official telegram group in case you want to talk.

[callmetango]

@mahiro21h Would you mind to create a new discussion at X11Libre 1 New Ideas · Discussions · GitHub? That way your extension would get more attention by developers which tend to hang around at Github more than on Telegram. 😉

[dec05eba]

X11 protocol, xlibre and xf86-input-libinput already supports gestures and has for at least 5 years. It's an issue in kde/gnome that doesn't use it.

[xgui4]

but the current one does not work at least Out Of The Box on most WM and DE so it suck on my laptop. Touchpad gesture is a must for me ...

[dec05eba]

but the current one does not work at least Out Of The Box on most WM and DE so it suck on my laptop. Touchpad gesture is a must for me ...

I have told you 500 times already. This is not an issue with xlibre itself. There is nothing xlibre can do about it.

[xgui4]

well but the problem is that KDE and GNOME are the mainstream DE and they are pro-wayland and x11 hater , they wont add wayland like feature to x11, so what your idea ?

[callmetango]

Thank you for your contribution! We currently restructured the "Ideas" discussions and accordingly this discussion will be moved to the Good Ideas For Later category.

[mSparks43]

X11/Xlibre also already has better HDR support than wayland with applications such as pyschHDR actually using it.

I like the xnamespace extension idea for improving it, rather than isolate applications from each other it could put appllications into 24bit/30bit output bins so applications that expect 24bit sRGB still work normally on a 30bit desktop.

[callmetango]

Interesting, though I don't completly understand the details since I'm not that deeply involved in X development. But I know HDR is a hot topic that we should address for the sake of feature parity.

[xgui4]

a 30bit desktop.

do you mean 32 bit? i have never heard of a 30 bit CPU...

[xgui4]

but is that support already on Desktop Environnement ? Most Windows coming to Linux would like to have a full DE with everything out of the box.

[mSparks43]

a 30bit desktop.

do you mean 32 bit? i have never heard of a 30 bit CPU...

hdr10 is 10 bits per channel, 3 channels

example code for using it here
https://github.com/Psychtoolbox-3/Psychtoolbox-3/blob/fc7a068889aeb091a2ebb8dcce20025ab3422da9/Psychtoolbox/PsychGLImageProcessing/PsychImaging.m#L1549

search that .m file for wayland for extra comedy.

[xgui4]

I think re-adding XWayland support can be great for having a better experience of X11 app on a Wayland compositor. Xorg xWayland scaling suck, so a better XWayland can be a really great addition !

[callmetango]

Xwayland is maintained by X.org and is outside the scope of the XLibre project. If the scaling is subpar, please file a bug at Issues · xorg / xserver · GitLab.

[dmantione]

If you ask me, as a Linux user since 1997, the greatest thing about X11 is its network transparancy. And this is possibly also the biggest current issue with X11, maybe even the elephant in the room. Ever since the switch of the century, the Linux community seems to have the opinion that X11 network transparency is riduculous idea and has done everything to undermine it.

Wayland considers the X11 network transparancy to be a stupid idea. Yet still, one of the greatest things about Linux is the ability to ssh into a remote server and run graphical applications in a transparent way.

However, X11 network transparency nowadays sucks. If you happen to run an old X application with Motif or Openlook user interface remotely, it works superb on modern X. It's fast and responsive. However, try to run LibreOffice from a remote... even on the same LAN, it is barely usable.

Applications written with modern UI toolkits such as QT or GTK, start slow, and can be very unresponsive if not on a very fast connection.

The Linux community has invented all kind of workarounds. For example with NoMachine or X2GO, you can efficiently run a desktop on a server far away on a relatively slow internet connection. VirtualGL, to get OpenGL graphics accelerated by a remote graphics card, can use the X protocol, but is slow as hell. VirtualGL has its own network protocol, if you use that, VirtualGL can be used efficiently from remote.

In my opinion, if the goal of this project is to make X great again, it will need an answer to this problem. I know attacking it is quite difficult, as it is not a change that can be made into the X server only. It may even need a thorough rethink of the X protocol. However, if this issue is not addressed, then the Wayland people were right to make Wayland not network transparant and the remaining people who use X will always have to deal with ugly workarounds, or can't use its killer feature effectively at all.