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.

[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. 😉

[cliquesoft]

I would rather not have any screen locking in place in Xlibre. As @SuperDuperDeou pointed out, this is much more a role of the session manager (or other methods for the designer of the GUI or OS).

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

[chankongus]

10bit just means your monitor can show smoother color gradients, 1.1 billion vs 16 million shades. HDR is about brightness and contrast: brighter highlights, deeper blacks, and a wider range overall. You can have 10bit without HDR, but true HDR always needs at least 10bit color to look right. X11 supported 10bits since forever, it's just that X11 apps/mesa drivers on X11 didn't, when you switch that setting all hell will break loose because apps expect the default colorspace to be always 8bit.

[fredvs]

X11 supported 10bits since forever, it's just that X11 apps/mesa drivers on X11 didn't,

Hum, question from a xlib.so user here. What should be done by the app to support it (if, by chance, mesa drivers finally support it)?

[reaperx7]

Just code for allowing 10bpp coloring more or less.

30bpp color rendering was always reserved for workstation applications like AutoCAD and such. Lots of apps will work with it, outside of gaming which tends to have more problems than anything.

You can enable it easily enough (example for amdgpu):

/etc/X11/xorg.conf.d/20-amdgpu.conf
Section "Screen"
Identifier "asdf"
DefaultDepth 30
EndSection

Courtesy the amdgpu wiki page of ArchLinux. Then problem is application support of 10bpp color.

[fredvs]

Ok, thanks, I will try to find what xlib.so/xcb.so method assign it (if you have a idea, it is welcome).

[oiaohm]

search that .m file for wayland for extra comedy.

https://github.com/Psychtoolbox-3/Psychtoolbox-3/blob/fc7a068889aeb091a2ebb8dcce20025ab3422da9/Psychtoolbox/PsychGLImageProcessing/PsychImaging.m#L1549

Lets follow mSparks instructions and see if it comedy.

% Also note that using this PsychImaging tasks will make your script non-portable to other
% operating systems than Linux or other display systems than X11 (e.g., Wayland) for the time
% being. Another limitation is that this only works with 10 bpc HDR-10 precision framebuffers,
% not with the higher precision 16 bit floating point framebuffers offered by standard HDR
% mode. This hack will be limited permanently to HDR-10 with static HDR metadata and 10 bit
% precision. It will eventually be superseded by a proper multi-display/stereo HDR implementation,
% if and when we get funding to work on this.

The file mSparks referenced is very clear Psychtoolbox HDR support is a hack that is planned to be removed.

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

This is not the case. Wayland HDR supports application output 16 bit floating point as offered by Psychtoolbox direct to output HDR option. Also there is a problem

For Psychtoolbox HDR to be able to fully function under X11 the Nvidia deep color work from 2017 would have to be worked out and done in way that does not crash other applications. Xnamespace might be a tool todo this.

https://github.com/Psychtoolbox-3/Psychtoolbox-3/blob/fc7a068889aeb091a2ebb8dcce20025ab3422da9/Psychtoolbox/PsychGLImageProcessing/PsychHDR.m

% - Modern AMD (RX 500 "Polaris" and later recommended) and NVidia (GeForce 1000
% "Pascal" and later recommended) graphics cards under a Microsoft Windows-10
% operating system, which is up to date for the year 2021.
%
% - Modern AMD graphics cards (like above) under modern GNU/Linux (Ubuntu 18.04.4-LTS
% at a minimum (untested!), or better Ubuntu 20.04-LTS and later recommended), with
% the AMD open-source Vulkan driver "amdvlk". Install driver release 2020-Q3.5 from
% September 2020, which was tested, or any later versions. Note that release
% 2023-Q3.3 from September 2023 was the last release to support pre-Navi gpu's like
% Polaris and Vega. Later versions only support AMD Navi and later with RDNA graphics
% architecture.

Yes there is a interesting problem here. Pshychtoolbox with full 16 bit floating point being direct to screen under Linux use to fail on Nvidia GPUs. Since mSparks is only a Nvidia user this equals this fool not being fully aware that the X11 hack in Pshychtoolbox gives second rate output particular in cases where you are overlaying things due to the limited alpha channel of the x11 configuration with HDR.

Yes Pshychtoolbox at the moment is annoying rock and hard place. Have multi monitor support by X11 but have limited HDR support so you cannot overlay outputs with fine alpha control or use direct to monitor and be locked to a single monitor

Come on people before upvoting stuff do some basic research. The reality like it or not X11 current protocol HDR support is garbage.

Wayland HDR support was only merged this year into the protocol.
https://www.phoronix.com/news/Wayland-CM-HDR-Merged

There is a lag between a feature added to protocol and applications like Pshychtoolbox catching up to it. Yes what was merged into wayland greatly exceeds what X11 depth color offers. To keep up with what in the Wayland protocol Nvidia 2017 deep color work need to be resolved.

X11 protocol when it comes to HDR vs Wayland like it or not has fallen behind.

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

[cliquesoft]

I'm not quite sure how the interface is being transmitted over the LAN/WAN/Internet, but could this be addressed as easily as just reducing the transmitted frame count (or screenshots or whatever is being sent)? I think some remote softwares handle it this way (anydesk, teamviewer, etc), but not 100% sure. Or possibly reducing the resolution?

[ArmanHayots]

They usually using common video stream compression techniques like interframe difference, area filling, MPEG-like encoding with variable bitrate etc.
In the base the X protocol operating on UI entities (like Win32 handles or NS- and B-objects in MacOS and Haiku respectively), so server just tells client to draw button – and client doing it according by client-side toolkit (if I understand that moment correct). But now most GUI toolkits/environments using X simply for pushing ready bitmaps and that's turning all the base idea into a bloated mess.

[kohnish]

It would be nice if they're mentioned if there are something X isn't capable of but wayland can.
Gestures, zero tearing, fractional scaling and etc seem to work for me, and many things like input method, clipboard, remote desktop work better than wayland.

So far, I haven't found any missing features and I'm only curious from technical perspective.

[xgui4]

Gesture is still way superior and native on wayland while x11 use patches for touchpad gesture. zero tearing require picom so it is not native. clipboard work better on x11 actually for me. and remote desktop suck compared to x11 forwarding

[kohnish]

Maybe gesture can be improved, if you describe what's actually missing. It might need a support from clients as well though, for which also you can make a request in their project.

[xgui4]

on most Wayland Compositor that i have try on bare metal (KDE so KWin , GNOME so Mutter and Hyprland) multitouch touchpad work perfectly like on Windows 10 + and MacOS , on X11 you are like stuck in the past with Windows 8 and before touchpad ... you can make the touchpad work on X11 but you must do do manually (I somehow succeed on my Intel laptop, but I don't know how lol) and still won't look as smooth abd native as Wayland.

[kohnish]

That's not specific enough for devs to look into the issue actually. Xgui4 Studio ***@***.***> writes:

…

on most Wayland Compositor that i have try on bare metal (KDE so KWin , GNOME so Mutter and Hyprland) multitouch touchpad work perfectly like on Windows 10 + and MacOS , on X11 you are like stuck in the past with Windows 8 and before touchpad ... you can make the touchpad work on X11 but you must do do manually (I somehow succeed on my Intel laptop, but I don't know how lol) and still won't look as smooth abd native as Wayland. -- Reply to this email directly or view it on GitHub: #64 (reply in thread) You are receiving this because you commented. Message ID: ***@***.***>

[kohnish]

I guess what's missing is Wayland emulation layer. Pure Wayland apps won't work, while in Wayland, x apps work to some extent. I think this is a big feature gap that should be addressed.

[xgui4]

I guess what's missing is Wayland emulation layer. Pure Wayland apps won't work, while in Wayland, x apps work to some extent. I think this is a big feature gap that should be addressed.

It is to be expected that wayland app won't work under x11 .. that normal ... it is like said why do macos app won't run under linux

[kohnish]

it runs over emulation/virtualisation. but it is a fact that wayland app isn't supported on Xlibre, and it's a feature parity that is discussed here. it'll be an issue.

[fredvs]

@kohnish : Did you check this https://github.com/orgs/X11Libre/discussions/74 ?