The Wakefield committers may hold off-line discussions from time-to-time. Since these meetings are just for the committers and invited wayland experts, summary minutes will be recorded here as time permits
Online Zoom Meeting 9am PDT January 31, 2025
Attendees: Olivier Fourdan, Alexey Ushakov, Maxim Kartashev, Harshitha Onkar, Phil Race, Kevin Rushforth, Victor D'yakov, Alexander Zvegintsev
Alexander:
Fixed a problem with focusable popups being closed prematurely, it was not handled correctly before.
I'm updating the pipewire header files to a more modern version.
Alexey:
We implemented pixel grabber functionality for Vulcan hardware accelerated surfaces.
We're creating a sort of shortcut for the robot functionality to grab pixels directly from it.
I implemented it to do single window testing for rendering.
Within this work I implemented surface to software blit that is necessary to get the pixels, now running some tests from AWT part for regression tests, investigating the remaining failures.
Maxim:
As you probably all know, there are no absolute coordinates in Wayland. So for getLocationOnScreen I just returned zeros.
It worked for a simple Swing application, and it worked perfectly.
But it turns out that there are actually cases when you do have some glimpse into the Wayland coordinate system when you look at the relative location of the monitors that you have attached to a system.
And in XToolkit, it is visible, it matters, but the applications do depend on this.
So if you have two displays that are not perfectly aligned, for example, if the other monitor, not that your main window is on, is above.
So your monitor has a positive offset in the absolute coordinate system.
And this created a small problem, which I fixed by making all windows returning their primary monitors offsets as their absolute locations.
So you might have some non-zero offset, if you have more than one monitor,
For example, the monitor on the right would be the normal size, the monitor on the left would be the horizontal offset size, and so on.
So having this done, I started going around and finding and fixing all sorts of offset issues, mostly with pop-ups.
And it took quite a while because I don't normally use a setup where the monitors are not aligned. But people do, and they report problems.
And I started using this setup so that I could catch problems before others did.
And the other day, for example, I discovered that the robot implementation actually also depends on this feature, that the specification expects the robot to have coordinates on the screen that didn't matter before, but now they do.
One is the test that would just get the location of a JFrame, which is wrong because its specification says that this location is relative to the parent and not to the screen.
So to properly feed the robot the correct coordinates, you need to get the location on the screen.
But even if you do that in our Wayland toolkit implementation, you may still get the wrong result because of screen offsets in a multi-monitor configuration.
So the problem is simple, but it took a long time to figure out which places to fix and how, and I'm sure we're not done yet, as not all holes have been plugged.
As more people start using our pure Wayland toolkit, more bugs are reported, unobvious configurations are discovered, etc.
For example, someone recently tested the clipboard and discovered that it would not accept more than 64K of data.And it turned out that at least on my Ubuntu with GNOME 24.04, the pipe opened for clipboard content transfer is in non-blocking mode.
And the old IO in Java doesn't handle this very well. So it just exits as if successful.
And fortunately after writing the buffer capacity, which is 64K, it continues as if nothing happened.
Online Zoom Meeting 9am PDT December 5 2024
Attendees: Jonas Ådahl, Olivier Fourdan, Alexey Ushakov, Harshitha Onkar, Phil Race, Kevin Rushforth, Victor D'yakov, Alexander Zvegintsev
...
Attendees: Olivier Fourdan, Alexey Ushakov, Phil Race, Kevin Rushforth, Maxim Kartashev, Jonas Ådahl, Victor D'yakov, Alexander Zvegintsev
...
Attendees: Olivier Fourdan, Jonas Ådahl, Maxim Kartashev, Kevin Rushforth, Victor D'yakov, Phil Race
...
Attendees: Niels de Graef, Jonas Adahl, Alexey Ushakov, Kevin Rushforth, Victor D'yakov, Phil Race, Alexander Zvegintsev
...
Online Zoom Meeting 9am PST Apr 25 2024
Attendees: Niels de Graef, Kevin Rushforth, Victor D'yakov, Alexey Ushakov, Olivier Fourdan, Phil Race, Maxim Kartashev, Alexander Zvegintsev
Phil:
We made changes in the specification of the Java 21 to accomodate Wayland.
At that time wasn't expected to be backported, but in order to be able to run 8,11,17 which are LTS and will be supported for a significant period of time,
that will overlaps with the lifetime of RedHat Linux 10 without the X11 session support.
Maintenance Releases of Java 8, 11 and 17 specifications, will have these specification changes to allow the implementation update on those.
Alexey:
Do you plan to port all the code that we are going to write to that releases? Pure Wayland Toolkit?
Phil:
Not a chance. This is purely by XWayland, this is a spec change, we not even backporting the Robot changes we did in 21.
At some point RedHat, Oracle, Azul or somebody else might decide to put the Robot changes into their versions of 8, 11 or 17 as well.
After the specification changes in MR, you don't have to backport Robot changes, you are compliant at this point, but it just doesn't work very well.
Alexander:
I've been busy with beforementioned spec backports for the MR, discovered and fixed missing doPriviliged calls on our TokenStorage implementation,
Fix tests that try to interact outside the XWayland server. I also tried to test the XTEST - libei support(should be available on Gnome 45) on beta of Ubuntu 24.04(Gnome 46), but it doesn't work, no confirmation dialog appeared.
I tried the xdotool and java.awt.Robot(XTEST internally). Is this supported only on Fedora?
Olivier:
just a couple of comments on xdotool, it heavily using XTEST for everything, I personally fixed upstream, it might now work.
I believe mutter had support of libei before XWayland, this is still optional, meaning that it depends whether XWayland itself have been build with libei support or not.
So it depends how XWayland was build on Ubuntu, but if they build the XWayland with libeie, than the XTEST would go through the libei as you expected.
Alexander:
Another question, what about the HiDPI support patch for the XWayland? It's probably good time to make it into JDK 23
Alexey:
We actually switched to the pure Wayland implementation now, but I ask Nikita to continue work on this.
I continue my work on Vulkan implementation, hopefully we will have something next week. It is similar to the Metal work, but this API is more complicated.
I have something working, but I need to put it together to at least have something interesting to show.
Niels:
Last meeting you mentioned that software rendering practically complete. It is interesting to know how people evaluate this.
Alexey:
Software rendering works quite good, but we got everighing possible from it. It is slower than hardware rendering. From our perspective is quite good for the preview.
In some cases we have low performance.
Maxim can provide more details.
Maxim:
We have received quite a few reports from users who tried this Wayland Toolkit and run our IDEs on that, discover some bugs.
Actually nobody complains about performance, I don't think that expectations are high, people know that it is not hardware accelerated.
Main complaint was from, I accidently discovered that window resizing was way slower on Wayland Toolkit comparing to XToolkit.
I made a few changes and now we got ~30 fps in 4k when it was ~10 fps before, it's quite smooth, even with software rendering.
We made a bunch of fixes here and ther since last meeting, e.g. one of the guys added support for more than 3 mouse buttons, which was not present before.
Olivier:
There is a proposal for a new category of Wayland protocols at compatibility. That could be useful for Wakefield project as well. Right now it is more about creating the category.
The reason why I wanted to mention it, somebody mentioned Wakefield as part of the discussion, specifically about something Wakefield does, about a bug with the maximum size of a window.
Is that something that we know about?
Maxim:
If understand correctly, I did a small change relatively recently with regards to limiting the maximum window size, because one of the tests started crashing JVM. It creates a window of size MAX INT.
Now it limits the size twice the size of combined monitors.
Online Zoom Meeting 9am PST Feb 29 2024
Attendees: Jonas Adahl, Kevin Rushforth, Victor D'yakov, Alexey Ushakov, Olivier Fourdan, Phil Race, Maxim Kartashev, Alexander Zvegintsev
Alexander:
Not much to report, continuing my aarch64 testing on Wayland, so far so good.
...
Online Zoom Meeting 9am PST Feb 29 2024
Attendees: Niels de Graef, Kevin Rushforth, Victor D'yakov, Alexey Ushakov, Olivier Fourdan, Phil Race, Maxim Kartashev
Phil & Alexey : FOSDEM Free Java room session on Wakefield went well.
Session can be viewed here : https://fosdem.org/2024/schedule/event/fosdem-2024-2154-openjdk-project-wakefield-the-wayland-desktop-for-jdk-on-linux/
Alexey : Not much to report, been occupied with other tasks
Maxim : Ramped up testing so ran all AWT + Swing groups.
With WLToolkit - 70 % of Swing tests passed and about 25% of AWT tests passed
Trying to run in a weston instance via plugin which supports setting location, pixel grabbing,
input events. First obstacle was the stability of weston window manager which crashed in 10 mins.
Have just implemented a special mode in jtreg which would run each test in a new weston instance
Niels: Perhaps this helper daemon (written by Olivier ?) could help
https://gitlab.gnome.org/ofourdan/gnome-ponytail-daemon
Phil : to Neils: Is there any update adding restore token support in RHEL 9.x
Neils : yes, https://issues.redhat.com/browse/RHEL-4526 - shows it is targeted to be fixed in 9.4
Maxim :
Their users when learning that wayland doesn't support setLocation for window positioning are not happy.
Phil: whilst we have screencast for pixel grabbing, libei upcoming for events,
positioning is not something we know the answer to yet. Yes, spec. allows for it,
but it is a practical problem.
Niels: there are proposals around protocols for specific cases
Eg splashscreen protocol but not much upstream interest so far in implementing it
The session management protocol is also proposed
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18
and there is at least some work going on there :
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1444
Picture in picture has its own protocol used by firefox
Suggest go to upstream discussion groups and try to have productive discussions with
But a core API for setting global positioning is a hard pass for the compositor,
Maxim : session mgmt might help Intellij
Maxim: What are Oracle's plans for Wayland
Phil : Finishing up Xwayland support in JDK 22, there's also a need to add support
for XWayland to JavaFX's robot class. Sometime after that we will be able to turn attention
to pure wayland but OpenJDK projects don't have specific deadlines. When they are ready
we can have a JEP to propose to integrate it, but it has to be 100% TCK compliant for that.
Online Zoom Meeting 9am PST Jan 4th 2024
Attendees: Niels de Graef, Kevin Rushforth, Victor D'yakov, Alexey Ushakov, Alexander Zvegintsev
Alexander:
In December I did some testing regarding the "automated tests become manual on OL 9 because of confirmation for each screencapture".
How many user interactions (select display, click share screen button) are required to do this?
The answer is ~11k, so we are definitely not going to do this and will wait for the restore_token backport to 9.4.
Regarding not getting a displayChanged event after a setDisplayMode call:
On Ubuntu 22.04, we get a ConfigureNotify for the root window when we switch to a non-native resolution, but we don't get it when we switch back to the native resolution.
On Ubuntu 23.04 and 23.10 we get both notifications.
...
Online Zoom Meeting 9am PST Dec 7th 2023
Attendees: Niels de Graef, Victor D'yakov, Alexey Ushakov, Philip Race, Olivier Fourdan, Maxim Kartashev, Alexander Zvegintsev
Alexander:
I don't have much to share regarding Wakefield, just that the fix for not showing focusable popups has been pushed.
...
Recently Nikita asked about usage of C++ standary library in on Wakefield mainling list, I understand is not quite good for us. What about just C++? Hotspot use it.
Philip:
I do not like C++ at all, hotspots themselves had consequnces it terms of they basically had to abandom supporting some OSes because of C++,
and the Solaris organization said that they deliberately never allowed any part of core solaris to be written in C++. It just takes away a problem if we just stick to C.
...
The question is whether we should use C heavily or just move to java where it is possible?
Philip:
Yes, that sort of the architechture we've had in every other implementation of everything, it all lives in java then you just call native.
If we were to look at a long term future, we could use FFM. The idea there is that you write everything in java, and the native library just accessed throught FFM.
So writing it oriented around the native implementation, makes it a little bit harder to move to the FFM.
So I am not saying that you should adopt FFM for this, but you might want to think of it.
FFM is final as of JDK 22, I already pushed a small usage of it, but I have to jump through hoops. The biggest issue that we have that it needs some time to warm up.
...
The largest chunk of work that I did was to try to merry code in the Idea to the new reality of Wayland, some quirks that I asked on the mailing list,
when some window loses focus and it cannot know which one is going to get it.
The approach of waiting just a little bit for the other window to aquire focus works quite well(so far in a very limited context), but I am still trying things out.
Philip:
We saw that the Red Hat Linux 10 is planning to drop the X.org and X11 session, do you know when Fedora is going to do so?
...
Since Fedora is a community project, it is up to the community to decide. Fedora can take many more packages, if they want they can have a Cinnamon or other sessions, but we will not have X.org in RHEL10.
Philip:
I have a question regarding the OL/RHEL 9, Red Hat empasized stability, but the version of Gnome doesn't seem to support the restore token functionality that we make important use of it the screen capture code.
It was added in later version of Gnome, which did not make into 9, and it seems to be dooming us never be able to test Red Hat Linux 9 in X11 compatibility mode. If is definitely the case that they won't be ever upgrade Gnome in 9?
...
Online Zoom Meeting 9am PST Nov 9th 2023
Attendees: Niels de Graef, Victor D'yakov, Alexey Ushakov, Kevin Rushforth, Philip Race, Olivier Fourdan, Maxim Kartashev, Alexander Zvegintsev
Alexander:
We have a regression for my fix for a popup dismiss on focus lost. It was reported by an external developer.
My old fix does not take into account that popup may be focusable(e.g. has TextField). I have a solution and will publish it soon. And we'need to backport it to JDK 21.
...
Most of the progress was not in the wakefield framework, we started experimenting with running our IDEs using the pure Wayland toolkit, so far so good. I had to make quite a few modifications to the IDE code that relied on certain XToolkit related classes and made a lot of assumptions out of that. There are, of course, there are quite a few hiccups here and there.
For example, some of the popups just flash instead of showing themselves at a certain position on the screen, or pasting does not always work for some reason, it starts choking every 5 times. There are weird corner cases and I'll have to go through mostly the IDE code, rather than the toolkit code to iron them out before we go public with this.
It is still usable, performance wise feels about the same as XToolkit. Resource wise, it seems to consume slightly more memory, but I haven't spent too much time looking into that.
My main concern for me at this point is a window placement, and I was wondering if guys from RedHat might have some advice on that. I discovered that gnome has a kind of extension interface for Wayland, where you can set a modality for your window. It has a very nice effect on modal dialogs, it darkens the background, it does not allow to it does not allow the focus to be transferred to the parent window, it shows the dialog centered on top of the window that it is its parent, it is all very well, except that many of our windows are not really dialogs, although they act like ones. For example, the find window, it is not modal, it does not prevent you from focusing a window underneath it, and the problem for me, and I suspect for many users, is going to be that it always opens towards to the top left corner of the screen no matter where you opened it last time.
So I was wondering if there is any way to at least open the window in the same position it was opened before?
Is there anything else I can do, like give the window manager a hint that I want it centered relative to my parent window?
Philip:
I played with the stuff you pushed into the wakefield project repo, it was clearly software rendering. And it is pretty good, reasonably fast, so it doesn't feel like it slow at all.
But there are some other things that are noticable, there was not gtk integration, or gnome integration, so the font were all black and white, because it wasn't picking up any of the desktop settings. The positioning thing was very obvious. The exceptions and messages continually being streamed to the console, but the overall UI was fine.
Regards to the windows positioning, clearly we have a modal and non-modal dialog, and it would be nice if non modal dialog could get the same positioning and treatment as modal dialogs.
...
The xdg-session-management protocol is under discussion and it has not yet been merged. Basically, it allows a client to request that client windows be restored to the same positions as before.
Philip:
We talked about the session manager in the past quite a while ago. I think we need to understand how we actually distinguish Java applications. It doesn't help with the first time, and even if this is absolute positioning, this window that I can recognize comes up with this position, but you really want it relative to your main window, and you window can may be moved around. It is not the something that happens only at startup, e.g. how to recognize a window shown before is the same window shown after, maybe the session manager takes care of all this in some clever way, but I am not sure about it.
...
Online Zoom Meeting 9am PDT 12th Oct 2023
Attendees: Niels de Graef, Victor D'yakov, Phil Race, Olivier Fourdan, Maxim Kartashev, Alexander Zvegintsev
Alexander:
The fix for taking screenshots on a displays with different scales is integrated.
It looks like we will support X11 compatibility mode in the next JDK release(at least for Ubuntu 22.04 for now). Probably we'll also include the latest Oracle Linux and RHEL.
Phil:
Let's try to test the latest Fedora as well, I know it is not on Oracle supported Linux list.
Alexander:
I recall that a fix for HiDPI support in X11 compatibility mode was posted to the Wakefield mailing list for the Wakefield sandbox, I think it is a good time to integrate it to mainline(JDK 22).
Maxim:
I think it was dependent on some other minor thing that I did, but I also don't remember the fate of it. I'll check on that, if the dependency is in the mainline, I'll ping the guy responsible for the fix.
Actual rendering with Vulkan started to happen, there is some progress in this area, but not very visual.
I did some minor fixes here and there in the Wayland prototype, I implemented the clipboard support, I started working on DnD, but it turned out that is a lot larger that clipboard support.
We are trying to wrap things up to come up with a more or less working solution to show the JetBrains IDE, actually at this point, the goal is almost on the side IDE,
they do some funny stuff with popups, some of them show up in weird places. It is practically the main major thing that prevents IDE from being usable from pure Wayland toolkit.
Tried to run this thing on KDE, but faced some KDE issues, like XServer is crashing every several minutes, unable to logout without killing something, etc.
We also have some difficulties to setup out testing virtual systems in the cloud to start with Wayland session, no matter of the config, investigation is ongoing.
The amount of tests is not significant, I managed to choose 400 hand picked tests, that still run in pure Wayland session, we have to use som jtreg 7.3 to pass all required env variable.
Those 400 are picked that can be used unmodified, so don't use Robot, don't rely on positioning of a window exactly, etc, but they still make sense.
I have a question related to splashscreen, how do we implement the decision which toolkit to use, especially when the splashscreen to be shown?
Alexander:
We still have the positioning issue for Wayland windows(we can't contol their position), we can use the X11 splashscreen since it doesn't have one(for now). Even if the toolkit will be Wayland later.
Maxim:
The positioning problem is sort of solvable with a large transparent window to the size of the screen, and then draw you splashscreen inside of it, but the problem of having an X11 splashscreen
and then proceeding later with the Wayland toolkit that you have to have the ability to draw over the splashscreen once toolkit get loaded.
You have to have a handle of a window that you showed during the startup, and then that handle has to be reused somehow when you have your AWT,
when you can paint and everything else, so it has to stay within one toolkit.
Niels:
Can we just tear down a splashscreen window and then immediately start a new one?
Maxim:
It is not technically possible, the shared code, the infrastructure that works on all the other platforms is set up such that at a startup you fire up a window
with the ability to save its opaque handle to the window for the code that comes later and be able to draw on that window, other than a static image that we took from a file(jpg, png gif).
Phil:
If we tear it down, at least there'll be some kind of flicker.
For now, if you want just to test this out, if this in production, I would stick for X11 for a while, and I only switch to the Wayland implementation where there is a high level of confidence.
But you obviously want to test out the Wayland implementation, so I would just use an environment variable.
Maxim:
That is the only thing that touches shared code. Do you have some recomendations what's not to do in shared code?
Because this platform is so specific, so it has two toolkits.
Phil:
For now just do what you have to do in the shared code, and we refine it later.
Niels:
Just wondering in regards to CI problem that you have, so one thing you could do is just run mutter or even gnome shell as headless.
That you can use to immediatelly run it as Wayland compositor.
gnome-shell --headless --wayland --virtual-monitor 1920x1080
Online Zoom Meeting 9am PDT 17th Aug 2023
Attendees: Niels de Graef, Victor D'yakov, Phil Race, Olivier Fourdan, Maxim Kartashev, Kevin Rushforth, Jonas Adahl, Alexander Zvegintsev
Alexander:
As suggested, I implemented the approach when the session is not closed right away, but after a few seconds of inactivity. It gave a significant boost for certain scenarios, e.g. taking pixel by pixel in 50x50 area took 375s before the fix and only 28s after the fix.
Other than that working on various HiDPI scenarios for taking screen data in X11 compatibility mode.
...
Attendees: Victor D'yakov, Alexey Ushakov, Phil Race, Kevin Rushforth, Maxim Kartashev, Olivier Fourdan, Alexander Zvegintsev
Update from Alexander :
Screencast support for AWT Robot was integrated into JDK 21
...
Attendees: Victor D'yakov, Alexey Ushakov, Phil Race, Kevin Rushforth, Maxim Kartashev, Olivier Fourdan, Jonas Adahl, Alexander Zvegintsev
Alexander:
we have pushed several changes related to the X11 compatibility :
JDK-8307779 - Relax the java.awt.Robot specification
JDK-8280993 - [XWayland] Popup is not closed on click outside of area controlled by XWayland
CSR JDK-8307456 approved for the java.awt.Robot taking screenshots issue wth Screencast. This fix is also targeted to JDK 21.
Drag and Drop does not work in java -> wayland app direction: while this DND fix has been released on the system side(1, 2), changes are still required on the JDK side.
Our code it quite picky for the drop target, and requires it to be a toplevel with WM_STATE property, whereas the Wayland server uses dummy windows without this property set.
I already have a fix for this on the JDK side that I want to put in 21, but first I want to make sure I didn't break anything. In any case, it will be active when the Wayland session is active.
...
There will be a separate PR for changes: code changes and spec changes to make it easier to review(dependent on each other). I'll post a head-up message to wakefield mailing list.
Niels:
About libEI, progress is still being made, and we are getting closer to something stable and ready to merge . One of the latest protcol changes , to not depend on protobuf anymore.
We are still planning to make it Gnome 45 and Fedora 39.
...
For libEI we are expecting last few API tweaks, obviously we want to do all that before we declare the API stable.
Niels:
How is the pure Wayland stuff going on? I understand that it is not going into JDK21
...