@thomasadam @peppe Thanks for that! I totally forgot about the decorations topic, which is of course very relevant, it means even jumping through the hoop and implementing a #wayland compositor, you can only deliver part of the functionality (and almost none of the looks) of your window manager.

But even with that issue solved, I would really dislike wayland's design. Although I *do* think that most of #X11 core drawing is obsolete and useless (mostly for the missing alpha channel), I think a display server should offer drawing facilities. Replace X with something dropping lots of cruft (indexed palettes, COMPOUND_TEXT, etc), instead incorporate extensions that everyone needs these days, extend #XRender (now as part of core) to offer more drawing primitives, etc ... you could have a replacement for X11 that's worth dealing with. And window managers could still be separate clients.

@kf @boo_ @ericsfraga

I would love for #EXWM to be #Wayland

@peppe To be clear about that, I don't question the fact that #X11 is full of old cruft that's mostly useless nowadays. It became more than clear to me while implementing my #xmoji tool, which uses almost exclusively #XRender requests for rendering (an *extension* to X11, not part of the core protocol), because X core drawing requests are really designed for 1990es hardware, supporting color palettes with limited entries, but no alpha channel whatsoever. Similar goes for font support in the X11 core protocol, it's useless supporting only bitmap fonts with no antialiasing etc, so I use client-side rasterizing (with freetype) and XRender only for compositing the result. There are more silly examples, like the "Compound Text" encoding monstrosity, because the core design predates Unicode, and so on....

In a nutshell, a major rework of what the X core protocol supports would be necessary.

But then, you can *still* dislike a suggested solution. I think #wayland is taking the "simplicity" much too far, so now both compositors and clients (rendering windows) have to do the same stuff over and over again. It's a pointless exercise trying to create a wayland client without huge libraries (such as e.g. cairo for client-side rendering, better yet use a full-blown toolkit like Qt or GTK that already makes use of cairo), while this is perfectly possible for X.

Ok, first reaction (confirming my suspicion that #glamor causes the bug) was super quick, I'm impressed! Let's see whether anyone jumps in soon to actually analyze the root cause.

JFTR, it's the bug I already probe for in #xmoji to enable a silly workaround when necessary, applying a transformation to the source picture.

@nebucatnetzer slightly off-topic, but I switched away from #GNOME to KDE #Plasma, since GNOME #Wayland doesn't (?) support server-side decorations. I'd have switched to the GNOME #X11 session, but I'd have lost workspace swiping and smooth scrolling.

Bonus points if you know any magic that would give me a #virtualKeyboard that could be invoked and used with mouse on a desktop without a touchscreen.

I exhausted any options that made sense to me and I can't dig and try random stuff beyond what I can fix back, because I really can't nuke this system.

Switching to #X11 is not an option for reasons.

I would appreciate any input.

@tripplehelix

#OpenBSD is a really great first BSD to try, IMHO.

You get less Linux compatibility, but it's more out-of-the-box-ready. Plus lots of old-skool #UNIX feels with #FVWM ;)

I still have OpenBSD running on my X200 with i3wm. It's solid. Unless I try tweaking power settings the kernel doesn't like, lol.

OTOH, #FreeBSD's handbook is freaking fantastic, and I was able to get #X11 running on my old #Thinkpad X200 with it.

@tripplehelix

I'm guessing you're taking about #FreeBSD.

Both #NetBSD and #OpenBSD give you a working #X11 immediately after install.

#NomadBSD even gives you #xfce