Live data from Hacker News

Xfwl4 – The Roadmap for a Xfce Wayland Compositor

alexxcons.github.io

261–270 of 339 posts

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#261
post #150

Earlier quoted context omitted.

> ...or is that a class of performance we just have to sacrifice for the frame-perfect rendering of wayland? I think I know what "frame perfect" means, and I'm pretty sure that you've been able to get that for ages on X11... at least with AMD/ATi hardware. Enable (or have your distro enable) the TearFree option, and there you go. I read somewhere that TearFree is triple buffering, so -if true- it's my (perhaps mistak…

only on the primary display. once you had more than one display there were only workarounds.

I don't know what "workarounds" you're talking about, or what unwanted behavior that I presume you're talking about. Would you be more specific?

I ask because just a few minutes ago, I ran VRRTest [0] on my dual-monitor machine and saw no screen tearing on either monitor. Because VRR is disabled in multi-monitor setups, I saw juddering on both monitors when I commanded VRRTest render rates that weren't a multiple of the monitor's refresh rate, but no tearing at all.

My setup:

* Both monitors hooked up via DisplayPort

* Radeon 9070 (non-XT)

* Gentoo Linux, running almost all ~amd64 packages.

* x11-base/xorg-server-21.1.20

* x11-drivers/xf86-video-amdgpu-25.0.0-r1

* x11-drivers/xf86-video-ati-22.0.0

* sys-kernel/gentoo-sources-6.18.5

* KDE and Plasma packages are either version 6.22.0 or 6.5.5. I CBA to get a complete list, as there are so many relevant packages.

[0] https://github.com/Nixola/VRRTest>

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#262

Earlier quoted context omitted.

It is many years, I guess close to a decade, since I needed to change X config manually. I still find the odd rough edge in Wayland (the most recent was failing screenshots with KDE).

> It is many years, I guess close to a decade, since I needed to change X config manually. Making manual changes in 2015+, for a protocol released in 1987, that's a long time having rough edges..

Sorry, to clarify, I am not making making manual changes to Wayland config. I have stopped needing to make manual changes to X config.

Until recently i just switched back to X whenI had problems with Wayland. The last time the issues fixed itself on the next update.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#263
post #202
post #151

Earlier quoted context omitted.

You seen to know your Waylands. Do you know if global shortcuts are solved in a satisfactory way, and if there easy mechanism for one application to query wayland about other applications. One hack I've made a while ago was to bind win+t command to a script that queried the active window in the current workspace, and based on a decision opened up a terminal at the right filesystem location, with a preferred terminal…

Currently, the Wayland protocol itself doesn't have a standard solution to global shortcuts. Instead, it's being pushed to the XDG Desktop Portal API, under the org.freedesktop.portal.GlobalShortcuts service: https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr... This should work with Hyprland provided that you are using xdg-desktop-portal-hyprland, as it does indeed have an implementation of GlobalShortcuts…

Thanks for the insight, I really appreciate it. I don't use hyperland (just what came up as brief research). Xfce generally has simple and legible code, hopefully this wayland compositor will be just as hackable and tweakable for my needs.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#264
post #235

Earlier quoted context omitted.

Hmm? Seems to be getting plenty of development. https://github.com/X11Libre/xserver/activity

the kind that introduces regressions? there is a reason lead developer of X11Libre left Xorg project, they did not like broken code: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1760 (and many more if you search)

[deleted]

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#265

>The goal is, that xfwl4 will offer the same functionality and behavior as xfwm4 does... I wonder how strictly they interpret behavior here given the architectural divergence? As an example, focus-stealing prevention. In xfwm4 (and x11 generally), this requires complex heuristics and timestamp checks because x11 clients are powerful and can aggressively grab focus. In wayland, the compositor is the sole arbiter of fo…

I ran xfwm's compositor back when it was first introduced on a 400 MHz Pentium II with a GeForce 2. It was fully fine.

The compositing tax is just waiting for vsync; unless your machine is, like, a Pentium Classic, compositing itself isn't a problem.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#266

In my view, this project itself shows some of the reasons why Wayland is the right path forward. On X, we had Xorg and that is it. But at least Xorg did a lot of the work for you. On Wayland, you in theory have to do a lot more of the work yourself when you build a compositor. But what we are seeing is libraries emerge that do this for you (wlroots, Smithay, Louvre, aquamarine, SWC, etc). So we have this one man proj…

This is the same logic that led to rails being shoehorned into every company in 2006-2010, which spawned a whole ecosystem of people who specialized in rewriting Rails projects back to Java/C#.

Yes, the stack gets you most of the way there. No, you won't be happy if you need to actually make changes to any part of that other than the top layer.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#267
post #175

Earlier quoted context omitted.

systemd comes close, and can be viewed as an attempt to create such a stick...

