Page History

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 June 20  2024

Attendees: Olivier Fourdan, Jonas Ådahl,  Maxim Kartashev,   Kevin Rushforth, Victor D'yakov, Phil Race

Vacation season : several people out today, and because of same we will not meet in July

Phil : DnD bug https://gitlab.gnome.org/GNOME/mutter/-/issues/3511 is a TCK compliance issue for JDK
Jonas :  DnD bug should be fixed in Gnome 46.3 (6-29-2024)
We may need to follow up with distros to get it backported.

Phil : is libei ready for experimentation
Olivier: yes

Discussion about c/h files generated from wayland protocol files - we should
generate these at build time, not check them in. JDK build will tell a developer
of missing dependencies and how to fix during configure. To build on older OSes
such as are used by CI build systems will instead require a devkit.
These are already extensively used by the JDK build.


Maxim:
Keeping Wakefield repo up to date with WIP.

Figured out what seems a reliable way to count FPS on wayland.

Have someone to work on Input Method support - common request
Jonas : Is this V3 - also there may be a meeting this summer in an occasional
series to discuss requirements for input methods. Maxim will send contact info
so the person working on it can participate if/when it happens.

Online Zoom Meeting 9am PST May 23  2024

Attendees: Niels de Graef, Jonas Adahl,  Alexey Ushakov, Kevin Rushforth, Victor D'yakov, Phil Race, Alexander Zvegintsev

Alexander:

I was mostly focused on stabilizing tests. Many of them were failing, some for the non-obvious reasons.

For example, there is a difference. It looks like there is a difference in implementation between XWayland server and regular X11 server.

We have a couple of tests where we are not releasing the mouse keystroke or the keyboard keystroke.

This looks like the regular X11 server would release these keys when the client disconnects.

But for some reason, XWayland does not. For example, we can get a failing test like a few tests after those tests which failed to release this key.

But just releasing this key is good enough to fix that.

There was some test that counted mouse enter/exit events and making some action to frame like iconify, deiconify, maximize and so on.

For some reason after maximizing both for a frame, mouse coordinates reported by XWayland go crazy and we are missing these events.

Is it our issue or not? But it seems like a bug somewhere outside.

Victor:

And just to explain to everybody on this call, by stabilizing tests, we are talking about open JDK in the mainline, which right now is JDK 23.

So we will fork in two weeks.

So it means at that moment mainline will be 24 and we don't have any plans to work on 23 at that moment unless it's really critical issue.

So it means we will continue to work only on mainline and 23 will be for stabilization.

Phil:

So the tests that Alexander fixes that are unstable are the ones that are only unstable when we run them on Wayland.

And these are, it's all about just tweaks to the tests, not about tweaks to, not about changes to the product code.

Alexey:

We're currently stabilizing the Pure Wayland branch, Pure Wayland toolkit in our fork, JetBrains runtime repository, fixing some issues to be able to release it in preview mode, not by default for the users.

There are some active community members that would like to implement something in Pure Wayland toolkit.

Maybe you've seen the recent pull request to the wakefield repository with server-side declaration.

We're also working on hardware acceleration. 

Phil:

Alexander is going to have to go off and be distracted from the pure Wakefield project focused on AWT in order to help Java FX catch up.

Because FX is going to have the same problem that we have had with the JDK.

We're not going to be able to run FX on upcoming distros unless we actually fix this.

And that will be right after the fork. I already mentioned that in two weeks.

But I, I think 95% of what it shouldn't be anything like as hard to do as what Alexander had to do for AWT.

I think it should be mostly lift the code, move it over here, drop, integrate, hook things up.

So it shouldn't be too bad. I think all the hard learning has been done.

Alexey:

We discussed the high DPI support for XWayland with Nikita.

And based on our experience, we decided not to port it to OpenJDK, because it works in some cases, but in general that approach doesn't work well.

And we have a lot of regressions and we fix them.

And we decided to fix those problems and just move forward.

Phil:

Were the issues with fractional scaling or with integer scaling as well?

Alexey:

If you have monitors with different scales, and if they are placed in a strange position in virtual space, e.g. on top of each other, it may be difficult to calculate the position of the windows, because some information is missing on the X11 side.

So it works for monitors that are placed one side of each other.

But if you put them on top of each other, it causes some problems with, for example, menus or things like that.

Nikita provided the initial solution to the open JDK alias with this fix.

