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

...