<AWT Dev> Call for Discussion : New Project to support the Wayland display server on Linux

Fri Jul 9 10:17:32 UTC 2021

> On 8 Jul 2021, at 19:11, Mario Torre <neugens at redhat.com> wrote:
> 
> [resending with hopefully the correct email address as I have
> completely lost which mailing list I'm subscribed to with which
> email!!!]
> 
> 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.

I’m not sure, that it’s right direction. We had a similar situation in early days of java. We had a Motif toolkit that was then replaced by XAWT implementation. I think in long term we need to be as close to low level interfaces as possible. We (JetBrains) have a lot of users on different desktops and having only GTK is not an option for us. So, I think that we need to have something like XAWT for Wayland.

Best Regards,
Alexey

> 
> 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 Wed, Jul 7, 2021 at 11:56 PM Alexander Zvegintsev
> <alexander.zvegintsev at oracle.com <mailto: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 <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 <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 <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>
>>        <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>
>>        <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 <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 <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>
>>        <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>
>>        <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 <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 <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 <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
> Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com <https://www.redhat.com/>>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/awt-dev/attachments/20210709/98121ae9/attachment-0001.htm>