We can actually provide the complete solution just to look at it and see if we can reuse it in the XWayland area. We don't have a lot of resources to work on pure Wayland.

Phil:

If you're basically saying the high DPI stuff isn't working.

Is it because of issues in, is it just a matter of working through the issues on our side?

Or is there something, is there a problem on the compositor side or is there something missing in terms of an API?

Alexey:

Yes, exactly. There's something missing in the API. We cannot get all the information to calculate location in some configuration, some display, multiple display configuration, unless we provide some additional API for XWayland sandbox.

It's less tricky in a pure Wayland mode. So we decided to just switch it.

Alexander:

Speaking of RHEL10, there will be removed Xorg session. Will it be possible to add it back somehow?

Or will it be removed completely?

Niels:

So there's a there's X11, there's the X11 session and there's Xorg.

And so X11 itself is a protocol and will be there in the form of X Wayland.

The Xorg session, that will be gone by in the default trial.

It could be that that's going to be so I think there will be people who will have an Apple package.

So Apple is the repository that people can install, but it's not supported by Red Hat.

So people will probably be able to install it, but it won't be supported.

Phil:

OK, so in other words, you can't just go to the Red Hat package repository, pick something, install it, and get Xorg back.

Niels:

No, indeed.

I recently looked into some of the Wayland protocols that are still under discussion.

So one of the things that piqued my interest was the splash screen protocol.

And one of the things I was wondering is if it makes sense to get some feedback from different people and see what they expect from a splash screen,

because that's one of the common ones. It's one of the things that we know that people are asking for.

For example, for global positioning, they want to have a splash screen that is centered somewhere in the middle of the screen, so it presents the user nicely.

So one of the things we could do is have a separate splash window, and a special protocol for splash windows.

Phil:

But the OpenJDK splash screen protocol and its API has couple of different there's some interesting there's an interesting aspect to it.
You can basically say I'm starting Java and you provide a command line option dash splash colon.
And then my pretty picture dot JPEG or GIF or whatever, or PNG.
And that will get put up by slap bang in the middle of the default screen. (Usually)
And it's done by some native code that gets up and running before the VM is even running.
So you can't there's not even anything running Java code at that point.

In the back in it just forks that off sets runs a thread to do that and then starts them.
That can theoretically be done in a very short amount of time.
And then you still have to boot up this massive thing called the VM and get it to start loading classes and stuff.
Now, once it's got up and loaded classes and all the rest of it, there's a kind of callback mechanism.
And we have splash screen APIs in the AWT.
And there can be a transition for that window to where that window is to actually transition into something where we can then start rendering into it using AWTs.
It doesn't have to be the same window. But the point is, is that for the splash screen to work for us, it's not just it can't just be a fire and forget thing.
We actually need to know where that window is and then be able to seamlessly transition to having an AWT, a normal l top level window.

They're both top level windows, but the first top level window isn't being run by AWT.

It's just a pure native block of that thing on the screen.

No event processing or anything. It's not an AWT window. It's just a native would be a native toolkit or X11 window into which we just call X put image.

Or something. And then but it transitions into this full on Java AWT window in which swing can draw or anything.

And we can put additional information as the application is then starting up.

Another question, what toolkit are you actually going to use, XToolkit or WLToolkit, before you've even run the tool, started to read,  run the code that parses the options that decides that.

We really need to know that window, the position of that splash screen, so that we can ask another window to go to the exact same position and size, not just kind of a habit fire and forget. Otherwise, this, the transition doesn't work.

Alexey:

We actually implemented the splash screen in our WL toolkit.

And there were some tricky architectural decisions to decide which window to show before anything existed, the X11 window or the Wayland window.

And yeah, I don't remember the exact logic, but it was a tricky question

Jonas:

The question was, does the splash screen image thingy share the same display connection as the AWT one, but if AWT isn't even started yet, does it need to, can it inherit the connection, or is that even possible if you don't know what kind of connection it's going to be until like after.

I guess from you there is that since it's going to be X11 or Wayland, when the splash screen shows up, it's not possible to know if it's even possible to share the connection because it's going to be X11 or Wayland.

Phil:

You ask a very good question. I would be inclined to guess. There must be a separate X connection, but I'm reasonably sure that with a bit of work that we could actually use the same connection.

It might be that we don't share the same connection, but I'm pretty sure we could.

