I came to prefer twm after I first tried Slackware from watching a video by a Slackware user playing it up. Now I'm hooked and have a slight fork as I very gradually try to learn enough to change it internally.

The obvious wayland desktop environments look a bit cartoonish after acclimating to twm and stumpwm, so I've had the thought of learning how to write a native wayland "window manager" (compositor?) that works like my fork of twm. I also thought it would be fun to try it in common lisp, but that's more of a fantasy than anything else. If I get started now perhaps it will be usable in 10 years. There does appear to be a Common Lisp binding at least, at some state of completion: https://github.com/sdilts/cl-wayland

Have people tried twm on XWayland? I gather XWayland can be run in a new "root-full" mode where it can supposedly run an X window manager. Does it behave normally with XWayland underneath? I'd be surprised. Even firefox now does weird things with popups if it doesn't recognize your window manager by name, but perhaps X and Wayland developers are more grounded.

1 members found this post helpful.

wpeckham. zeebra, re TinyX, I've been working with that a bit for inxi for this coming release, so I have brushed up.

If you are serious about looking into these, first, just grab one of the tiny isos, tinycore basic for Xvesa, and TinyCore Pure64 for Xfbdev. I think tinycore has the code on their code repo, maybe slitaz too. Alpine may use these, not sure. I think they are not though. DSL (damned small linux) was the one that sort of brought TinyX back from the dead, though the initial version was rolled back to 1.2 due to some issues, which appear to be resolved since now at least TinyCore is at 1.3. But talk to those guys if you want to look into it.

First, TinyCore and Slitaz use TinyX. Both of these are very cool, but different, remarkably so given their tiny sizes. The reason it's tiny is because it's an absolutely stripped down barebones X server, with the driver as part of the server, thus, Xvesa (32 bit only), Xfbdev (64 bit) are TinyX servers, then a bunch of legacy servers only people with really old hardware will own. quoting from the docs I just made for TinyX:
https://codeberg.org/smxi/pinxi/src/...i-graphics.txt (Section Display Server Data > TinyX

Known to exist or have existed:

Xchips
Xfbdev [verified tc, active 2023]
Xi810
Xigs
Xipaq
Xmach64
Xmga
Xmodesetting [only tentatively proposed by TinyCore, not existing]
Xneomagic
Xsavage
Xsis530
Xtrident
Xtrio
Xts300
Xvesa [verified tc, active 2023]

I also package inxi for TinyCore so I'm used to TinyX. Short version: most people won't like it because it's tiny. Amazing, incredible, fantastically weird, but tiny. Currently I believe only Xvesa and Xfbdev are alive, at version 1.3, which is the same version they were forked at, so I don't know how much work has been done on them beyond making the code compile and run.

=====================================

jayjwa, zeebra

Re the general question of X.org vs Wayland, first, just to correct a few things, Wayland is like x11, it's a protocol, not a display server. kwin_wayland, wlroots, sway, etc, are like X.org. You don't write a how to for wayland, you write a how to for the compositor, which is a royal pain since there are a lot, but sway basically saved the free software ecosystem by creating what is basically the reference compositor library for anything that is not kwin_wayland, gnome-shell, enlightenment... and one of a hundred experimental ones. this is the list inxi uses currently, with some new updates coming in 3.3.32, which is going to be a massive release:

asc awc bismuth
cage cagebreak cardboard chameleonwm clayland comfc
dwl dwc epd-wm fireplace feathers fenestra glass gamescope greenfield grefson
hikari hopalong [Hh]yprland inaban japokwm kiwmi labwc laikawm lipstick liri
mahogany marina maze maynard motorcar newm nucleus
orbital orbment perceptia phoc polonium pywm qtile river rootston rustland
simulavr skylight smithay sommelier sway swayfx swc swvkc
tabby taiwins tinybox tinywl trinkster velox vimway vivarium
wavy waybox way-?cooler wayfire wayhouse waymonad westeros westford
weston wio\+? wxr[cd] xuake