Sorry, but systemd has absolutely nothing, or even less than nothing to do with user-space GUI desktop applications.

Ah, if only! GNOME and even to an extent KDE both depend on systemd components, to the point that systemd-free distros are compelled to fork it if they want a GUI: https://wiki.gentoo.org/wiki/Elogind

Only yesterday I was wondering how it is that my brightness keys work in my desktop environment, when /sys/class/backlight/intel_backlight/brightness is only writeable by root. The (somewhat horrifying) answer is that applications can send a request to logind over DBUS, which checks the request against opaque and arbitrarily byzantine Polkit rules, and then writes to the sysfs file on the application's behalf, which it can do because it runs as root. It's unclear quite what this achieves that simply making the file writeable by the "video" group does not, but hey at least systemd gets to be involved.

Incidentally, the correct command to change the brightness as a normal user from the command line is as follows:

  busctl  --timeout=1 call org.freedesktop.login1 /org/freedesktop/login1/session/self org.freedesktop.login1.Session SetBrightness ssu "backlight" "intel_backlight" 
So simple, so easy to remember, so superior to "echo > /sys/class/backlight/intel_backlight/brightness". Google it for a fun thread on why the --timeout=1 is neccessary (it won't work without it!) - although I suppose I should be thankful for that little foible, as without it the thread wouldn't exist and I would never have figured out the command in the first place.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#268

Earlier quoted context omitted.

If the XLibre project appears to be making enough fairly-consistent progress for you to be comfortable tossing around some cash, then do gather up some likeminded folks to hire a dev to follow the guidance here [0] and help out! Do note that I've never tried to croudfund a programmer, but that's something that I have to believe is possible to do. [0] https://github.com/X11Libre/xserver?tab=readme-ov-file#i-wan... >

Given that all their patches were reverted in upstream X11 due to quality issues [0], I wouldn't put too much trust into that project. [0] https://www.phoronix.com/news/X.Org-Server-Lots-Of-Reverts

Given that FDO [0] has been screaming about how Xorg is dead and Wayland is (despite plenty of evidence to the contrary) ready for everyone and every use case for the past like ten+ years, I remain somewhat wary about their opinions regarding Xorg development.

Maybe XLibre will be a damn trainwreck, or maybe it'll be to xorg what xorg was to XFree86. I intend to find out through the testimony of users of XLibre.

[0] ...or maybe just a very vocal subset of the folks at FDO...

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#269

Earlier quoted context omitted.

> It's a downgrade that we have no choice but to accept in order to continue using our machines. Odd. Xorg still works fine [0], and we'll see how XLibre pans out. [0] I'm using it right now , and it's still getting updates.

They're trying to "nudge" everyone. Major desktop environments and entire distributions are removing X11 support to varying degrees. A lot of this is because they can't get their adoption rates above about half due to various broken workflows or simply user preference. They intentionally don't want you to keep using X11, and they'll keep turning up the heat on the pot until we're all boiling. Gnome just removed the m…

> They're trying to "nudge" everyone.

Once again, Gentoo Linux proves (somewhat regrettably) to be one of the best Linux distros out there. OpenRC and Xorg as defaults, with SystemD and Wayland as supported options is quite a lovely way to do things.

> Gnome just removed the middle-click paste option.

Gnome removes useful things all the time. "The Gnome folks do something user-hostile just because they feel like it" isn't news; that's been going on for decades. This habit of theirs is a big reason why I've been using KDE for a very long time.

Re: Xfwl4 – The Roadmap for a Xfce Wayland Compositor

#270

Earlier quoted context omitted.

If you're just trying to run Linux you're better off either using one of the many read-made distributions or going with X11 since that works just about everywhere and has done so for decades.

THanks for the encouragement. I'm trying to get Debian Linux to run on a Chromebook and it's been no shortage of frustration, especially because ChromeOS is Linux and ostensibly open source, but just getting the kernel booted was an ordeal and a half. I'm currently stuck at suspend not working because something something EC, for which ChromeOS has a userland program to coax it into working right.

ChromeOS and devices it was made for are not the best start in Linux-land since it is Linux just like Android is, i.e. it is based on a Linux kernel but for the rest quite different from 'standard' (GNU-) Linux distributions like Debian + derivatives, Arch, Fedora etc. Maybe you can get that userland tool from ChromeOS to work in Debian, maybe not.

Even though you're trying to get Debian installed on the thing I'd also refer to the Arch wiki for information on how to get things working right:

https://wiki.archlinux.org/title/Chrome_OS_devices

Arch being what it is it has attracted a host of knowledgeable users who have collected their information about how to get things working on different systems in an organised and usually comprehensive way on that wiki. Much if not most of what is written there is also applicable to getting non-Arch distributions running on those systems.

Post reply on HN