wayland support

[codesardine]

wayland support falling back to X11 will be a neat feature since development seems to be going that way will improve graphic performance and might even get some devs contributing back to your project and more people getting there eyes in jwm, not alot of WMś support it.

[scsijon]

this is worth looking at again joe as it's now starting to spread.

some url's worth looking at are:

http://wayland.freedesktop.org/ http://dodonov.net/blog/2011/06/11/x-org-wayland-and-all-that-awesome-low-level-stuff/ http://lwn.net/Articles/415589/ http://www.h-online.com/open/features/Wayland-Beyond-X-1432046.html http://en.wikipedia.org/wiki/Wayland_(display_server)

just to start with, there is a heap more, arch, mint, ubuntu and raspberrypi all have working versions available and i'm working towards a puppy version using XWayland so we have the best of both worlds.

[cicku]

It's something we should have in the future, but not now.

Fedora has been stumbling on wayland for several releases, until recently it started using wayland in gdm login screen ONLY. Actually based on my experience of wayland, it still sucks, acceleration in GNOME doesn't work very well.

[dumblob]

Thinking about properly supporting Wayland (i.e. getting rid of xlib and related stuff completely), it's definitely possible and I think it's worth it.

But because Wayland doesn't provide any graphical drawing primitives (except for very low-level "shaders"), it would make sense to use e.g. Zahnrad for drawing. This should be easier than reimplementing basics manually and at the same time should make JWM even more portable than right now.

[technosaurus]

For those of you that think wayland/mir/surface is (going to be) the next great thing, the X11 protocol is actually better for most purposes, though it could use some updates.

Since Linux 4.2, the kernel supports splice() on sockets, which could make the common configuration using Unix domain sockets much faster if the server and client were Linux-4.2-aware... This is called zero-copy. On top of that the X11 protocol is extremely simple - basically you write a request number, length and struct data to the socket, then (depending on the request) read the reply.

Wayland, Mir and Surface (Android) require the end user (or obfuscation layer - my term for an abstraction layer) do all of this themselves ... with opengl. Take a look at the differences in any cross platform toolkit that supports both an X11 and wayland backend ... the wayland backend essentially has to implement most of an X11 server... Talk about Don't Repeat Repeat Yourself... If every application/toolkit does this the overhead adds up fast and unfortunately, unlike Android and Windows, Wayland still doesn't have a decent defacto toolkit to rely on.

The problem with X11 isn't the protocol, it's the implementation. A good Wayland implementation is going to outperform the current, hideous xorg-server implementation with decades of bolted on fixes and #ifdefs for platforms that ceased to be relevant before Linux even existed. Did you know there is still a decade(s) old bug to use system iconv instead of its builtin version that accounts for ~1/3 of libX11.

[ghost]

How is this as of now? I am just wondering if Wayland support would be nice.

[ghost]

How is this as of now? I am just wondering if Wayland support would be nice.

yes i am waiting for it too

[doverresearch]

I may not understand it (So excuse my ignorance) but from what I've seen its just another abstraction layer that sits on top of X11. I listened to a guy rant about how everyone hated X11 and that by plopping Wayland on it the code would be easier or something. To me there are several good swear words. Abstraction Layer and Obscufication. People having contests to see who can Obscuficate better I would think are almost certain to be sent to some form of computer hell after they pass. As to abstraction layers the fellow who wrote Circad (A windoze) electronics package told me that none of the windows API calls worked properly or fast enough (Usually both) except set color. This is from memory but he said something like 100s to 10s of thousands of times too slow depending on the lines angle, width and how it ended (Square or Rounded) He ended up using one call to locate the start of screen memory and wrote his own line draw routines. If nothing else the demo is worth looking at just to see something thats done by someone gifted (like Joe!)

Huge hard drives boggle my mind a bit having the job of putting a 5 Megabye Seagate drive on a machine I helped design but the unreal power of modern computers? And the MIPs they are capable of? All wasted by people piling new heaps of code on top of other heaps of code on top of (etc etc etc)

[Faalagorn]

I may not understand it (So excuse my ignorance) but from what I've seen its just another abstraction layer that sits on top of X11.

Actually not, if at all, Wayland is much less advanced than X11 as compositors take all the burden. Maybe you confused it with how PulseAudio works by being an another layer over the ALSA?

[01micko]

We've been doing some work getting jwm to work under cage in woof-ce (puppy linux).

It's in it's infancy but progressing well enough.

I think trying to shoehorn jwm as it is into wayland is a bad idea. A new project, say jway would be the way to go!

Of course, real life dictates all as time is precious.

---

Screeny depicts slacko64 alpha running under cage on a dual monitor setup:

[dumblob]

@01micko that sounds interesting - I've looked at the cage repo (neither in any of the branches nor in the issue tracker), but couldn't find basically anything regarding porting of JWM to Wayland.

Could you point me to the right places and clarify what's the current state & further plans?

[01micko]

