Based on the title, I thought this was going to be a wayland compositor on the JDK; it's not, it's work to make java (swing?) render to wayland without xwayland. Which is definitely a good thing, just not what I expected:)
They say that one limitation on Wayland is that "AWT expects to be able to query and set the positions of all its own windows", but since AWT does an extremely poor job of this on X11, I hope this Wayland limitation will prevent the new implementation from trying.
For example, the first time you open a dialog window (or the main window in the SwingSet2 demo) you can usually see the contents drawn offset by a few pixels and then later redrawn correctly. I don't see that in the demo video, so maybe they fixed it, or maybe it's hidden by the opening animation. (It might also be harder to reproduce with certain window managers – I see it every time with Xfce but only sometimes with Openbox.)
Sometimes (although rarely) you can see Swing creating a window in the wrong location on screen, making it visible and then moving it to the correct location afterwards.
And on and off over the years, on both Linux and Windows, in different apps, I've seen Swing somehow manage to move focus to the wrong window when you switch too quickly with alt-tab.
So if AWT can't mess with the window position, that should hopefully improve things.
I'm using Rider with this. There's a Nix flake in the Wayland testing issue in the jbr repo for those interested. It's looking really good so far, I'm very much enjoying the reduction in latency.
Does wayland/x11 use generic GPU drivers(that is supported by all GPU) to write to a framebuffer? For example, if there is no shell such as Gnome or KDE, and we are only booting to a terminal - do wayland/x11 still use that generic GPU driver to draw letters to the screen?
Thanks, but how does Linux kernel ensures that it can talk to all framebuffer devices out there? Does it come with a generic implementation that all GPU vendors support?
Wayland is just an IPC protocol, so it imposes little. In practice compositors use mostly hardware agnostic Linux APIs. The driver needs to support things like KMS, DRM, GBM, etc.
So, is it correct to say Wayland, the process drawing everything on the screen by writing to a gpu framebuffer, is just another linux process with escalated privilege?
Wayland client and server share video memory buffers through libdrm GBM API (Mesa) and DRM was designed so that Wayland can use wl_drm protocol without escalated privileges.
Can't wait for this to finish. The inability to screenshare with java.awt.robot is what's preventing ScreenConnect and thus my desktop from dropping X11 compatibility.
Is it 2007? I remember seeing it much earlier - like 2001-2002 or so. Maybe SwingSet2 was the follow-up to some SwingSet1 that came earlier, and which contained a lot of the same stuff?
Yes, there was an earlier SwingSet, but someone told me that even SwingSet2 was earlier than 2007 (I went by the first copyright year on the source code).
You're not too far off the mark. That demo, SwingSet2, was written in 2007 (and possibly still uses the look & feel of that time, I think), but you can run it, unchanged and probably without recompilation on JDK 22 as well as the Wakefield build (native Wayland) it seems.
There are lots of xwayland-specific bits needed to handle it running under a compositor but still acting as a privileged client compared to regular Wayland clients.
It's probably not as difficult as you'd think. Embedded X servers have existed for a long time (that is, running an X server as a client of another X server), and running them rootless (without displaying a "desktop" of their own) is also nothing new.
From there it's just a matter of writing the code to allow it to be a wayland client, which isn't that hard, and then doing translation between the wayland event callbacks and X events.
That will at least get you something basic working. There's a bit more to it, of course, and those details are why it's still actively maintained and worked on, but it's not too crazy.
The wayland compositor itself does need to special-case Xwayland, which brings some complexity.
It doesn't really. Xwayland is pretty much an X server that draws to Wayland instead of directly to the display. You can write an X server that draws to anything: a display, a printer, a Windows or macOS surface, an OpenGL texture...
Xwayland is even based on the same Xorg codebase, it's just that the DDX ("device-dependent X") layer used is Wayland-based.
Now I’m going down the weirdest nostalgia trip down memory lane of when I was a teenager and thought Java web applets were the coolest thing since sliced bread because you could run OpenGL in a browser.
You know, I thought it wasn’t for a while there, but I’m not so sure right now. If it’s cool, maybe it’s kinda retro-cool, like “late 90s enterprise webapp” cool. Is that cool? Not sure.
