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 December 5  2024

Attendees: Jonas Ådahl, Olivier Fourdan, Alexey Ushakov, Harshitha Onkar, Phil Race, Kevin Rushforth, Victor D'yakov, Alexander Zvegintsev

Alexander:

Fixed a couple of JavaFX/Swing interop issues related to our screencast usage for receiving screen data:

1. hang when FX is running, it internally runs the gtk main loop, which wasn't accounted for on the JDK side.
So now it handles 3 cases:
    * When there is no GTK main loop running
    * If there is a GTK main loop running, but we are not requesting pixels on its thread
    * If there is a GTK main loop running and we request pixels on its thread

2. crash,
Internally the ScreenCast session keeps open for 2s (both JDK and JFX, and their implementations are almost identical).
When we perform a cleanup to close the session, we internally called pw_deinit before the fix.
It becomes a problem if these sessions overlap in time, so that the second session cleanup crashes when it tries to call pipewire functions without initializing the pipewire system by pw_init

Working on JDK side fix of the emulated resolution change does not come issue.
The system side fix has landed on the Ubuntu 22.04 only partially, as it doesn't receive configure notification for change back to the native resolution(other works), but it 24.04 it works with native application as it has both fixes..
It still needs changes on the JDK side.

And there are a few more issues to fix.
The ones that were already discussed before like HiDPI support. It was decided that it's hard to implement for x11 compatibility mode. didn't dig into it, so I'll take a look at it later.
There is another issue with drag and drop when we do a drag and drop within a single window when the CTRL key is pressed. I haven't managed to make a native renderer for this yet.

Alexey:

Regarding high DPI support, I would suggest to discuss it with Nikita Gubarkov via email.
Because he spent a lot of time trying to support high DPI in Xwayland and got some basic limitations.
So he even implemented some logic and we tried to make it work in production.
But we found some really hard corner cases and were not able to fix them.

Alexander:

I seem to recall that it had something to do with multiscreen.
So probably we can implement this support at least for a single screen.

Jonas:

For Gnome 47 or Fedora 41, I've implemented support for what we call native scaling for XWayland(for mutter).
It's more or less similar to how one of the KDE HiDPI X11 modes works where we tell XWayland to draw bigger.
And then we tell X11 clients to draw bigger than our logical monitor layout in the compositor.
And then we take each window from the X server and scale it down to the same scale that we told XWayland to scale itself up to.
This works well for all X11 applications.
We have applications that use what we could call traditional X11 high DPI, where the Xserver has a global scale and windows, all different windows in the application try to follow that scale.
But when I was running this with Intellij, it was using X11, but if you had access to a Wayland connection, it dynamically adjusted its scale to whatever monitor you were using.
It was according to the WL output and that caused problems because whatever it was on a low DPI monitor, there was no way for the compositor to know that it wasn't large anymore, and it got very, very tiny.
Is there a way to detect this kind or disable this from a window manager or Wayland compositor direction so that this doesn't happen if you run Intellij?

Alexey:

I suppose that we're going to revert this logic in the future versions of EDA so it shouldn't be a case anymore.
But it's interesting. Do you have some links to read about this feature of XWayland? So maybe we can find out the way how we can use it.

Jonas:

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3567#note_2159205

Alexey:

Yes, we have been collecting feedback from our users with the Vulkan rendering preview and we have found some issues with different environments.
Some users are trying to run Vulkan with hardware accelerated WSL2 and we actually looked into it and it didn't work, but we found out why.
That kind of acceleration is not fully supported by the drivers that they a have implemented.
And in particular, it was an unimportant feature, the XOR mode.
So probably if we make the XOR mode optional, we'll be able to run on WSL with hardware acceleration as well.
There were also some issues with the NVIDIA hardware.
We are currently working on all of those issues that we got from our users.
And we're also currently implementing the feature that helps us test Vulkan.
In the Wayland software mode, we have implemented some of the PixelGrabber functionality for a window.
We go directly to the surface of the window and grab the color from there.
So we are able to test at least one window application without the help of the operating system.
And right now we've almost implemented the approach to grab pixels from Vulkan windows.
And I think we'll have an update next week.
And also Maxim fixed some corner cases in Wayland software mode.
Connected with some dialogues and context menus with the multiple monitors.

Online Zoom Meeting 9am PDT November 8  2024

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

Alexander:

ImageDecoratedDnD.java  now fails on Gnome 47 (Ubuntu 24.10), DnD is aborted when trying to run it with CTRL pressed.

It looks like a non-java issue, as it doesn't reproduce at all when mouse and keyboard interactions are done via XTest(java.awt.Robot)

