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

[Alexander Zvegintsev]

(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 
.


I faced this issue on Ubuntu 21.04.

However things getting better 
with 
Nvidia 470 drivers, its beta released 
 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
   
 o 
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
   

 * generating key/mouse events:
 o 
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
   


This still need more investigation, butxdg-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. 



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 .


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 

FYI: A CFD for a Wayland project has been posted to disc...@openjdk.java.net

[Philip Race]

https://mail.openjdk.java.net/pipermail/discuss/2021-July/005846.html

-phil.

Re: RFR: 8267385: Create NSAccessibilityElement implementation for JavaComponentAccessibility [v2]

[Pankaj Bansal]

On Tue, 29 Jun 2021 15:00:41 GMT, Artem Semenov 
 wrote:

>> src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m 
>> line 372:
>> 
>>> 370: if ([javaRole isEqualToString:@"pagetablist"]) {
>>> 371: newChild = [TabGroupLegacyAccessibility alloc];
>>> 372: } else if ([javaRole isEqualToString:@"table"]) {
>> 
>> Do we even need legacy peer implementation in the new classes?
>
> The new TabGroup is also named TabGroupAccessibility, so as not to get out of 
> the naming, the old class is renamed for this, otherwise the building will 
> fail.

But when are these Legacy classes used? The "pagetablist" and "table" roles are 
being handled in commonComponentAccessibility and new implementation classes 
will be used there. Why can't we just remove these legacy classes and any 
references to them, instead of renaming them

-

PR: https://git.openjdk.java.net/jdk/pull/4412

Re: [jdk17] RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL [v5]

[Ajit Ghaisas]

On Mon, 5 Jul 2021 15:55:20 GMT, Alexey Ushakov  wrote:

>> Implemented blit via compute kernel
>
> Alexey Ushakov has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
>   
>   Minor cleanup

I verified that the latest version does not re-introduce JDK-8243547.
All automated test run is also green with this version.

-

PR: https://git.openjdk.java.net/jdk17/pull/62