A subset of these compositors support x11 and wayland protocols, but I suspect the smaller ones are dumping the x11 and just doing wayland.

I have followed this for many years because I have had to struggle with the remarkably poor state of wayland docs, the total absence of reliable wayland protocol debuggers that you can rely on always being there like X.org tools are, but you have to remember, while the wayland people created their reference compositior Weston, which nobody uses to speak of, the x11 group reference display server was X.org, which became the defactor standard so most people don't even realize X.org is an x11 display server that just happened to also be written by the same group. Sadly that same result did not happen with weston, which does have decent debugging tools, as do sway/wlroots in some cases. I know of no debugging tools for wayland for kwin_wayland or gnome-shell, but I gave up looking because I could find nothing.

I use xfce, who are very slowly working on wayland in 4.19, but they are following the proper slackware style development model, which is to not jump in until it's actually ready for prime time. To paraphrase your BDFL Patrick V., what distros are doing this coming release, like Fedora, is essentially releasing sucker display servers, and I for one am very happy to let their users find all the bugs.

Recent postings have indicated also some real issues in wayland, but Damentz, who does the Liquorix kernel, said he's switched to KDE wayland and that over the past year, there's been a huge jump in quality and reliability, so experiences may improve.

If I were to do bare metal testing, I'd pop sway on an old Thinkpad, try to keep Xwayland off of it to force myself to use only wayland programs because it's guaranteed that there will be bugs when a display compositor talks to an xwayland adapter layer.

I don't think however that with what is certain to be a very rapid pace of development now for wayland compositors (and remember, there is no such thing as a wayland display server, it's just the protocol, which means you can't talk about a single compositor the way we can with X.org, even though there can in theory be other x11 display servers, but there really aren't).

=====================================

Re forking etc, easier said than done, personally, wayland solves no issues I have, but wayland does solve some issues some people have, just not me. So I have zero incentive to switch until the xfce guys feel it's working well and it can be reliable, I trust them like you guys trust patrick to not do something stupid. Virtually seamless transition to gtk 3 for example, I barely noticed.

Just thought I'd share my perspective and experience, the best thing to do is to run it and test, though like many here, I expect to be one of the last to switch, at least I hope to be.

But if anyone is serious about it, you should get with for example OpenBSD Xenocara/X.org, Theo is not thrilled at all with wayland, doesn't like the eway it forces a single linux model of a unitary stack, he was just talking about this, though wayland is available as a port.

But the logical thing to do based on the complexity is to talk to all other projects who don't want to use wayland, this can work, Trinity desktop, much to my surprise, and Mate, both survived and exist today because they were not fans of new kde or gnome. But fragmented attempts, no way.

Also interesting is if real interest were to show up for the TinyX servers, but they are not X.org replacements, they are tiny, and do not do what X.org does, though they do run a desktop and window managers fine. But if you are curious, just talk to the Slitaz/TinyCore guys.

==============================

Re the basics, the primary X.org maintainer has said in public he no longer works on X.org, he only works on Xwayland, which you can see here:

A few years back xwayland was at 21, same as x.org, now it's several major versions ahead. So it's not really relevant what anyone feels or thinks, including me, the fact is that X.org is not being developed anymore actively, so unless a group of people get together to basically start working on it (keeping in mind Keith Packard of Intel agrees that wayland protocol compositors should be the future, and he was the x11 guy if I remember right) the current stagnant state will continue.

Once no active development happens on such a large codebase, bit rot has to set in, driver issues, conflicts, things don't get fixed, until the system starts getting visibly glitchy. I am not certain, but I have been seeing visual glitches on some applications now already, mostly gtk based, and apparently KDE's wayland compositor is significantly better than GNOME's, which is no suprise. Sway is nice, if you like i3, you can use the same config file basically. There's a few OpenBox type compositors too if floating windows are your thing. That's the easy way, just make sure it's based on wlroots or kde/gnome/enlightenment, otherwise you are just testing someone's hobby project for them, imo anyway.

