wxWindow::WarpPointer does nothing on GTK w/Wayland (Issue #23778)
scottb88
Description
Since Fedora switched to Wayland, WarpPointer does nothing.
My app uses WarpPointer at various points, always in response to mouse events, in a way that works the way the user is expecting, doesn't surprise them, saves them time, and is always within the main app window. Works great on Mac and windows.
Platform and version information
I'm using
- wxWidgets version 3.1.5
- I checked the change log and looked at the source on Master and it appears to be the same as 3.1.5.
- GTK version: 4.10.4-1.fc38 (all versions in the last 2 years)
- GDK == Wayland works perfect on X11
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
scottb88
Wayland is security conscious, and allowing an app free reign of the mouse is said to be a security risk. An old (2014) discussion stated that relative_pointer must be used:
https://wayland.app/protocols/relative-pointer-unstable-v1
I'm not sure if gdk_seat_grab () would help. That would restrict the warp to the window, and be safer. I have zero experience with these APIs.
GTK/Wayland finally came up with a secure and efficient way to capture screen movement to video. It took years. That's about all I know.
gdk_seat_grab ()
gdk_seat_grab ()
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ian McInerney
I went down the wayland mouse warping rabbit hole a year ago, and it is basically discouraged by upstream (not necessarily for security reasons, but because they think it is bad UI/UX for the application to move the mouse on its own). My results are summarized here: https://gitlab.com/kicad/code/kicad/-/issues/9785#note_745301721.
That said, apparently there is an extension that some compositors are implementing called zwp_pointer_lock_v1.set_cursor_position_hint, which is supposed to allow programmatic movement of the cursor (extension defined here: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml#L218). However, even that extension seems to be implemented in different ways in different window managers/compositors, with this comment saying Weston and Mutter apply it at different times https://gitlab.freedesktop.org/xorg/xserver/-/issues/734#note_749474.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
scottb88
You have a drawing tool, my app is a construction estimating tool. I'm drawing shapes over an image or PDF of a blueprint. We probably need warp for the same reason.
I'm totally ok with the warp being restricted to the client area of a window that the app created. But even apple who's ui guidelines forbid it, supports it.
For those not familiar with precision drawing, it's sometimes fastest for the user for part of all of the screen to be magnified temporarily mid drawing. For this action to be incorporated into the workflow smoothly, with minimal slowdown, moving the mouse pointer in necessary.
Perhaps we can convince gtk and kde that the functionality is necessary (and others) so the group can request it from Wayland.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
oneeyeman1
@scottb88 ,
Wayland people are really, really stubborn. No one can convince them on anything.
Tried that some time ago (asked to allow positioning TLW) and failed miserably.
Thank you.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mircea Kitsune
Really hope this problem can be resolved in some form. I recently switched to the Wayland session of KDE Plasma on my Manjaro Linux box: Ever since I have issues using DarkRadiant which is the map editor for TheDarkMod. We've been discussing it for months trying to figure out what's going on as this doesn't happen on X11, I've had to use partial workarounds to be able to keep using the software... thankfully someone found and pointed out this report.
Our bug in a nutshell: To grab and translate a 2D / 3D view, the cursor is expected to be in the middle of the panel. Because it's not the view starts going out of control as you move the mouse around due to movements being interpreted as being at a greater length, harder the further the pointer goes from the position at which the view was clicked.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
scottb88
VZ
Really hope this problem can be resolved in some form.
Please ask Wayland developers to implement support for this, we can't do anything about it until then. I don't have much hope they're going to listen, but I just don't see any other alternatives, sorry.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Jon Evans
@vadz the Wayland devs insist this is possible already by using the pointer constraints extension, which is how Xwayland does it.
https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xwayland/xwayland-input.c#L3246
Do you have thoughts about whether or not this could solve the problem?
Also, it seems like wxWidgets doesn't currently have a lot (any?) Wayland-specific API calls inside the GTK port. If this were to be implemented by copying the techniques from xwayland-input.c, would this be able to live inside the GTK port or would there need to be some new place in wxWidgets to add Wayland-specific code?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Scott Talbert
Also, it seems like wxWidgets doesn't currently have a lot (any?) Wayland-specific API calls inside the GTK port. If this were to be implemented by copying the techniques from xwayland-input.c, would this be able to live inside the GTK port or would there need to be some new place in wxWidgets to add Wayland-specific code?
wx does have some Wayland-specific API calls already, see:
https://github.com/wxWidgets/wxWidgets/blob/master/src/unix/glegl.cpp
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
@vadz the Wayland devs insist this is possible already by using the pointer constraints extension, which is how Xwayland does it.
https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xwayland/xwayland-input.c#L3246
My question is whether this works for "native Wayland" windows too, i.e. does this actually change the mouse position at Wayland level or just the mouse position reported by Xwayland? If it's really the former, let's do it, by all means.
Do you have thoughts about whether or not this could solve the problem?
I'm not sure but it would be worth trying.
Also, it seems like wxWidgets doesn't currently have a lot (any?) Wayland-specific API calls inside the GTK port. If this were to be implemented by copying the techniques from xwayland-input.c, would this be able to live inside the GTK port or would there need to be some new place in wxWidgets to add Wayland-specific code?
Yes, definitely, we can test whether we're using Wayland during run-time (all Wayland-related code also has to live inside compile-time checks, but this is not a big problem neither) and then do whatever we need. In addition to OpenGL code mentioned by Scott, see also src/gtk/toplevel.cpp which has many checks for Wayland. It's not pretty but it works fine.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mircea Kitsune
@craftyjon I can confirm that when running the application I'm experiencing problems with using GDK_BACKEND=x11 the issue goes away, even if I'm still on the Plasma Wayland session and this variable is essentially forcing the application to go through X11. I'm in fact using that as a workaround until the problem is solved... unfortunately some windows still do it even this way and it's only a partial fix.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Jon Evans
After some discussion on the wayland IRC chat, I have opened https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/158 -- hopefully this will lead to an eventual first-class API for this that wx can use, as it seems like the pointer-constraints approach may have some limitations.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
dsa-t
Here's how I implemented it in KiCad:
https://gitlab.com/kicad/code/kicad/-/commit/89cb35dc2294d2c5144471c8f6485d925d04b306
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23778)It would be nice to integrate this in wx. @dsa-t Do we have your permission to reuse the code in the linked KiCad commit (maybe not literally, but I would refer to it when writing this if you do give it) under wx licence?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
dsa-t
dsa-t left a comment (wxWidgets/wxWidgets#23778)@dsa-t Do we have your permission to reuse the code in the linked KiCad commit
Yes.
But for generic use-cases it's better to wait for https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/337
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Scott Talbert
swt2c left a comment (wxWidgets/wxWidgets#23778)@dsa-t Do we have your permission to reuse the code in the linked KiCad commit
Yes.
But for generic use-cases it's better to wait for https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/337
We'd probably have to wait quite a while though right? That's just a protocol update. Then all the compositors would have to implement it, right?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
dsa-t
dsa-t left a comment (wxWidgets/wxWidgets#23778)We'd probably have to wait quite a while though right?
True.
Then all the compositors would have to implement it, right?
At least for KWin (KDE) there is an implementation.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Zamundaaa
Zamundaaa left a comment (wxWidgets/wxWidgets#23778)The pointer warp protocol is now merged, and you can expect it to be supported in Plasma 6.5 (will be released in November)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ian McInerney
imciner2 left a comment (wxWidgets/wxWidgets#23778)I think to get this wx will need to actually implement the protocol itself (similar to how we have the current pointer protocol in KiCad directly, wx would need to do that for this new protocol). Because the gdk_device_warp function was removed in GTK 4 (https://gitlab.gnome.org/GNOME/gtk/-/commit/3d37f08f38c10923cc8b1e5fcc999b8b76d75533), and so I don't know if we can count on having a library implementation of it to use.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23778)So I've tried implementing support for wp_pointer_warp_v1 as there is now at least one compositor with support for it (Jay) and I almost managed to do it, except that I have no idea how to get the (last) enter serial from GTK 3. It stores it in GdkWaylandDisplay, but doesn't provide any accessor function for it and AFAICS the struct itself is private.
Does anybody have any idea about how to get the serial from GTK or do we really need to attach our own listener for pointer events to all surfaces (we can get wl_surface from GdkWindow) just to get it?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
mahkoh
mahkoh left a comment (wxWidgets/wxWidgets#23778)The enter serial is provided to the wl_pointer event listener. You have to create your own wl_pointer to receive it. SDL already uses this protocol.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23778)Thanks, I guess I'll have to do it. This is a lot of work for something only supported in one not very widely used compositor, however :-( It's a real pity GTK doesn't allow accessing this, even though it has it already, but I guess that's just how it is.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Zamundaaa
Zamundaaa left a comment (wxWidgets/wxWidgets#23778)KWin has support for it, and Mutter recently implemented it too.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23778)KWin has support for it, and Mutter recently implemented it too.
I trusted https://wayland.app/protocols/pointer-warp-v1 but maybe it's out of date.
Anyhow, this is good news, of course, and a good reason to do this sooner rather than later.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23778)I have an implementation which works (with Jay) now, but I still have a problem with multiple seats: how do I map the wl_surface or even wl_seat that I can obtain from GTK with the wl_seat that I create? They're different objects and I don't see how to pass from one to the other as there doesn't seem to be any way to get the ID (confusingly called "name" in Wayland) of an already existing seat. Does anybody have any idea about how to do it?
If not, I guess we'll just have to limit support for this to just a single seat with a pointer...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Zamundaaa
Zamundaaa left a comment (wxWidgets/wxWidgets#23778)Surfaces are independent from seats, you don't need to map anything. You can just call warp_pointer with the wl_surface from GTK and the wl_pointer you created.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23778)Sorry, I don't think this answers my question. A pointer is associated with a seat and if we have multiple seats (with pointers), I can't see how to select the correct one, i.e. the one which is used with the given surface.
As usual, the aggravating thing is that GDK stores this link internally, but there is no way to get to it from the outside.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Zamundaaa
Zamundaaa left a comment (wxWidgets/wxWidgets#23778)A pointer is associated with a seat and if we have multiple seats (with pointers), I can't see how to select the correct one, i.e. the one which is used with the given surface.
A surface could have pointer focus in 5 seats concurrently, there isn't "one" that's used with a surface.
If wxwidgets actually supports multi-seat, you need to find out which seat caused the pointer warp event, and only warp the matching wl_pointer.
If it doesn't have good or any multi-seat support (which I assume), just warp the pointer of the seat that got the last wl_pointer.enter event.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23778)I've never actually used Wayland multi-seat support, so I don't even know how to test this, but I'm not sure "last" is the good criterion here...
Anyhow, for now I'm just using the first seat which has a pointer and a valid enter serial.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23778)I've put my code so far in #25721. As explained there, this doesn't actually work correctly, in spite of what I had assumed in my initial excitement.
Any comments there about the problems I describe and about anything else in my code (this is the first time I write something using Wayland, so I'm very open to suggestions of improving it) would be welcome.
And, of course, please test it if you can.
TIA!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
mahkoh
mahkoh left a comment (wxWidgets/wxWidgets#23778)While it would be good to have multi-seat support in wxwidgets, it is not something you have to seriously worry about. A significant amount of software fails catastrophically if there is more than one seat: they ignore all but the first or last seat (it varies). If new seats are announced at runtime, they confuse which objects belong to which seats, etc.
Since the order in which seats are announced is random, such software might work when you start it the first time but then fail the second time. This means that I practice having more than one seat is not workable on general purpose desktop compositors.
In this particular case, you'll probably be fine with trying to warp every seat.
I also thought (and even tried) attaching a listener to GDK seat
Every object can only have a single listener. The function being called add_listener is a misnomer.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23778)In this particular case, you'll probably be fine with trying to warp every seat.
I just don't know enough about the real life use of multiple seats to judge whether it's a good idea. E.g. I could imagine having 2 seats connected to the same machine but associated with different outputs and in this case it really wouldn't make sense to warp the "other" seat pointer to the given output. But, again, I don't know if it's a realistic scenario or not.
Anyhow, it's probably not the most pressing concern.
I also thought (and even tried) attaching a listener to GDK seat
Each object can only have a single listener. The function being called add_listener is a misnomer.
Interesting, are you sure about this? All Wayland documentation I've seen definitely implies that you can have multiple listeners. And the comment for wl_seat_listener::name would definitely seem to imply that other events, e.g. capabilities, are sent to all listeners and not just a single one, otherwise why would single name out?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
mahkoh
mahkoh left a comment (wxWidgets/wxWidgets#23778)—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23778)Wow, thanks. The documentation is really, really misleading as it never once mentions that this is not supported.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23778)BTW, looking at GNOME implementation I see that it requires the application to have the "implicit grab" for pointer warping to work. Does anybody have any idea what does this mean, i.e. what an implicit grab is and how do we get it? I wanted to test this myself but building Mutter in Fedora 42 toolbox doesn't work any longer because of missing glycin-2 dependency and I didn't pursue this any longer...
I'm afraid this might not be the case for arbitrary uses of WarpPointer(), meaning that we would still have to support zwp_pointer_constraints_v1 too (because I assume this, at least, works fine with GNOME?).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Zamundaaa
Zamundaaa left a comment (wxWidgets/wxWidgets#23778)Implicit grabs are when some mouse button is held down while in the surface - even when the pointer leaves the surface, it still has pointer focus until the button is released.
I'm afraid this might not be the case for arbitrary uses of WarpPointer(), meaning that we would still have to support zwp_pointer_constraints_v1 too (because I assume this, at least, works fine with GNOME?).
Pointer constraints are not meant for, will not reliably work for, and should not be used for pointer warping, that's why we made a pointer warp protocol...
If Gnome's implementation of pointer warping doesn't work for your use case, then you should make an issue on Mutter's repository about it. Please don't try to work around it.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23778)Implicit grabs are when some mouse button is held down while in the surface
I was afraid of something like this. If I understand this correctly, i.e. if calls to WarpPointer() are simply ignored if no mouse buttons are held down, this is definitely not going to work under Mutter for many (most?) use cases :-(
Pointer constraints are not meant for, will not reliably work for, and should not be used for pointer warping that's why we made a pointer warp protocol...
But if the compositor doesn't implement it, or doesn't implement it in a useful way, using pointer constraints would still be better than doing nothing, wouldn't it? I wonder how well does this for KiCad in practice.
If Gnome's implementation of pointer warping doesn't work for your use case, then you should make an issue on Mutter's repository about it. Please don't try to work around it.
I don't have a use case, I'm a library author, it's the applications authors who have use cases. But it seems trivially simple to imagine many use cases in which you'd like to warp the pointer without the mouse button being held pressed, e.g. imagine the user presses Ctrl-N to create a new shape and you want to position the pointer at it. In fact, I have more trouble imagining useful use cases for wrapping the mouse when the mouse button is pressed than when it is not.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Jon Evans
craftyjon left a comment (wxWidgets/wxWidgets#23778)But if the compositor doesn't implement it, or doesn't implement it in a useful way, using pointer constraints would still be better than doing nothing, wouldn't it? I wonder how well does this for KiCad in practice.
From KiCad's point of view, if the user's choice of compositor does not implement the protocol, that is on them, and the user should switch to a compositor that implements all required protocols for our application. We're OK with dropping "hacks" like the pointer constraints thing. We already advocated for (and got) a real pointer warping protocol in Wayland, and we have little interest in re-arguing that point with N different compositor maintainers.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23778)I'm, of course, glad to not add any more hacks, but if this doesn't work in KiCad under GNOME, this feels like a rather hollow victory. Anyhow, I have to at least test how this works with mutter first. Unfortunately I just can't run its latest version, even after installing Rust toolchain in my toolbox and compiling libglycin from source, it exits with a mysterious
Failed to setup: Failed to take control of the session: GDBus.Error:System.Error.EBUSY: Device or resource busy
message. I've opened an issue about --nested apparently not existing any more, but it's all rather weird. It's crazy that after setting things up to run mutter just a few months ago, they don't work any longer, I'm almost feeling like a JS developer with such rate of breakage^W change :-(
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23778)I'm being asked about the use case for warping in KiCad in mutter issue tracker, could someone please answer it there? I don't know it well enough myself.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
scottb88
scottb88 left a comment (wxWidgets/wxWidgets#23778)User clicks left mouse down (to place a point)
Program displays a magnifier (when needed)
User lifts left button for exact point position.
If the magnifier is needed and hits the edge of the window,
I warp the pointer to the center of the magnifier so that cursor is still
over the part of the image the user is aiming for (very important to save
time/confusion).
Always only in the app window, always while left mouse is down, always puts
it back, never traps the cursor.
On Fri, Aug 29, 2025 at 8:43 AM VZ ***@***.***> wrote:
> *vadz* left a comment (wxWidgets/wxWidgets#23778)
> <https://github.com/wxWidgets/wxWidgets/issues/23778#issuecomment-3237094103>
> I'm being asked about the use case for warping in KiCad in mutter issue
> tracker
>
> —
> Reply to this email directly, view it on GitHub
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AODX3TA52PLVGRYLYNTBGYT3QBKJTAVCNFSM6AAAAAB6KLRSM2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEMZXGA4TIMJQGM>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Closed #23778 as completed via 77ec71a.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.