From maxim.kartashev at jetbrains.com Tue Nov 1 15:21:58 2022 From: maxim.kartashev at jetbrains.com (Maxim Kartashev) Date: Tue, 1 Nov 2022 18:21:58 +0300 Subject: frame callback Message-ID: These are a few questions mainly directed to Wayland developers. I greatly appreciate any insight into how Wayland is supposed to work. 1. The wl_surface.frame request gives you a hint as to when it is best to supply Wayland with new content for a surface. I wonder if it has any use in the GUI environment? I implemented redrawing such that this callback is used, but now re-implemented it without this callback as it seems to only complicate things without any benefit. On the other hand, Gnome apps seem to be using it (gedit is one example), so I wonder if I am missing something and the callback is actually there to drive the re-drawing cycle, for example? 2. xdg_surface.ack_configure. What does this ack_configure actually mean for the server in these scenarios of a window resize operation: suppose there was toplevel.configure for size 100x100 and then 2.1 we ack_configure'd it, but then committed the surface with a new 200x200 buffer. 2.2 or we did not send ack_configure for this serial at all and committed the surface with the same buffer as previously (no change in size). Should we expect another toplevel.configure for the new size in each case following the "unexpected" surface commit? Does the protocol necessitate another toplevel.configure in either case? 3. Initial xdg_toplevel.configure. Does the protocol require the server to send the initial toplevel.configure with the size 0x0 after the creation of that xdg_toplevel? It doesn't seem to say so in the protocol's xml files, but *not* waiting for that configure event and attaching a buffer to a surface prior to sending any xdg_surface.ack_configure seem to contradict the protocol ("the client must make an ack_configure request sometime before the commit"). -------------- next part -------------- An HTML attachment was scrubbed... URL: From jadahl at redhat.com Wed Nov 2 16:07:15 2022 From: jadahl at redhat.com (Jonas =?iso-8859-1?Q?=C5dahl?=) Date: Wed, 2 Nov 2022 17:07:15 +0100 Subject: frame callback In-Reply-To: References: Message-ID: On Tue, Nov 01, 2022 at 06:21:58PM +0300, Maxim Kartashev wrote: > These are a few questions mainly directed to Wayland developers. I greatly > appreciate any insight into how Wayland is supposed to work. > > 1. The wl_surface.frame request gives you a hint as to when it is best to > supply Wayland with new content for a surface. I wonder if it has any use > in the GUI environment? I implemented redrawing such that this callback is > used, but now re-implemented it without this callback as it seems to only > complicate things without any benefit. On the other hand, Gnome apps seem > to be using it (gedit is one example), so I wonder if I am missing > something and the callback is actually there to drive the re-drawing cycle, > for example? The wl_surface.frame callback is there to allow GUI toolkits and applications to draw in a way that they don't draw unnecessarily often. It's especially useful if you ever do animations, as the frame callback will roughly be synchronized to frame clock of the monitor the surface is on. This means that if you tie your paint loop to the frame callback, and the surface is on a 144 Hz monitor, you'll draw your animation at 144 Hz, but if the surface is moved to a 60 Hz monitor, you'll automatically start animating at 60 Hz. Right now, wl_surface.frame is also how EGL implements eglSwapInterval(1). If you don't have any animations, and e.g. only redraw in response to e.g. mouse movements or updates coming from the application, it's still useful to postpone any drawing until a frame callback, as it means you don't draw a bunch of frames that will never ever reach the users eyes. Lets say for example you move around an icon under the mouse cursor; if the mouse device sends you 120 motion events every second, but your monitor only redraws 60 times a second, if you redraw for every pointer motion event, half your frames will be wasted. So in general, it's recommended to throttle your redrawing using wl_surface.frame. There are also other similar Wayland protocol extensions, such as the presentation time protocol[1], that can be useful when dealing with frame timings. > > 2. xdg_surface.ack_configure. What does this ack_configure actually mean > for the server in these scenarios of a window resize operation: suppose > there was toplevel.configure for size 100x100 and then > 2.1 we ack_configure'd it, but then committed the surface with a new > 200x200 buffer. > 2.2 or we did not send ack_configure for this serial at all and committed > the surface with the same buffer as previously (no change in size). > Should we expect another toplevel.configure for the new size in each case > following the "unexpected" surface commit? Does the protocol necessitate > another toplevel.configure in either case? There are in general three ways to resize a surface in Wayland. In two of these, 'configure' and 'ack_configure' play a role, while in the third, it does not. Let me go through them one by one, but first clarify how 'xdg_surface.configure' and 'xdg_toplevel.configure' relate to each other. The xdg_toplevel interface is an "extension" to the xdg_surface interface. The xdg-shell protocol extension defines a "configure sequence" to be a sequence of events that the client should act on as a whole, meaning each event builds up a pending configuration. A configure sequence always concludes with 'xdg_surface.configure'. 1. Interactive resize Interactive resize is when a user e.g. drags a corner or a side of the window, and the window resizes in response to this. This is usually triggered by the application or toolkit calling 'xdg_toplevel.resize' with a serial coming from an input event such as pointer button down. In response to this, the compositor will start to send 'xdg_toplevel.configure' with the size and 'xdg_surface.configure' with a serial. What the application should respond with is a committed surface state with 'xdg_surface.ack_configure' with the serial from the configure event, containing a surface sized so that it doesn't exceed the dimensions sent in the xdg_toplevel.configure event. By looking at the serial event of the ack_configure request, the compositor can match the newly committed state with the configure event it sent, and for example know whether it should treat the resize as part of the interactive resize, or if it was something else. If you get a configure event with 100x100, ack it and create a 200x200 sized surface, the end result is that your client will behave badly during the interactive resize. If you at first do not ack the configure event, and commit a 200x200 surface, the compositor will treat it as a sporadic resize unrelated to the interactive resize. This is a race condition that all compositors must handle, no matter if the client did it on purpose or not, but in the end, a client is required to ack_configure a configure event, and if the client intends to behave correctly, it must follow the specification, and in the interactive resize case, that means to clamp the size to the configured dimension. Regarding expecting another configure event after not ack:ing but still committing - no, you cannot assume you'll get another configure event. >From the compositors point of view, the resize that was committed before an eventual ack_configure will be treated as a sporadic resize, unrelated to the interactive resize. 2. Resize in response to state changes State changes include maximizing, unmaximizing, fullscreening, unfullscreening, switching between being maximized on one monitor being moved to another. When this happens, the compositor will send a configure sequence (xdg_toplevel.configure + xdg_surface.configure) with relevant state, and the client should respond by ack:ing the configure event while providing a new surface state according to the new configuration. 3. Sporadic resizes An application can resize itself sporadically. An example for this is clicking an expandable that causes the window size to grow. In this case, there is no configure event nor any ack_configure request involved, but only a matter of the application committing a state containing a larger buffer, and a larger window geometry. Since sporadic resizes in theory can happen any time, compositors must handle race conditions where they happen e.g. immediately before an interactive resize. > > 3. Initial xdg_toplevel.configure. > Does the protocol require the server to send the initial toplevel.configure > with the size 0x0 after the creation of that xdg_toplevel? It doesn't seem > to say so in the protocol's xml files, but *not* waiting for that configure > event and attaching a buffer to a surface prior to sending any > xdg_surface.ack_configure seem to contradict the protocol ("the client must > make an ack_configure request sometime before the commit"). The compositor must send an initial configure after the client commits an initial "empty" state, with empty meaning that it haven't yet attached a buffer. You can read about it here[2]. After a client received the initial configure, it should ack_configure it, attach a buffer according to configured state and size, and lastly commit the surface. The reason why a client must always wait for the initial configure event before committing its initial state is so that the compositor can tell the client how it should draw the first frame - for example if it should be maximized, tiled, fullscreen, focused, etc. Thus, it will not necessarily send the size 0x0; if the first frame the client should draw is maximized, the configured size will be one that makes the surface fit the whole work area. The mentioned contradiction is not a contradiction. Most wl_surface and related role state is double buffered, meaning it is not applied until wl_surface.commit. What "make an ack_configure request sometime before the commit" means in this case is that the ack_configure request is sent before wl_surface.commit, so that it will be part of the atomically applied state. Let me draw up how it will appear to the compositor and client: /- wl_compositor.create_surface(new wl_surface at 1) | xdg_wm_base.get_xdg_surface(new xdg_surface at 2, wl_surface at 1) | xdg_surface.get_toplevel(new xdg_toplevel at 3, xdg_surface at 2) | xdg_toplevel at 3.set_maximized() // configure toplevel \-> wl_surface at 1.commit() // apply initial empty state atomically This whole sequence to the compositor is a single atomic operation where the client creates a new toplevel where the client whishes to be mapped as maximized. In response to this the compositor may respond with /- xdg_toplevel at 3.configure(1920, 1030, maximized|activated) \-> xdg_surface at 2.configure(123) The client should treat these two events atomically, concluded by the xdg_surface.configure event, as an intent, where the client is told to paint itself as maximized and focused (activated). In response to this, the client responds to the configuration with /- xdg_surface at 2.ack_configure(123) | wl_surface at 1.attach(buffer_with_size_1920_1030) | wl_surface at 1.set_input_region(..) | wl_surface at 1.damage(1920, 1030) | xdg_surface at 2.set_window_geometry(0, 0, 1920, 1030) \-> wl_surface at 1.commit() The compositor will interpret this as an atomically committed state that contains the following changes to be applied together: * This was a commit that was done in response to a configure event with serial 123 * A new buffer sized 1920x1030 was attached * The whole surface content changed (damage was 1920x1030) * The window geometry was set to 1920x1030 at 0,0 Some things to keep in mind: * When attaching a buffer which changes the size of the window, it is important to call xdg_surface.set_window_geometry() as part of the same commit sequence, as otherwise the compositor will clamp the effective window geometry. * Some xdg_toplevel states mandate that the client always respects the configured size. These include 'maximized' and 'tiled'. For fullscreen, what instead is mandated is that the committed size must match the size, or be smaller. * It is not allowed to commit a non-empty (attach buffer) state before the initial configure event from the compositor. * Always think of configure sequences and state committed to a surface as atomically applied transactions, and not a sequence of individual commands. I hope this helps. Let me know if I should expand on any other area, or explain more why things are the way they are. Jonas [1] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/stable/presentation-time/presentation-time.xml [2] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/8d79352851199eeb4fe1ad7644c06502c1cb518f/stable/xdg-shell/xdg-shell.xml#L431-434 From duke at openjdk.org Tue Nov 8 07:26:17 2022 From: duke at openjdk.org (duke) Date: Tue, 8 Nov 2022 07:26:17 GMT Subject: git: openjdk/wakefield: pure_wl_toolkit: 5 new changesets Message-ID: <7317900d-37ba-491d-91d4-f7ce1e2aefc7@openjdk.org> Changeset: 3bdd2418 Author: Maxim Kartashev Date: 2022-10-18 12:28:09 +0000 URL: https://git.openjdk.org/wakefield/commit/3bdd24180b2a891194fdaac2b1aac766a6f2a07c Support more xdg-shell functions and buffer management bugfixes Implemented maximize/fullscreen together with the reverse functions. ! src/java.desktop/unix/classes/sun/awt/wl/WLComponentPeer.java ! src/java.desktop/unix/classes/sun/awt/wl/WLFramePeer.java ! src/java.desktop/unix/classes/sun/awt/wl/WLGraphicsDevice.java ! src/java.desktop/unix/classes/sun/java2d/wl/WLSurfaceData.java ! src/java.desktop/unix/native/common/java2d/wl/WLBuffers.c ! src/java.desktop/unix/native/common/java2d/wl/WLBuffers.h ! src/java.desktop/unix/native/common/java2d/wl/WLSurfaceData.c ! src/java.desktop/unix/native/libawt_wlawt/WLComponentPeer.c ! src/java.desktop/unix/native/libawt_wlawt/WLToolkit.c Changeset: 5d869890 Author: Dmitry Batrak Committer: Maxim Kartashev Date: 2022-10-21 12:05:01 +0000 URL: https://git.openjdk.org/wakefield/commit/5d86989059ade80bea31ef9a541b952bdb8df2c7 make default component focused on frame activation ! src/java.desktop/unix/classes/sun/awt/wl/WLComponentPeer.java Changeset: 3f89a76c Author: Dmitry Batrak Committer: Maxim Kartashev Date: 2022-10-18 18:17:21 +0000 URL: https://git.openjdk.org/wakefield/commit/3f89a76c8e4b75e6c173cf87625e92ec91ab47a8 client-side decorations, and some fixes for minimize/maximize window functionality ! src/java.desktop/unix/classes/sun/awt/wl/WLComponentPeer.java + src/java.desktop/unix/classes/sun/awt/wl/WLFrameDecoration.java ! src/java.desktop/unix/classes/sun/awt/wl/WLFramePeer.java ! src/java.desktop/unix/classes/sun/awt/wl/WLToolkit.java ! src/java.desktop/unix/classes/sun/java2d/wl/WLSurfaceData.java ! src/java.desktop/unix/native/libawt_wlawt/WLComponentPeer.c ! src/java.desktop/unix/native/libawt_wlawt/WLToolkit.c ! src/java.desktop/unix/native/libawt_wlawt/WLToolkit.h Changeset: a4bfa406 Author: Dmitry Batrak Committer: Maxim Kartashev Date: 2022-10-31 12:15:44 +0000 URL: https://git.openjdk.org/wakefield/commit/a4bfa40652dc0820e7e9e22340a1a143a2bdd707 Support setting state to a window before making it visible, and right afterwards Also fix assertion in WLKeyboardFocusManagerPeer, initialize memory allocated for WLFrame just in case to prevent potential usage of uninitialized fields in future. ! src/java.desktop/unix/classes/sun/awt/wl/WLComponentPeer.java ! src/java.desktop/unix/classes/sun/awt/wl/WLFramePeer.java ! src/java.desktop/unix/classes/sun/awt/wl/WLKeyboardFocusManagerPeer.java ! src/java.desktop/unix/native/libawt_wlawt/WLComponentPeer.c Changeset: 5adc5fb1 Author: Maxim Kartashev Date: 2022-10-31 17:24:52 +0000 URL: https://git.openjdk.org/wakefield/commit/5adc5fb180ab368b7d0ca941d9a2c42e1c0ee0eb More bugfixes in Wayland buffers management Event-driven painting of client decorations. Smooth window resize. Transactional commits at AWT and Swing level based on frame numbers. ! src/java.desktop/share/classes/java/awt/Window.java ! src/java.desktop/share/classes/javax/swing/RepaintManager.java ! src/java.desktop/share/classes/sun/awt/AWTAccessor.java ! src/java.desktop/unix/classes/sun/awt/wl/WLComponentPeer.java ! src/java.desktop/unix/classes/sun/awt/wl/WLFrameDecoration.java ! src/java.desktop/unix/classes/sun/awt/wl/WLFramePeer.java ! src/java.desktop/unix/classes/sun/awt/wl/WLGraphicsConfig.java ! src/java.desktop/unix/classes/sun/awt/wl/WLRepaintArea.java ! src/java.desktop/unix/classes/sun/awt/wl/WLToolkit.java ! src/java.desktop/unix/native/common/java2d/wl/WLBuffers.c ! src/java.desktop/unix/native/common/java2d/wl/WLSurfaceData.c ! src/java.desktop/unix/native/libawt_wlawt/WLComponentPeer.c From maxim.kartashev at jetbrains.com Tue Nov 8 07:38:19 2022 From: maxim.kartashev at jetbrains.com (Maxim Kartashev) Date: Tue, 8 Nov 2022 10:38:19 +0300 Subject: CSD, interactive resize, and more updates Message-ID: A new set of commits made their way to https://github.com/openjdk/wakefield/tree/pure_wl_toolkit/ including * Client-side decorations, * Interactive window resize, * Maximize/minimize/fullscreen, restricting min/max window size, * Stricter Wayland protocol wrt size change and the initial window appearance. There are some known (and, I'm sure, plenty of unknown) issues and glitches there. One example is the lack of custom mouse cursor images, so positioning the mouse to start resizing is tricky as there is no visual hint yet. Another is jaggy window behaviour when resizing to the left (i.e. when the position changes together with the size). -------------- next part -------------- An HTML attachment was scrubbed... URL: From maxim.kartashev at jetbrains.com Thu Nov 10 17:03:32 2022 From: maxim.kartashev at jetbrains.com (Maxim Kartashev) Date: Thu, 10 Nov 2022 20:03:32 +0300 Subject: Wayland: destroyed objects and events Message-ID: I was wondering if there's a good way of dealing with events that come from objects that are being concurrently destroyed. The scenario is as follows: let's say a callback is created like so wl_frame_callback = wl_surface_frame(wl_surface); payload = malloc(...); wl_callback_add_listener(wl_frame_callback, &wl_frame_callback_listener, payload); and soon after that there's wl_surface_destroy(wl_surface); free(payload); It seems like if the frame event has already been "scheduled" to be fired at the point of wl_surface_destroy(), it might be actually delivered and the callback defined by wl_frame_callback_listener will get invoked with "payload" being free'ed already. Is there a good way to make sure wl_frame_callback will never fire past the point of wl_surface_destroy()? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ofourdan at redhat.com Thu Nov 10 17:18:10 2022 From: ofourdan at redhat.com (Olivier Fourdan) Date: Thu, 10 Nov 2022 18:18:10 +0100 Subject: Wayland: destroyed objects and events In-Reply-To: References: Message-ID: Hi Maxim On Thu, Nov 10, 2022 at 6:05 PM Maxim Kartashev wrote: > > I was wondering if there's a good way of dealing with events that come from objects that are being concurrently destroyed. The scenario is as follows: > let's say a callback is created like so > wl_frame_callback = wl_surface_frame(wl_surface); > payload = malloc(...); > wl_callback_add_listener(wl_frame_callback, &wl_frame_callback_listener, payload); > and soon after that there's > wl_surface_destroy(wl_surface); > free(payload); > It seems like if the frame event has already been "scheduled" to be fired at the point of wl_surface_destroy(), it might be actually delivered and the callback defined by wl_frame_callback_listener will get invoked with "payload" being free'ed already. > Is there a good way to make sure wl_frame_callback will never fire past the point of wl_surface_destroy()? I guess you could destroy the callback with wl_callback_destroy() so it won't fire up again? HTH Cheers Olivier From maxim.kartashev at jetbrains.com Thu Nov 10 17:23:57 2022 From: maxim.kartashev at jetbrains.com (Maxim Kartashev) Date: Thu, 10 Nov 2022 20:23:57 +0300 Subject: Wayland: destroyed objects and events In-Reply-To: References: Message-ID: > > I guess you could destroy the callback with wl_callback_destroy() so > it won't fire up again? Would that stop the callback from firing, considering that wl_callback_destroy() request might be received by the server _after_ an event has already been scheduled? The asynchronous nature of the protocol leaves me guessing sometimes. On Thu, Nov 10, 2022 at 8:18 PM Olivier Fourdan wrote: > Hi Maxim > > On Thu, Nov 10, 2022 at 6:05 PM Maxim Kartashev > wrote: > > > > I was wondering if there's a good way of dealing with events that come > from objects that are being concurrently destroyed. The scenario is as > follows: > > let's say a callback is created like so > > wl_frame_callback = wl_surface_frame(wl_surface); > > payload = malloc(...); > > wl_callback_add_listener(wl_frame_callback, > &wl_frame_callback_listener, payload); > > and soon after that there's > > wl_surface_destroy(wl_surface); > > free(payload); > > It seems like if the frame event has already been "scheduled" to be > fired at the point of wl_surface_destroy(), it might be actually delivered > and the callback defined by wl_frame_callback_listener will get invoked > with "payload" being free'ed already. > > Is there a good way to make sure wl_frame_callback will never fire past > the point of wl_surface_destroy()? > > I guess you could destroy the callback with wl_callback_destroy() so > it won't fire up again? > > HTH > Cheers > Olivier > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ofourdan at redhat.com Thu Nov 10 17:35:51 2022 From: ofourdan at redhat.com (Olivier Fourdan) Date: Thu, 10 Nov 2022 18:35:51 +0100 Subject: Wayland: destroyed objects and events In-Reply-To: References: Message-ID: On Thu, Nov 10, 2022 at 6:24 PM Maxim Kartashev wrote: >> >> I guess you could destroy the callback with wl_callback_destroy() so >> it won't fire up again? > > Would that stop the callback from firing, considering that wl_callback_destroy() request might be received by the server _after_ an event has already been scheduled? The asynchronous nature of the protocol leaves me guessing sometimes. I think that's the recommended way, it destroys the proxy object on the client side. Cheers Olivier From duke at openjdk.org Fri Nov 11 09:11:12 2022 From: duke at openjdk.org (duke) Date: Fri, 11 Nov 2022 09:11:12 GMT Subject: git: openjdk/wakefield: pure_wl_toolkit: 2 new changesets Message-ID: Changeset: e29f9b19 Author: Dmitry Batrak Committer: Maxim Kartashev Date: 2022-11-09 16:17:48 +0000 URL: https://git.openjdk.org/wakefield/commit/e29f9b194e03848326bdc6a4f41816309cbc3d96 maximize/un-maximize improvements * remove 'roundtrip' calls - they don't seem to be needed after recent changes to paint logic * remove unneeded lock in WLFramePeer.setState - corresponding code doesn't query or modify any state * always repaint client decorations on frame state change - it might not be accompanied by size change * remember the size of frame before maximization, use it on de-maximization, if compositor doesn't propose a size itself ! src/java.desktop/unix/classes/sun/awt/wl/WLFramePeer.java ! src/java.desktop/unix/native/libawt_wlawt/WLComponentPeer.c Changeset: f520a5fb Author: Maxim Kartashev Date: 2022-11-09 18:34:43 +0000 URL: https://git.openjdk.org/wakefield/commit/f520a5fbbc673870278f76dea908ae6bbab820f3 Implemented getColorModel() and createAcceleratedImage() This is enough to make J2Ddemo and StylePad work ! src/java.desktop/unix/classes/sun/awt/wl/WLComponentPeer.java ! src/java.desktop/unix/classes/sun/awt/wl/WLGraphicsConfig.java From duke at openjdk.org Tue Nov 15 09:02:31 2022 From: duke at openjdk.org (duke) Date: Tue, 15 Nov 2022 09:02:31 GMT Subject: git: openjdk/wakefield: pure_wl_toolkit: 3 new changesets Message-ID: <7159b9a4-d616-4512-a03e-97eddf0271b0@openjdk.org> Changeset: 5b9d9894 Author: Dmitry Batrak Committer: Maxim Kartashev Date: 2022-11-11 12:31:44 +0000 URL: https://git.openjdk.org/wakefield/commit/5b9d98946ceb2282fbf25b6d07223fab0d60a791 prevent crashes on concurrent access to AWT API ! src/java.desktop/unix/classes/sun/awt/wl/WLComponentPeer.java ! src/java.desktop/unix/classes/sun/awt/wl/WLFramePeer.java ! src/java.desktop/unix/classes/sun/awt/wl/WLToolkit.java ! src/java.desktop/unix/native/libawt_wlawt/WLComponentPeer.c Changeset: 97008ede Author: Maxim Kartashev Date: 2022-11-10 15:51:05 +0000 URL: https://git.openjdk.org/wakefield/commit/97008ede8e259f341d200fa830a248f78d21d903 Prevent race condition when destroying buffer manager Also implemented AWT_LOCK() family of macros ! src/java.desktop/unix/classes/sun/awt/wl/WLComponentPeer.java ! src/java.desktop/unix/native/common/java2d/wl/WLBuffers.c ! src/java.desktop/unix/native/common/java2d/wl/WLSurfaceData.c ! src/java.desktop/unix/native/libawt_wlawt/WLToolkit.c Changeset: c9a44c32 Author: Maxim Kartashev Date: 2022-11-14 16:16:57 +0000 URL: https://git.openjdk.org/wakefield/commit/c9a44c326aba3e9365b529c60516d78181dc23cf Basic support for VolatileImage The image is actually a non-volatile software implementation. ! src/java.desktop/unix/classes/sun/awt/wl/WLComponentPeer.java ! src/java.desktop/unix/classes/sun/java2d/wl/WLSurfaceData.java ! src/java.desktop/unix/classes/sun/java2d/wl/WLVolatileSurfaceManager.java From maxim.kartashev at jetbrains.com Tue Nov 22 14:15:30 2022 From: maxim.kartashev at jetbrains.com (Maxim Kartashev) Date: Tue, 22 Nov 2022 17:15:30 +0300 Subject: Dependency on xkbcommon Message-ID: Hi All, In the current version of the "pure" Wayland toolkit I introduced a "soft" dependency on libxkbcommon.so that is dlopened at run time to convert keystrokes into symbols. However, we have soon discovered that many modern distros don't have the library installed by default. As far as I can tell, gdk links with it statically. I wonder how practical is it for OpenJDK to follow suit (xkbcommon is licensed under derivatives of the MIT license)? Or else bring in the source code into OpenJDK? Any other ideas? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jadahl at redhat.com Tue Nov 22 14:23:58 2022 From: jadahl at redhat.com (Jonas =?iso-8859-1?Q?=C5dahl?=) Date: Tue, 22 Nov 2022 15:23:58 +0100 Subject: Dependency on xkbcommon In-Reply-To: References: Message-ID: On Tue, Nov 22, 2022 at 05:15:30PM +0300, Maxim Kartashev wrote: > Hi All, > > In the current version of the "pure" Wayland toolkit I introduced a "soft" > dependency on libxkbcommon.so that is dlopened at run time to convert > keystrokes into symbols. However, we have soon discovered that many modern > distros don't have the library installed by default. How did you discover this? I would assume all distributions that supports Wayland having libxkbcommon installed by default, as practically all Wayland clients that does keyboard input make use of it. > > As far as I can tell, gdk links with it statically. I wonder how practical > is it for OpenJDK to follow suit (xkbcommon is licensed under derivatives > of the MIT license)? Or else bring in the source code into OpenJDK? Any > other ideas? GDK doesn't link it statically. This is how it looks on my system: $ ldd /usr/lib64/libgdk-3.so.0 | grep xkbcommon libxkbcommon.so.0 => /lib64/libxkbcommon.so.0 (0x00007f160b2e7000) $ ldd /usr/lib64/libgtk-4.so | grep xkbcommon libxkbcommon.so.0 => /lib64/libxkbcommon.so.0 (0x00007f7aaae8c000) The same applies to Qt6: $ ldd /usr/lib64/libQt6WaylandClient.so.6 | grep xkbcommon libxkbcommon.so.0 => /lib64/libxkbcommon.so.0 (0x00007fc7f14a1000) So I suggest to link to it dynamically, not statically. Jonas From maxim.kartashev at jetbrains.com Wed Nov 23 08:57:23 2022 From: maxim.kartashev at jetbrains.com (Maxim Kartashev) Date: Wed, 23 Nov 2022 11:57:23 +0300 Subject: Dependency on xkbcommon In-Reply-To: References: Message-ID: Thanks, Jonas! It seems that libxkbcommon.so *should* be there, I'm going to verify that again myself. It might be that by default it is not in the path known to the dynamic loader, which would explain dlopen() failing on those systems. On Tue, Nov 22, 2022 at 5:24 PM Jonas ?dahl wrote: > On Tue, Nov 22, 2022 at 05:15:30PM +0300, Maxim Kartashev wrote: > > Hi All, > > > > In the current version of the "pure" Wayland toolkit I introduced a > "soft" > > dependency on libxkbcommon.so that is dlopened at run time to convert > > keystrokes into symbols. However, we have soon discovered that many > modern > > distros don't have the library installed by default. > > How did you discover this? I would assume all distributions that > supports Wayland having libxkbcommon installed by default, as > practically all Wayland clients that does keyboard input make use of it. > > > > > As far as I can tell, gdk links with it statically. I wonder how > practical > > is it for OpenJDK to follow suit (xkbcommon is licensed under derivatives > > of the MIT license)? Or else bring in the source code into OpenJDK? Any > > other ideas? > > GDK doesn't link it statically. This is how it looks on my system: > > $ ldd /usr/lib64/libgdk-3.so.0 | grep xkbcommon > libxkbcommon.so.0 => /lib64/libxkbcommon.so.0 (0x00007f160b2e7000) > $ ldd /usr/lib64/libgtk-4.so | grep xkbcommon > libxkbcommon.so.0 => /lib64/libxkbcommon.so.0 (0x00007f7aaae8c000) > > The same applies to Qt6: > > $ ldd /usr/lib64/libQt6WaylandClient.so.6 | grep xkbcommon > libxkbcommon.so.0 => /lib64/libxkbcommon.so.0 (0x00007fc7f14a1000) > > So I suggest to link to it dynamically, not statically. > > > Jonas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maxim.kartashev at jetbrains.com Wed Nov 23 10:05:03 2022 From: maxim.kartashev at jetbrains.com (Maxim Kartashev) Date: Wed, 23 Nov 2022 13:05:03 +0300 Subject: Dependency on xkbcommon In-Reply-To: References: Message-ID: This was indeed a false alarm: the file installed by default is libxkbcommon.so.0, while we are trying to dlopen("libxkbcommon.so"), which is usually absent unless you install the -dev package that provides a symlink libxkbcommon.so -> libxkbcommon.so.0 Mystery solved, I'll fix the code. On Wed, Nov 23, 2022 at 11:57 AM Maxim Kartashev < maxim.kartashev at jetbrains.com> wrote: > Thanks, Jonas! > > It seems that libxkbcommon.so *should* be there, I'm going to verify that > again myself. It might be that by default it is not in the path known to > the dynamic loader, which would explain dlopen() failing on those systems. > > On Tue, Nov 22, 2022 at 5:24 PM Jonas ?dahl wrote: > >> On Tue, Nov 22, 2022 at 05:15:30PM +0300, Maxim Kartashev wrote: >> > Hi All, >> > >> > In the current version of the "pure" Wayland toolkit I introduced a >> "soft" >> > dependency on libxkbcommon.so that is dlopened at run time to convert >> > keystrokes into symbols. However, we have soon discovered that many >> modern >> > distros don't have the library installed by default. >> >> How did you discover this? I would assume all distributions that >> supports Wayland having libxkbcommon installed by default, as >> practically all Wayland clients that does keyboard input make use of it. >> >> > >> > As far as I can tell, gdk links with it statically. I wonder how >> practical >> > is it for OpenJDK to follow suit (xkbcommon is licensed under >> derivatives >> > of the MIT license)? Or else bring in the source code into OpenJDK? Any >> > other ideas? >> >> GDK doesn't link it statically. This is how it looks on my system: >> >> $ ldd /usr/lib64/libgdk-3.so.0 | grep xkbcommon >> libxkbcommon.so.0 => /lib64/libxkbcommon.so.0 (0x00007f160b2e7000) >> $ ldd /usr/lib64/libgtk-4.so | grep xkbcommon >> libxkbcommon.so.0 => /lib64/libxkbcommon.so.0 (0x00007f7aaae8c000) >> >> The same applies to Qt6: >> >> $ ldd /usr/lib64/libQt6WaylandClient.so.6 | grep xkbcommon >> libxkbcommon.so.0 => /lib64/libxkbcommon.so.0 (0x00007fc7f14a1000) >> >> So I suggest to link to it dynamically, not statically. >> >> >> Jonas >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Mon Nov 28 08:22:58 2022 From: duke at openjdk.org (duke) Date: Mon, 28 Nov 2022 08:22:58 GMT Subject: git: openjdk/wakefield: pure_wl_toolkit: 6 new changesets Message-ID: <837ec34c-6527-419d-afb9-c453c833fd29@openjdk.org> Changeset: 0c724402 Author: Maxim Kartashev Date: 2022-11-16 12:37:32 +0000 URL: https://git.openjdk.org/wakefield/commit/0c7244024484aacdeecdc8ee11f351b493030d3e Prevent deadlock when scrolling SurfaceData need to be able to be locked twice during scrolling, but the associated mutex wasn't recursive, which led to a deadlock. ! src/java.desktop/unix/native/common/java2d/wl/WLBuffers.c ! src/java.desktop/unix/native/common/java2d/wl/WLSurfaceData.c Changeset: f5f49f37 Author: Dmitry Batrak Committer: Maxim Kartashev Date: 2022-11-17 14:09:05 +0000 URL: https://git.openjdk.org/wakefield/commit/f5f49f37f46df6b529cc1a6b36afb8025cf83c5a support setting mouse cursors ! make/autoconf/lib-wayland.m4 ! src/java.desktop/unix/classes/sun/awt/wl/WLComponentPeer.java + src/java.desktop/unix/classes/sun/awt/wl/WLCustomCursor.java ! src/java.desktop/unix/classes/sun/awt/wl/WLFrameDecoration.java ! src/java.desktop/unix/classes/sun/awt/wl/WLFramePeer.java ! src/java.desktop/unix/classes/sun/awt/wl/WLToolkit.java ! src/java.desktop/unix/native/common/java2d/wl/WLBuffers.c + src/java.desktop/unix/native/libawt_wlawt/WLCursor.c ! src/java.desktop/unix/native/libawt_wlawt/WLRobotPeer.c ! src/java.desktop/unix/native/libawt_wlawt/WLToolkit.c ! src/java.desktop/unix/native/libawt_wlawt/WLToolkit.h Changeset: 96c9a95e Author: Dmitry Batrak Committer: Maxim Kartashev Date: 2022-11-18 19:51:17 +0000 URL: https://git.openjdk.org/wakefield/commit/96c9a95e4b1c6b1534433171392fcbea7b00e5de set cursor on pointer enter event, as per Wayland API requirement in the initial implementation cursor was only updated on pointer move events ! src/java.desktop/unix/classes/sun/awt/wl/WLComponentPeer.java Changeset: e92347b0 Author: Dmitry Batrak Committer: Maxim Kartashev Date: 2022-11-23 11:17:30 +0000 URL: https://git.openjdk.org/wakefield/commit/e92347b069a21725883e381ffb78ada473378e98 generate correct mouse events after click in window resize area ! src/java.desktop/unix/classes/sun/awt/wl/WLFrameDecoration.java ! src/java.desktop/unix/classes/sun/awt/wl/WLInputState.java ! src/java.desktop/unix/classes/sun/awt/wl/WLToolkit.java Changeset: c06812a8 Author: Maxim Kartashev Date: 2022-11-23 13:19:15 +0000 URL: https://git.openjdk.org/wakefield/commit/c06812a856157c0a9a1cbc2fe1611157041a9d45 dlopen version 0 of xkbcommon if non-versioned file is missing ! src/java.desktop/unix/native/libawt_wlawt/WLToolkit.c Changeset: e86a60bf Author: Maxim Kartashev Date: 2022-11-15 17:57:19 +0000 URL: https://git.openjdk.org/wakefield/commit/e86a60bf9899882a515cf878f4d6b1499d627f6f Dialog and window menu support ! src/java.desktop/unix/classes/sun/awt/wl/WLComponentPeer.java + src/java.desktop/unix/classes/sun/awt/wl/WLDecoratedPeer.java + src/java.desktop/unix/classes/sun/awt/wl/WLDialogPeer.java ! src/java.desktop/unix/classes/sun/awt/wl/WLFrameDecoration.java ! src/java.desktop/unix/classes/sun/awt/wl/WLFramePeer.java ! src/java.desktop/unix/classes/sun/awt/wl/WLToolkit.java + src/java.desktop/unix/classes/sun/awt/wl/WLWindowPeer.java ! src/java.desktop/unix/native/libawt_wlawt/WLComponentPeer.c ! src/java.desktop/unix/native/libawt_wlawt/WLToolkit.h