Call for Discussion : New Project to support the Wayland display server on Linux

Thu Jul 8 16:07:10 UTC 2021

I tend to agree with this, we certainly need to identify the underlying APIs that are problematic (screenshot and mouse/keyboard control as far as I am aware), then see what we can do from there, and I would like to first address the XWayland use case before turning into a fully fledged new toolkit implementation (but I agree with Phil that this is the long term necessity).

What I would like to do however is to see if it makes sense to create a GTK toolkit rather than a Wayland one, and let GTK deal with every abstraction. We can be pretty confident that GTK will always be there, and will work on X11 and Wayland transparently, so even a user on a pure KDE desktop won’t really need to deal directly with Wayland.

Ideally, users with pure KDE distributions (OpenSuSE maybe?) may help here analyse what the requirements are. One problem that comes to mind when using GTK as a toolkit is the interaction with other GTK based applications that may be embedded, i.e. Swing views in Eclipse, Firefox based web views, etc.. etc… But I think this is already today an issue and is dealt with in the current 2d and JFX code already.

Cheers,
Mario

> On 7. Jul 2021, at 23:52, Alexander Zvegintsev <alexander.zvegintsev at oracle.com> wrote:
> 
> (adding awt-dev)
> 
> Let me add a few comments.
> 
>> already Wayland is the default on RHEL 8, OL 8, Ubuntu 21.04 and I am sure others too.
> It is the default, but not in every case. Wayland may be turned off deliberately if you are using a Nvidia graphics card, so you need to take extra steps to get it working <https://askubuntu.com/questions/1334825/what-are-the-steps-to-run-wayland-on-21-04-with-optimus-nvidia>.
> 
> I faced this issue on Ubuntu 21.04.
> 
> However things getting better <https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-470-Wayland-Friendly>with Nvidia 470 drivers, its beta released <https://www.nvidia.com/download/driverResults.aspx/176525/en-us> on 2021.6.22. So probably it won't be a problem in the near future.
> 
>> Consequently we expect quite shortly to propose an OpenJDK project that will consider the goals of
>> - a short to medium term solution for JDK running on Wayland in X11 compatibility mode
>> - a medium to long term solution for JDK running as a native Wayland client.
> 
> Both goals having a common task: we will need to implement java.awt.Robot functionality for Wayland(at least).
> 
> So it makes sense to make XToolkit's java.awt.Robot work under Wayland first, and then reuse this code for native Wayland client.
> 
> I see two major tasks here: taking screenshots and mouse/keyboard control. As far as I know there is no standard way to implement they across all display servers yet.
> 
> Possible ways to implement this:
> 
> * taking screenshot:
>     o open issue against Wayland, may be resolved
>       someday:https://gitlab.freedesktop.org/wayland/wayland/-/issues/32
>       <https://gitlab.freedesktop.org/wayland/wayland/-/issues/32>
>     o https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.Screenshot
>       <https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.Screenshot>
>     o via DBUS interface(display server dependent),
>       e.g.https://github.com/flameshot-org/flameshot/blob/master/src/utils/screengrabber.cpp#L43
>       <https://github.com/flameshot-org/flameshot/blob/master/src/utils/screengrabber.cpp#L43>
> * generating key/mouse events:
>     o https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.impl.portal.RemoteDesktop
>       <https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.impl.portal.RemoteDesktop>
>     o generating new virtual input device, uinput, superuser
>       privileges required, looks too flaky
>       https://unix.stackexchange.com/questions/422698/how-to-set-absolute-mouse-cursor-position-in-wayland-without-using-mouse
>       <https://unix.stackexchange.com/questions/422698/how-to-set-absolute-mouse-cursor-position-in-wayland-without-using-mouse>
> 
> This still need more investigation, butxdg-desktop-portal <https://github.com/flatpak/xdg-desktop-portal>looks more preferable way for now.
> 
> 
> Please see below some caveats for OpenJDK native Wayland client:
> 
> You can't control a position for a top-level window. <https://gitlab.freedesktop.org/wayland/wayland/-/issues/183>
> 
> This will also affect a splashscreen windows. It is still possible to control position under XWayland though.
> 
> Looks like we will just accept it.
> 
> 
> Top-level window decorations.
> 
> Initially Wayland had only client-side decorations(you have to draw it by yourself).
> 
> As of now server-side decorations are available by XDG-Decoration protocol <https://gitlab.gnome.org/GNOME/mutter/-/issues/217>.
> 
> However server-side window decorations are not mandatory and not all compositors are supporting it, e.g. Mutter(Gnome Shell's compositor).
> 
> Gnome Shell is the default on Ubuntu, so we will need to provide window decorations somehow. One of possible solutions is to use Gtk to create a window for us.
> 
> 
> --
> Thanks,
> Alexander.
> 
> On 7/7/21 6:24 AM, Philip Race wrote:
>> 
>> For a number of years the Linux community has been working on a complete replacement for the 1980's era X11 desktop display server protocol
>> with new protocols and libraries that support client-side rendering and a compositing desktop windowing system.
>> This work is being done under the auspices of the Wayland project [1] and there is a reference
>> implementation of a Wayland compositor called "Weston".
>> 
>> A new client written for  the Wayland desktop has no dependency at all on X11, but Wayland also provides a compatibility
>> mode where the X.org X11 server runs along side Wayland, so that thousands of X11 applications can continue to run.
>> 
>> Presently all distros that ship the Wayland server, also still ship the pure X11 server and the user can select
>> which one to use on the login screen. However there will come a time when Wayland is the only choice and
>> already Wayland is the default on RHEL 8, OL 8, Ubuntu 21.04 and I am sure others too.
>> 
>> At that time Java for Linux will "mostly" run via the X11 compatibility layer, but would not pass the JCK,
>> since some important APIs,  notably those of the java.awt.Robot class [2] will fail with Wayland.
>> We need to solve this so that pure Java and applications which mix Java and X11 APis can work.
>> 
>> But even then this would mean Java on Linux is not a first class desktop citizen, which is not desirable for
>> the long term, given the importance of Linux to many Java developers as well as to active
>> individual and corporate contributors to the JDK project.
>> 
>> Indeed there have already been informal discussions for some time with various parties that have expressed
>> interest in helping towards the outcome of supporting Wayland
>> 
>> Consequently we expect quite shortly to propose an OpenJDK project that will consider the goals of
>> - a short to medium term solution for JDK running on Wayland in X11 compatibility mode
>> - a medium to long term solution for JDK running as a native Wayland client.
>> 
>> There are some unknowns and questions, such as what are the options for supporting Robot ?
>> What other support is missing ? What platform APIs should the implementation  use ?
>> How does a native Wayland solution interoperate with OpenJFX ?
>> 
>> 
>> Comments, expressions of interest etc are welcome.
>> 
>> 
>> -Phil Race, for the Java client groups.
>> 
>> 
>> [1] : https://wayland.freedesktop.org/
>> [2] : https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/Robot.html
> 

—
Mario Torre
Java Champion and OpenJDK contributor

PGP Key: 0BAB254E
Fingerprint: AB1C 7C6F 7181 895F E581  93A9 C6B8 A242 0BAB 254E

Twitter: @neugens
Web: https://www.mario-torre.eu/
Music: https://mario-torre.bandcamp.com/