@01micko that sounds interesting - I've looked at the cage repo (neither in any of the branches nor in the issue tracker), but couldn't find basically anything regarding porting of JWM to Wayland.

@dumblob jwm is not ported at all, it is untouched. Cage is a 'kiosk wayland compositor'. See https://www.hjdskes.nl/projects/cage/

The whole puppy desktop runs under cage and it would possibly work with openbox or icewm or whatever.

Could you point me to the right places and clarify what's the current state & further plans?

See https://github.com/puppylinux-woof-CE/woof-CE/projects/1

@dimkr has done all the work, I've only been testing and offering suggestions.

[dimkr]

I think trying to shoehorn jwm as it is into wayland is a bad idea. A new project, say jway would be the way to go!

That is definitely on my TODO list!

At the moment, my focus is to get things like wlr-randr (https://github.com/Hjdskes/cage/pull/212) and swaybg working, and make Cage configurable to some degree (i.e. input device settings - https://github.com/Hjdskes/cage/pull/188). Puppy uses xrandr to set display settings, has a wizard that configures things like mouse acceleration, and so on - we need 1:1 equivalents of all these building blocks.

When all these building blocks are in place, my plan is to fork Cage, stop maximizing the single application window, start drawing JWM-like window borders, and implement stuff like Alt-Tab. Basically - gradually re-implement Puppy's JWM desktop on top of Cage.

[dumblob]

we need 1:1 equivalents of all these building blocks.

That'll be a lot of work. A lot. But yeah, Wayland is to stay, so it's worth it!

When all these building blocks are in place, my plan is to fork Cage, stop maximizing the single application window, start drawing JWM-like window borders, and implement stuff like Alt-Tab. Basically - gradually re-implement Puppy's JWM desktop on top of Cage.

I know this is too early to ask, but anyway :wink:. Do you aim for 1:1 compatibility with JWM XML files (incl. corresponding functionality) or rather something different? If different, do you have somewhere any todo list how that should look like (feature-wise)?

[dimkr]

I know this is too early to ask, but anyway wink. Do you aim for 1:1 compatibility with JWM XML files

No, I hate XML, and I think things like the tray and menu should be handled by external programs - that's the Sway approach.

[dimkr]

Started working on this JWM-like compsitor concept. So far, I have window borders without buttons and a title and working Alt-Tab.

[thetwin9000s]

Just one point I would like to make. And I might have this all wrong or I just don't get it but... JWM is written to connect with X11 which might not be what everyone "likes" but its at the lowest point to the display hardware. Correct? Things like Ciaro, GTK or Wayland (I think?) are added (on top) abstraction layers that force the code to jump through hoops to get to the physical display. When I read that someone had created a windowing manager that used JUST X11??? Hoo Hoo!! The original idea for "X" was quite good I thought. Simple stuff written for speed not ease of writing someone's idea of a standard. Like the whole idea of the PARC model with the exact same look and feel? Why? Can nothing better be ever created? Anyway I was very pleased with Joe building this very nice system which can be compiled without even using much of X11. Which is also good because I think that minimalist idea got pushed aside and it got a lot of added features that didn't really meet that keep it simple let the programmer do with it what he/she will. That aside I hate having systems stuff need abstraction layer heaped on abstraction layer (etc etc etc)

Am I wrong? I think if for no other reason JWM should be left alone.

I'll add one thing I admit having zero first hand know how of but here it is. My read on Wayland is that the people I've listened to talk about it have a lot of smack to talk about X. How its old, how its this or that and Wayland has been talked up a lot but I've yet to hear much from its users who aren't having problems so my thought is thanks but none for me.

But then I like ALSA and dislike having to add Pulse running on top of it to be able to get sound from a program. If Pulse was a better faster than ALSA replacement I would certainly be interested but abstration layers... Can't we keep it tight, fast and small? *Yes, I know ALSA is not tiny. And not really the topic.

Why not start a different window manager for Wayland (or Ciaro or whatever) Those of us who aren't buying the latest and fastest hardware will still have one windowing manager without the bloat! And last time I looked you could still compile JWM with only a couple X11 library calls if you wanted to. THAT seems very cool to me as the insane number of libraries needed to compile even simple stuff seems like it keeps growing being more obscure or difficult to even find that I wonder if there might not be a call for an OS built along the original principals of X.

Is it just me?

[dumblob]

@thetwin9000s hm, I'd say the whole point of this proposal is much simpler than what you describe. Namely to be able to use JWM on systems which'll not have enough of X11 apps any more or even systems which will not support X11 at all.

And for JWM you'd probably need a few years od occasional development to support Wayland in full. Thus this discussion we have here is in no way too early. Actually almost the opposite...

[thetwin9000s]

Well as I pointed out the huge size of Linux and its apps and the unmeasurable amount of computer cycles wasted adding piles of abstraction layers does inspire some thought to starting off with the idea of a new lean machine without any requirement to run everything ever created before. But really I have to ask. Why JWM and Wayland? Mix something small and fast with something that can't fail but to be slower?

And I did a little more reading about the opinions of users of Wayland and it seems like its not really ready for the spotlight. Of course in anything the people complaining about something outnumber people who are content. One reason the doctor review sites seem so slanted to the negative so I take that with a grain of salt.

Since X11 is between everything we use and the display drivers I think your statement of less software using it isn't exactly correct. Programs that don't use something between X11 and the App are fewer because people like the ease of building menus, windows etc with stuff that is in between using something like GTK, Cairo or QT for example. Without X11? GTK (and the others) don't work. I know they are trying to do away with X11 but I think that is still not quite there. *note I could be wrong or out of date. If someone really wanted to do a full replacement for X11 say make a GTK that talked to the display driver? That would be worth getting worked up about. Like I said improve the bottom layer if you can. Don't heap more abstraction layers on top of abstraction layers.

Unless someone wants to fork jwm I think Joe probably is the only one that matters in as far as accepting the task anyway so depending on what he thinks about it makes our proposals or debate rather pointless..

On 2/24/22, dumblob @.***> wrote:

@thetwin9000s hm, I'd say the whole point of this proposal is much simpler than what you describe. Namely to be able to use JWM on systems which'll not have enough of X11 apps any more or even systems which will not support X11 at all.

And for JWM you'd probably need a few years od occasional development to support Wayland in full. Thus this discussion we have here is in no way too early. Actually almost the opposite...

-- Reply to this email directly or view it on GitHub: https://github.com/joewing/jwm/issues/103#issuecomment-1050119486 You are receiving this because you were mentioned.

Message ID: @.***>

[Faalagorn]

You are right with Cairo and GTK, but Wayland is a display server, a replacement for X11, there's xwayland implementation for Wayland to allow running legacy X11 apps, but if you don't have them, you don't have to use X11 at all with Wayland.

[01micko]

From GTK 3.2 (irrc), GTK works just fine on pure wayland. If your favourite apps are older than that then fine, stick with X. However as @Faalagorn stated lots of them run if a compositor is build with Xwayland support. Most of them, as far as I know, can be built with this.

Cairo is very important to wayland. Lots of wayland compositors use it, plus pango.

As for the JWM supporting wayland, IMHO, that will not happen. Wayland is too different and would require too much work. In wayland, much more control is given to client side apps, so in a way, it stays out of the way more than an X window manager.

Of course @joewing may decide otherwise but I doubt it. Better off to contribute to another wayland compositor, or write a bar similar to jwm's, or start from scratch.

[thetwin9000s]

Really? I must have been reading it wrong *which is not unusual. I think its just the number of programs that form new abstraction layers continue year after year but taking something like X11 and making a better one? I have to say I'm surprised. Hate to admit this also (Egg on face) It will be interesting to see if Wayland makes the system faster which would really be something or is a giant slower blob. I think the previous comment about it being a mountain of work to make JWM work on Wayland sounds right unless Wayland is call for call compatible which would make sense if you wanted everyone's old stuff to continue to work. I do like the idea of doing a rethink on software in general and focus a little more attention on bloat/speed. JWM was always (I think) exceptional in that regard.

On Sat, Feb 26, 2022 at 1:54 PM Faalagorn @.***> wrote:

You are right with Cairo and GTK, but Wayland is a display server, a replacement for X11, there's xwayland implementation for Wayland to allow running legacy X11 apps, but if you don't have them, you don't have to use X11 at all with Wayland.

— Reply to this email directly, view it on GitHub https://github.com/joewing/jwm/issues/103#issuecomment-1052132120, or unsubscribe https://github.com/notifications/unsubscribe-auth/AX4OERTLZ4HTPG47AITRGHLU5DLQPANCNFSM4ALBIZYA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[dumblob]

Let us prolong the agony: https://www.phoronix.com/scan.php?page=news_item&px=XWayland-Rootfull-Desktop

Ok, now seriously. This is breaking news! No need to rewrite JWM but simply run it on XWayland! I wonder whether one could also manage all pure Wayland windows with such XWaylend-driven window manager.

@joewing this is good news - feel free to read the article and maybe even test it if you are a highly adventurous person :wink:.

[dimkr]

Puppy Linux already supports JWM under a fullscreen Xwayland with 1:1 feature parity compared to JWM under X.Org, see https://github.com/puppylinux-woof-CE/woof-CE/wiki/Wayland-Support#current-status-1.

The Xwayland changes are nice, but not required to run JWM under Xwayland. Puppy uses a patched dwl, which maximizes the first Wayland client (Xwayland) across all monitors, and sets GDK_BACKEND=x11 to force all applications to run inside this Xwayland window. Native Wayland clients which refuse to use X11 float above the Xwayland desktop: when they're focused, dwl handles key bindings instead of JWM.

[keshto]

I started this https://github.com/keshto/tinywl_plus and it is handles windows for the most part like JWM. Big things it is missing are font rendering to render the titles and read/writing config, but think we can get there. I am more than happy to help out where I can.

[xplshn]

Any updates on this? @joewing ?