Jonas:

 Is the splash screen always the same size as the window itself? Is that what the purpose is that it shows something?

Phil:

That's the purpose. Yes, that's exactly the purpose.

There's the splash screen that gets loaded initially, where there's, you can't do any rendering into it.

You just basically give it a GIF or a PNG and it's displayed via very lightweight native code.

So the splash screen is fast. The splash screen, the window on the screen that has the PNG in it is like supposed to be instant, like 10th of a second.

And then you got another little bit of time while the VM boots everything up. 

It could be drawing a progress bar as it basically ticks off loading all the plugins and all sorts of other things that some big application might do, making connections, reconnecting to the server.

And then, then generally that window then, most, in most applications, that window is not going to become your application window. It is just , the information we're getting going, we're getting going.

And then boom, it disappears because now your main application window is up. And that's the usual way people use it. 

JonasL

It makes me wonder what exactly is missing from having a splash screen protocol that gets you the PNG on the screen, more or less instantaneously.

Is it that you have to morph it to the next one somehow? Like you need to create an association between the splash and the next window? Or what exactly?

Phil:

I have to go off and double check our API, but to see how the transition is done. The same connection, but I don't think it's the same actual window is the point.

It's the same server connection, but it's not the same window. We just replace the window with the new one.

Alexey:

As far as I can remember, in Wayland Toolkit, we actually use the same window.

Because it's impossible to create the similar window with the same, the similar position.

Jonas:

With the splash protocol that I suspected would have to be a different window that you would.

And if there needs to be some kind of association of one knowing about the next, then that's something to take into account in how you design the protocol.

Niels:

Another question is about making a splash screen output only, which means that basically it would not be allowed to get any input.

I don't know what kind of problem that might be for you, or if that would be acceptable to people.

Phil:

The window is definitely "output only", so I think that part fits into the proposed protocol. 

Alexander

And one aspect we didn't mention, probably not an issue, is that the splash screen window should support shaped windows.

Phil:

You probably right. because any window can be a shaped window(e.g. a window that looks to you like a circle rather than a rectangle).

And generally it's done by applying a clip, essentially, between the implementation and the display server.

And there's generally some kind of transparency involved to help make it work. And for the initial image that you're displaying as a PNG, if you're displaying a JPEG, which doesn't support transparency, you can't.

But PNG and GIF could actually have transparent pixels and some clever, some very clever developer could basically craft their nice PNG, which is 500 by 500 or something.

They know exactly what part of the window is transparent and what part isn't.

And then they have to apply the same, apply a clip to create the AWT window when it comes up that matches that exactly.

Otherwise you won't have a seamless transition.

Alexander:

It should also be input transparent, not just visually transparent.

Jonas:

Something to keep in mind about the input region, maybe not relevant for splash screens, but if you have a shaped window that only wants to receive input on the shape, the representation is trivial. It's just a texture or a buffer with an alpha channel, which is supported without any problems.

The problem is that the input region is a region. This means a set of rectangles.

So if you have smooth lines, like bezier curves, that's going to be a lot of regions, a lot, a lot of rectangles. So it's very inefficient.

Phil:

The only saving grace is shaped windows are, not many people use complex shapes for, in practice for, it's it's the usual sort of thing where some nice curved, some nice curved corners or something, right.

But it's, which means that maybe the problem is not quite as bad. You don't see many real user interface applications that have a some kind of a complicated thing that looks like a Mobius strip as your, as your window or something now that's not exactly. I would say it's almost nonexistent.

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.

Maxim:

Very minor update from my side, just mostly bugfixes and small changes, people continue to use our unfinished toolkit on various Linux distros and report lots of bugs and wishes.

For example, many seem to be bothered by the mismatched title bar thing and stuff like that.

Alexey:

We have solved all performance issues with our runtime based on JDK21, so we will release JBR21 runtime based on it inside our product with 24.2 release.

It'll be bundled with Wayland support, ofc is not by default, we may have more testing within our users.

There is some unofficial testing of pure Wayland toolkit within our community. I am personally working on CLion and Idea running on top of Wayland, of course we have some issues, but it generally works.

Even in software mode it has quite good performance.

I also continue to implement hardware accelerated rendering using Vulkan, just got some basic rendering working.

Phil:

Have you guys tested the arbitrary shaped windows support?

Maxim:

Yes, the ruler example works, it is actually semi-transparent by the way.

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

...

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?

...