6 members found this post helpful.

Oh, I almost forgot, Puppy too uses TinyX.

TinyCore TinyX repo: https://github.com/tinycorelinux/tinyx

But you'll note there's no code activity there for 2 or so years.

The README did hint towards maybe a future Xmodesetting TinyX server, which would be interesting since that would bring in a fairly new display driver that is modern. But that requires people to code the stuff, which is not certain.

Another clear example where if there is actual interest, all these projects should get together and create one active branch and work on it together.

This is definitely in the "If people get together and share efforts, this could happen, but if they don't, it won't" category of code projects I think.

2 members found this post helpful.

the last time I fiddled with kwin-wayland I ran into a lot of:

• Bugs that were present only on wayland
• bugs that were fixed on wayland (but still present on X)
• Bugs and UI issues that occurred on both because changing a protocol doesn't magically fix every problem.

All the wayland compositors I've looked at give me eye strain. When you render the desktop as if it is a video game then you end up with sporadic changes in framerate that cause issues for long sessions at the computer.

Back in October I saw a fun tidbit from the changelog for CS2 regarding wayland vs X11:
Food for thought. I know not everyone here is big on video games, but game engines are some of the most hardware intensive applications you can run and are very sensitive to performance issues. If wayland was on-par with X11 then Valve wouldn't be dropping back to the old protocol.

I find it amusing that a company that wants to make money from the same demographic wayland was developed for is preferring X. I can't imagine what kind of random and crazy chaos we will see when projects like QT and GTK drop X11.

4 members found this post helpful.

i tried Wayland with Mutter in 2018, I am still in therapy.
https://i.ibb.co/TR5QcM1/Wayland.jpg

4 members found this post helpful.

Reading a thread like this validates my existing policy of staying on Xorg until I'm pushed. Saying "It's the coming thing" doesn't impress me.

4 members found this post helpful.

I have to say that I am using gnome 44 on wayland and have not had any troubles at all up to now, but I have to say that my use is purely as a normal laptop computer for office use.

1 members found this post helpful.

I mean, there was a similar backlash when XFree86 was dropped for XOrg. Nothing's stopping anyone from writing something that isn't wayland or forking X. XOrg was rough for a bit, too. I think we'll have X11 while wayland gets the bugs straightened out. We're just in a weird situation where development is split, and things are sliding over towards the thing that needs more work, since X11 is pretty mature at this point.

I'm kind of excited about the alleged lower latency of wayland, but latency is my bane for about 99% of what I do on a computer.

https://www.youtube.com/watch?v=QWV4pFV5nX4

2 members found this post helpful.

As for networking in wayland I thikn also it will be solved in some way to be at par with X. I have no doubt about that. As garpu said, it just need some time, and I think wayland is a good modern protocol today updated to more recent machines. Evolution is that, make it better and make it according the needs of time you live in. Its just a step forward, maybe in 20 years from now or even earlier we get other solutions.

2 members found this post helpful.

Does anyone have any insight into the Wayland eyestrain issue? Are they handling video differently?

For my sins, I fixed Analogue tvs/monitors in the thermionic Valve/tube age(1970s/80s). Too much contrast was a common cause of eyestrain & headaches. The colours would change completely from one pixel to the next.

If the eye was built for 2D, it could be in perfect focus all the time. As it happens, the eye was created for 3D, where focus is very good but not 100%. The effect of too much contrast was that your eyes would show you rings around the transitions as eyestrain would develop within 10 minutes. The eye would also come under strain from staying at exactly the same focal length. This is the stuff of TV repair courses.

All these issues go away with age, as does exact focus. The eye is very adept at resolving 'blur circles.' These are caused by 'slightly out of focus' settings. So you rarely see something slightly out of focus, because your eye resolves it. When the blur circle gets too big, you can't resolve it. That's how pinhole glasses work, by shrinking the blur circle, and enabling the eye.

