You are not logged in.
Q4OS Trinity is my first linux distro, and TDE is entirely dependent on X11. I like making apps, so naturally I develop tools using libx11, etc. (eg, Xakar) which are needed by those applications.
But everyone everywhere is always hating on x, and i understand that it's old and there is a better alternative, wayland, here. But it's heavier than x and many apps still depend on xorg..
Wayland feels less documented than X11, for example trying to make a global hotkey application on xserver was easy and it works. But searching for a wayland implementation.. all I get are GitHub issues. This makes me think— Is wayland as "customisable" as x? Is it possible to make tools to satisfy my absurdly specific issues or do I need to be limited to whatever these big distros are providing?
Also KDE seems to be doing the best with wayland as of now as it supports global menus and would discontinue X11 in following year.
I might move away from Trinity to Cinnamon in future, which has a larger userbase and more well maintained so I don't think learning xlib for just Trinity would be worth it..
So should I keep learning and developing with x, or is it a dead project I'd be wasting my time on?
coding & robotics enthusiast | Q4OS 6.4 TDE/XFCE + Win10 1903 on ASUS-E202SA (N3060 | 2GB RAM | 500GB HDD)
Offline
I actually prefer X11. But KDE has jumped to Wayland and it's probably the most popular DE. I think Wayland is the future no matter what the users actually want. I don't think X11 is dead, but it is on life support.
Calm down, it's only ones and zeroes
Offline
I do prefer X11 too.. maybe i should stick to what I have for now
coding & robotics enthusiast | Q4OS 6.4 TDE/XFCE + Win10 1903 on ASUS-E202SA (N3060 | 2GB RAM | 500GB HDD)
Offline
At least for now, that's probably the way to go. But, keep learning Wayland when you have the time.
Calm down, it's only ones and zeroes
Offline
X11 ofcourse. Wayland will replace it soon, no question there. But not yet.
Surely x11 hasnt been created with the modern hadrware in mind but they have quit improving it way before reaching its full potential. And not only that, they also didnt want anyone else to fork or let continue working on it. There is still uncertainty about what exactly happened,but atleast some people working on xlibre now. (Supported on main distros; debian,arch,gentoo,fedora,slackware,void,alpine already)
Worth to mention, there are also Phoenix (written from scratch in zig) and Wayback (X11 compatibility layer leveraging wlroots and Xwayland)
Last edited by onuracengiz (2025-12-28 18:52)
Offline
Phoenix is pretty interesting, but xlibre.. meh
coding & robotics enthusiast | Q4OS 6.4 TDE/XFCE + Win10 1903 on ASUS-E202SA (N3060 | 2GB RAM | 500GB HDD)
Offline
The simple fact is that X11 is going the same way as sysvinit and others of its ilk.
Wayland is going to be the equivalent of systemd - you're pretty well stuck with it and any X11 variants will at best be minor projects that are doomed to fail in the long term.
Offline
For your information, I’ve been using Xlibre on my main Q4OS Trinity installation for several days now, and I haven’t encountered any issues—maybe even slightly lower memory usage, if anything. I was curious (and perhaps a bit skeptical) to test this fork, which aims to implement pending X11 fixes and new Wayland features.
The result: just as stable, no problems at all. So, I’m very enthusiastic: regardless of what happens to X11, this fork already provides a host of fixes for X11 and is set to evolve further (the developers are clearly very active and motivated). I’ve even seen that some distros are considering using it to continue offering full X11 compatibility and support for future applications.
Debian & Q4OS (especially TDE), low-level C, ASM (z80/68k/x86/ARM64), embedded systems, CPU architectures (RISC-V, binary formats, assembly), retro-computing, metal, and sci-fi.
Offline
I at this point am fully on board Wayland. Not that I have anything against X11, but things just don't WORK on it anymore. None of my machines have SMOOTH operating touchpads on X11 without a lot of customization, whereas Wayland "just works". None of my 2-in-1's support auto rotation of the screen using the onboard accelerometer in X11 (or at least I've never gotten it to work), works in Wayland. None of the biometric devices work "out of the box" with X11, most of them do in Wayland.
I stayed on X11 for quite some time due to Wayland just having so many things that are broken, but at this point, it's the exact opposite. Wayland mostly works for all my hardware, while X11 simply doesn't anymore due to the development having stopped so long ago.
Last edited by tlmiller76 (2026-02-24 05:51)
Q4OS Trinity machine - Lenovo ThinkPad P14s Gen5 AMD. AMD Ryzen 7 Pro 8840HS, 16GB DDR5, 256GB m.2 NVMe SSD, Radeon RX780M iGP, Qualcomm QCNFA725 Wifi 6E + BT 5.2, 14" 2880x1800 400-nit OLED.
Offline
Wayland mostly works for all my hardware, while X11 simply doesn't anymore due to the development having stopped so long ago.
Understandable, but that's EXACTLY why xlibre exists and continue to progress. And I really don't want anything else than Trinity DE. For now, it's the DE that's exactly suits me, it's just perfect for my usage, a perfect balance between low ressources usage and modern features a desktop must have. But I completly understand your point.
Debian & Q4OS (especially TDE), low-level C, ASM (z80/68k/x86/ARM64), embedded systems, CPU architectures (RISC-V, binary formats, assembly), retro-computing, metal, and sci-fi.
Offline
tlmiller76 wrote:Wayland mostly works for all my hardware, while X11 simply doesn't anymore due to the development having stopped so long ago.
Understandable, but that's EXACTLY why xlibre exists and continue to progress. And I really don't want anything else than Trinity DE. For now, it's the DE that's exactly suits me, it's just perfect for my usage, a perfect balance between low ressources usage and modern features a desktop must have. But I completly understand your point.
Yeah, I still can't use Trinity on most of my machines despite liking it a lot (#2 after plasma 6). I use docking stations that require me to use mixed scaling. So I need 1.25 scaling on the internal LCD, but 1.0 scaling on the external monitor. That's simply not possible with any form of X, and most likely never will be according to some devs, so Trinity is, unfortunately, only something that gets put on a laptop after it's done in my "primary" rotation and is otherwise waiting for me to get rid of it.
Q4OS Trinity machine - Lenovo ThinkPad P14s Gen5 AMD. AMD Ryzen 7 Pro 8840HS, 16GB DDR5, 256GB m.2 NVMe SSD, Radeon RX780M iGP, Qualcomm QCNFA725 Wifi 6E + BT 5.2, 14" 2880x1800 400-nit OLED.
Offline
For your information, I’ve been using Xlibre on my main Q4OS Trinity installation for several days now, and I haven’t encountered any issues—maybe even slightly lower memory usage, if anything. I was curious (and perhaps a bit skeptical) to test this fork, which aims to implement pending X11 fixes and new Wayland features.
The result: just as stable, no problems at all. So, I’m very enthusiastic: regardless of what happens to X11, this fork already provides a host of fixes for X11 and is set to evolve further (the developers are clearly very active and motivated). I’ve even seen that some distros are considering using it to continue offering full X11 compatibility and support for future applications.
Interesting - I've tried this in a VM using https://github.com/xlibre-debian/debian and wound up with a login screen that would not log in - just kept cycling back. Seemed to be having problems Xlibre X connection to display :0 broken
Sort of gave up at that point.... ![]()
Offline
seb3773 wrote:For your information, I’ve been using Xlibre on my main Q4OS Trinity installation for several days now, and I haven’t encountered any issues—maybe even slightly lower memory usage, if anything. I was curious (and perhaps a bit skeptical) to test this fork, which aims to implement pending X11 fixes and new Wayland features.
The result: just as stable, no problems at all. So, I’m very enthusiastic: regardless of what happens to X11, this fork already provides a host of fixes for X11 and is set to evolve further (the developers are clearly very active and motivated). I’ve even seen that some distros are considering using it to continue offering full X11 compatibility and support for future applications.Interesting - I've tried this in a VM using https://github.com/xlibre-debian/debian and wound up with a login screen that would not log in - just kept cycling back. Seemed to be having problems Xlibre X connection to display :0 broken
Sort of gave up at that point....
Strange, I have installed it on my two machines, and even the one at work (one Aquarius, two andromeda version of Q4OS trinity) and didn't experienced this bug. Will look at it if I can reproduce in a VM ![]()
Last edited by seb3773 (2026-03-02 19:05)
Debian & Q4OS (especially TDE), low-level C, ASM (z80/68k/x86/ARM64), embedded systems, CPU architectures (RISC-V, binary formats, assembly), retro-computing, metal, and sci-fi.
Offline
Thanks @seb. It just occurred to me that it may be virtualbox-guest that is behind it.
Offline
So I need 1.25 scaling on the internal LCD, but 1.0 scaling on the external monitor. That's simply not possible with any form of X, and most likely never will be according to some devs
Well, I don’t agree with these devs. Taking a quick look at how Wayland handles different screen scales is actually pretty standard:
Each screen is rendered into a framebuffer at its logical resolution.
For example, a 4K screen: framebuffer at 1920×1080; a 1080p screen: framebuffer at 1080p.
The compositor (or equivalent) scales the framebuffer, not the windows.
→ Windows remain in native coordinates.
The compositor just does a final upscale per screen.
Nothing magical here... Wayland calls this "fractional scaling", Valve calls it "render scaling" on the Steam Deck, etc... It’s a classic, well-known technique—clean and efficient. Nothing to do with the hacks I saw using xrandr --scale (downscale → upscale → blur, so of course it always looks bad).
And the beauty of it is that, in theory, nothing stops us from implementing this in Trinity’s compositor. By sheer coincidence, I’ve been diving into the compton-tde code to make a few optimizations, and from what I know, it’s totally doable!
I’ll look into this as soon as I have a bit of free time
Stay tuned ^^
Debian & Q4OS (especially TDE), low-level C, ASM (z80/68k/x86/ARM64), embedded systems, CPU architectures (RISC-V, binary formats, assembly), retro-computing, metal, and sci-fi.
Offline
It was Virtualbox as I guessed.
Removed the virtualbox X11 package and it took dependencies with it. Installed Xlibre and all now good
Scratch that - works but very very slow and glitchy.
Last edited by bin (2026-03-03 15:16)
Offline
tlmiller76 wrote:So I need 1.25 scaling on the internal LCD, but 1.0 scaling on the external monitor. That's simply not possible with any form of X, and most likely never will be according to some devs
Well, I don’t agree with these devs. Taking a quick look at how Wayland handles different screen scales is actually pretty standard:
Each screen is rendered into a framebuffer at its logical resolution.
For example, a 4K screen: framebuffer at 1920×1080; a 1080p screen: framebuffer at 1080p.
The compositor (or equivalent) scales the framebuffer, not the windows.
→ Windows remain in native coordinates.
The compositor just does a final upscale per screen.Nothing magical here... Wayland calls this "fractional scaling", Valve calls it "render scaling" on the Steam Deck, etc... It’s a classic, well-known technique—clean and efficient. Nothing to do with the hacks I saw using xrandr --scale (downscale → upscale → blur, so of course it always looks bad).
And the beauty of it is that, in theory, nothing stops us from implementing this in Trinity’s compositor. By sheer coincidence, I’ve been diving into the compton-tde code to make a few optimizations, and from what I know, it’s totally doable!
I’ll look into this as soon as I have a bit of free timeStay tuned ^^
That would be cool if it were capable of getting it to work on xlibre. I'd love to still be able to actually USE trinity other than as an oddball when setting on the couch or at the kitchen table, etc. Be able to actually use it on my docking station like a proper laptop.
edit: Got my q4os install now running on xlibre so can test if/when it should work.
Last edited by tlmiller76 (2026-03-05 02:35)
Q4OS Trinity machine - Lenovo ThinkPad P14s Gen5 AMD. AMD Ryzen 7 Pro 8840HS, 16GB DDR5, 256GB m.2 NVMe SSD, Radeon RX780M iGP, Qualcomm QCNFA725 Wifi 6E + BT 5.2, 14" 2880x1800 400-nit OLED.
Offline
Yes, especially since Trinity is so much more than just a curiosity—in my opinion, at least (I love this DE, and in general, its integration with Q4OS tools. Q4OS Trinity is my distro of choice! :-)
The solution I’m proposing—by the way, work has already started! There’s a lot to do, but the compton-tde base is relatively solid, and I can confirm it’s totally doable. We just need to make it happen :-p)
About xlibre, I might have explained it poorly, or maybe I didn’t express myself clearly, but the solution I’m proposing isn’t dependent on it. It should work on any version of X11. The changes I’m suggesting are NOT at the X11 level (I don’t know the codebase well enough, and honestly, I don’t think that’s the right place or the right way to act. The entry point is the compositor, not X).
That said, I do use xlibre on all my Q4OS Trinity installations now, partly because it’s a version of X11 that includes a lot of long-overdue fixes and ongoing codebase cleanup. I’m not involved with the project, but I follow it with interest because it’s the future of X11 (and I have a deep aversion to Wayland). I think it’s the only “lifeline” for continuing to use X in the future (and so.. Trinity DE). But for the scaling issue we’re discussing here, X isn’t part of the equation—compton is ![]()
I’ll share updates as soon as I have something functional. I’m not quite there yet, and it’s getting late here ^^
Debian & Q4OS (especially TDE), low-level C, ASM (z80/68k/x86/ARM64), embedded systems, CPU architectures (RISC-V, binary formats, assembly), retro-computing, metal, and sci-fi.
Offline