Project Wayfield – The JDK Wayland Desktop on Linux [video]

https://inside.java/2024/03/24/openjdk-wakefield/

by Tomte • 2 years ago

70 33 2 years ago

zamalek• 2 years ago

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.

exabrial• 2 years ago

TIL Wayland had an X11 compatibility layer... bless ya'll's hearts! That could not be easy.

chungy• 2 years ago

The X server is fairly portable, and XWayland is built directly from the X.Org sources.

It also has ports to Windows and Mac OS X ...

Quekid5• 2 years ago

Plus... Wayland is literally the work of many of the original X.org devs.

Arnavion• 2 years ago

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.

maxhille• 2 years ago

And AFAIK the only part of Xorg where development happens in the recent years.

yjftsjthsd-h2• 2 years ago

Not only (standalone Xorg continues to get small features), but likely the most active.

kelnos• 2 years ago

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.

bitwize• 2 years ago

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.

coldtea3• 2 years ago

There was one for Windows, Mac and others, why not Wayland?

And wasn't the X11 compatibility layer one of the first things developed for Wayland, since a lot of DEs/apps didn't directly support it yet?

yjftsjthsd-h2• 2 years ago

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:)

sgt• 2 years ago

Demos remind me of something from 2003 though.

pron3• 2 years ago

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.

paltaie• 2 years ago

That would be because that demo (SwingSet2) is probably that old! https://docs.oracle.com/javase%2Ftutorial%2Fuiswing%2F%2F/lo...

Edit: close enough, 2007

coldtea3• 2 years ago

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?

znpy• 2 years ago

From the title it seemed to me it was something of a revival of that old thing, Project Looking Glass 3D (https://en.wikipedia.org/wiki/Project_Looking_Glass).

iamcreasy3• 2 years ago

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?

gertop• 2 years ago

X11 and Wayland aren't involved with text mode. The kernel implements its own framebuffer: https://www.kernel.org/doc/html/latest/fb/fbcon.html

iamcreasy3• 2 years ago

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?

TingPing• 2 years ago

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.

iamcreasy3• 2 years ago

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?

binary1322• 2 years ago

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.

I really thought Java was cool.

lilboiluvr692• 2 years ago

Is Java not (still) cool?

binary1322• 2 years ago

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.

ptx• 2 years ago

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.

lilboiluvr692• 2 years ago

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.

Project Wayfield – The JDK Wayland Desktop on Linux [video]

Related Stories