The issue is reproducible when an actual user performs mouse and keyboard actions with physical devices (which didn't happen before), sometimes it passes though(maybe 1 out of 20 attempts).

Now I am trying to make a native reproducer for it. 

Alexey:

Yes, it actually took longer than we expected.

In Vulkan we have validation layers and despite the fact that it works visually we had a certain amount of validation errors in the pipeline because of some mis-synchronization and things like that and we actually fixed all the validation issues.

They're actually enabled in the fast debug build and you also need to have validation layers installed in the system to make them work. 

We are even sending out some preliminary builds to our users and have gotten some good feedback from them recently.

The Vulkan support provides the list of the hardware devices(if you enable it with the True with capital)

We've got a list of hardware devices that our users are using, some people are using m1 macbooks with Asahi Linux installed, and Vulkan has been working on hardware accelerated drivers for that Linux.

So currently we are putting all the changes we have made in our JBR into the separate branch that Maxim recently updated, which is a jdk21.0.1-wayland.

Obviously it's not as performant now, but we're working on the primitives.

And the ultimate goal is to use an accelerated image for rendering after all the primitives are done.

In the future we will work on the renderer.

Actually, one of our engineers is working on enabling Vulkan on X11. So it looks like it's a fairly simple change, but it's quite tricky. So maybe in this case we will have Vulkan in both pipelines.

Maxim:

One issue wasn't just a bug fix.

It sort of pointed out to me a potential incompatibility between Java and Wayland: Wayland requires proof of user involvement (like serial numbers from user events) for actions like clipboard access.

The protocol, however, doesn’t specify which events are accepted, nor does it provide feedback, leaving developers to experiment and guess.

After extensive testing with various Wayland implementations, I found a solution that works for now.

This is extremely fragile and any other Wayland implementation that does things differently will kill the Java assumption and things will start to break.

We also got rid of the generated code in our development branch, it is now generated on the fly during the build.

You only need to install one extra package, wayland-protocols, which is not hard at all, except for a gGnome-only protocol, which should be brought by hand, as I don't know where to get it on any distribution. I made it optional as it is not essential, it just makes the dialogs work better and more gnome-like.

Jonas:

We recently upstreamed the xdg_dialog protocol, and it has set_modal.

And regarding the clipboard and  the ambiguity of what kind of serial input events are respected and all that, I suggest opening an issue in the Wayland repository issue tracker to see if it can be clarified. At least to know which parts are expected and which are implementation specific.

Online Zoom Meeting 9am PDT October 10  2024

Attendees: Olivier Fourdan,  Alexey Ushakov, Phil Race, Kevin Rushforth, Maxim Kartashev, Victor D'yakov, Alexander Zvegintsev

Alexey:

We have some achievements from the Vulkan implementation.

We finally implemented blit support, for blits, which is necessary to actually present content on the screen.

So currently we actually have a software rendering mode presented via Vulkan.

It's even possible to run our IDEs, for example Idea, in this mode.

We have like in a metal texture pool and able to render used textures as a back buffer in Vulkan and present them on the screen.

We also implemented some primitives in pure rendering mode, but they do not work now because currently we have volatile image as a buffered image.

Now we still have rendering in software mode presented via Vulkan.

We've now implemented high DPI support for this mode, so it's possible to use this hybrid rendering mode with different scale factors.

We're going to be polishing these changes and maybe early next week we'll get them into the Wakefield repository.

From a performance point of view it doesn't make sense, because this hybrid mode is slower than even the pure software rendering mode in wayland.

It's a pretty good step from an implementation point of view, because now we can test our texture pool and drag application windows from screen to screen with a different DPI and see how it reacts and rebuild the texture buffers and stuff like that.

We continue to implement primitives to finally use a real hardware accelerated volatile image as a backbuffer.

Phil:

What platforms are you testing on? Is everything equally stable on the Vulkan pipeline?

Alexey:

Currently it only works for Linux and Wayland. We have discussed other platforms, it is quite easy to extend this support to Windows and X11, it is an isolated part of the pipeline.

Phil:

What kind of hardware are you testing on? Raw, VirtualBox or something like that as well?

Alexey:

We tried it mostly on AMD hardware. So we tried desktop cards and mobile cards.

Unfortunately NVIDIA is very unstable for Wayland.

By the way, Vulkan has its own software rendering pipeline inside, you can actually run Vulkan pipeline in software rendering mode.

We've implemented the ability to switch between the different cards and the software rendering pipeline via the VM property.

You can get the list of devices that you have in the system, you can run on that particular device in the next run and run on that particular device.

Online Zoom Meeting 9am PDT September 12  2024

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

...