4 members found this post helpful.

<Disclaimer> - although I have read plenty about wayland/Xwayland, and become very plenty confused about them, (and probably am not using correct terminology), I have never tried running the thing. Maybe I should but why?</Disclaimer>

On your first point - the backlash against Xorg - I'm sure you are right in remembering a backlash against replacing XFree86 by Xorg, although I went through that same transition without either having any problem myself or seeing any mass protest. Xorg was (and remains) around 99.99% externally compatible with XFree86 as regards :
. configuration (the /etc/X11/xxx.conf and the xmodmap key/mouse-code mapper)
. window-manager application
Compare with replacing Xorg by ??? xwayland compositor. Both the above points are not only completely different, the second one becomes (for me) complete replacement by some other one (I use sawfish window manager and I understand that no xwayland compositor is ever likely to work the way sawfish does including its programmable interface, which I use extensively).

I think the point about the window manager - current with Xorg and whatever with wayland - is significant for anyone who chooses not to use one of the Corporate ones such as Gnome or KDE/Plasma. I have nothing against either of those and am sure I could eventually adjust to using either one (again) but I resent having to spend a serious amount of time getting something inferior to what I have now to work the way I like.

From what I have read, most of the claimed benefits of a wayland compositor compared to Xorg related to handling misbehaving X clients (e.g. forget to repaint its window) and/or deficient window managers (e.g. don't have any intuitive way of distinguishing and organizing the various windows, i.e. what is often called "exposee"). I don't seem to suffer such problems myself with my slackware+Xorg environment.

So I think the question I'm digging at for the Slackware community is, given what we (think we) know about the likely course of events and trend towards what will be xwayland compositor controlling the monitor(s) and compositing the clients' windows - will that be better than what we have now? Or worse? and how much work for us in adjusting?

On your second point, "Nothing's stopping anyone from ... isn't wayland or forking X" others have expressed the in various ways and yet more others have replied - the statement is literally true but practically and financially unrealistic. If it was a simple as that, someone would have done it long ago.

3 members found this post helpful.

Remember, evolution has no blueprint. It can branch off in any direction, including backwards.

Remember too that there are modern developments which are seriously retrograde. Touchscreen controls in cars, for example. Are they safer than using a mobile phone while driving? I don't think so.

I think the biggest problem with developments in Linux these days is that they are driven by the under-40s generation, who automatically assume everything old needs to be replaced by something better. It's only when they are in the thick of it that they realise things aren't quite as straightforward. But that's how they will learn. Just a shame we're the collateral damage along the way.

9 members found this post helpful.

Personally, I feel the "Nothing's preventing anyone from forking and writing their own..." argument no longer holds much water. Fine in the last millenium, where software was simpler & smaller; Fine for things like text only editors with simple output.

Now you have packages delivered & maintained by a team of people developing each aspect of the software. Any one person is prevented by time, money & human needs. A control specialist is not necessarily a database, graphics or security specialist.

I saw a unix C compiler from 1974 - it was 10K. Gcc-11.2.0 is 1.2M. One guy could have written the 1974 version, but not today's, with all of it's exotic security features and optimisations.

So, it's ok to bitch occasionally about where a project is going, as long as it's left at you airing your views.

4 members found this post helpful.

Keep in mind that no one is FORCED to change just because there is something new.
TinyX is depreciated, but some distributions still use it.
Slackware is conservative about changes, which is one factor giving it such dependable stability.
We CAN stay on X.org even if it is abandoned by nearly all other distributions as long as it works for us.
It is just not going to change much. But that can be a GOOD thing!

1 members found this post helpful.

Comparing security issues are enough for me to agree with the switch

Wayland:
https://nvd.nist.gov/vuln/search/res...meSearch=false

X.org:
https://nvd.nist.gov/vuln/search/res...meSearch=false

Not to mention the features

3 members found this post helpful.