The issue has been encountered while developing a Wayland toolkit for OpenJDK, so there is no ready-made product that can be used to demonstrate it. A development build of a JDK together with a Java program that demonstrates the issue can be provided upon request, though.

SOFTWARE/OS VERSIONS
KUbuntu 24.04
KDE Plasma Version:  5.27.12

ADDITIONAL INFORMATION
The issue hinders porting efforts of IntelliJ IDEs on Wayland as the relative pointer movement protocol is necessary to implement interactive popup repositioning using the mouse pointer.

(In reply to Maxim Kartashev from comment #1)
> The issue has been encountered while developing a Wayland toolkit for
> OpenJDK, so there is no ready-made product that can be used to demonstrate
> it. A development build of a JDK together with a Java program that
> demonstrates the issue can be provided upon request, though.
> 
> SOFTWARE/OS VERSIONS
> KUbuntu 24.04
> KDE Plasma Version:  5.27.12
> 
> ADDITIONAL INFORMATION
> The issue hinders porting efforts of IntelliJ IDEs on Wayland as the
> relative pointer movement protocol is necessary to implement interactive
> popup repositioning using the mouse pointer.

Can you please provide a demo application and instructions how to run it with wayland support please?

I looked at the code and kwin _should_ send relative motion events. Also, just to be sure, are you running plasma 5.27 or 6.4?

(In reply to Vlad Zahorodnii from comment #3)
> I looked at the code and kwin _should_ send relative motion events. Also,
> just to be sure, are you running plasma 5.27 or 6.4?

5.27.12

> I looked at the code and kwin _should_ send relative motion events.

Can you point to the relevant code, please? I'd like to have a look as well

(In reply to Maxim Kartashev from comment #5)
> > I looked at the code and kwin _should_ send relative motion events.
> 
> Can you point to the relevant code, please? I'd like to have a look as well

With popups, the most relevant bit is the popup input event filter https://invent.kde.org/plasma/kwin/-/blob/Plasma/5.27/src/popup_input_filter.cpp?ref_type=heads#L44 but it should let motion events pass through.

Eventually, ForwardInputFilter::pointerEvent() should catch it and send a relative motion event https://invent.kde.org/plasma/kwin/-/blob/Plasma/5.27/src/input.cpp?ref_type=heads#L1777

In Plasma 6, that code changed quite a bit but the overall mechanics are still the same.

Thanks! 

Let me try to simplify the reproducer as much as possible.

Created attachment 185793 [details]
A Java program to reproduce the issue

OK, here's a reproducer:

1. Download a Java SDK (JBRSDK) from here: https://github.com/JetBrains/JetBrainsRuntime/releases/tag/jbr-release-21.0.8b1163.59
Here's a direct link to the linux-x64 version: https://cache-redirector.jetbrains.com/intellij-jbr/jbrsdk-21.0.8-linux-x86-b1163.59.tar.gz

2. Unpack
tar xzvf jbrsdk-21.0.8-linux-x64-b1163.59.tar.gz
cd jbrsdk-21.0.8-linux-x64-b1163.59

3. Download the attached Java program as AWT.java file, copy it to the jbrsdk-21.0.8-linux-x64-b1163.59 directory

4. Run
WAYLAND_DEBUG=1 ./bin/java -Dawt.toolkit.name=WLToolkit AWT.java 2>log
and move the mouse pointer over the window that has appeared a bit.

5. Grep the log file for relative pointer movement events

> ag relative_pointer log
Here's what I get on Ubuntu 22.04 with Mutter, for example:
32:[1304284.676] wl_registry@2.global(18, "zwp_relative_pointer_manager_v1", 1)
33:[1304284.723]  -> wl_registry@2.bind(18, "zwp_relative_pointer_manager_v1", 1, new id [unknown]@17)
56:[1304285.742]  -> zwp_relative_pointer_manager_v1@17.get_relative_pointer(new id zwp_relative_pointer_v1@7, wl_pointer@12)
153:[1305005.497] zwp_relative_pointer_v1@7.relative_motion(39, 3689095613, -16.41015625, -21.88281250, -9.00000000, -12.00000000)
156:[1305005.869] zwp_relative_pointer_v1@7.relative_motion(39, 3689103418, -18.23437500, -21.88281250, -10.00000000, -12.00000000)
...

Note that the reproducer creates a simple toplevel, there are no popups involved, yet there are no relative pointer events coming at all.

(In reply to Maxim Kartashev from comment #10)
> Note that the reproducer creates a simple toplevel, there are no popups
> involved, yet there are no relative pointer events coming at all.

```
[1919366.822] {Default Queue} wl_pointer#3.motion(23634080, 201.81640625, 281.86328125)
[1919366.836] {Default Queue} zwp_relative_pointer_v1#24.relative_motion(5, 2159244057, 12.35937500, -3.08984375, 8.00000000, -2.00000000)
[1919366.849] {Default Queue} wl_pointer#3.frame()
[1919375.028] {Default Queue} wl_pointer#3.motion(23634088, 217.56250000, 280.11328125)
[1919375.063] {Default Queue} zwp_relative_pointer_v1#24.relative_motion(5, 2159252056, 15.74218750, -1.75000000, 9.00000000, -1.00000000)
[1919375.076] {Default Queue} wl_pointer#3.frame()
[1919383.114] {Default Queue} wl_pointer#3.motion(23634096, 238.84765625, 276.24218750)
[1919383.138] {Default Queue} zwp_relative_pointer_v1#24.relative_motion(5, 2159260054, 21.28515625, -3.87109375, 11.00000000, -2.00000000)
[1919383.157] {Default Queue} wl_pointer#3.frame()
[1919391.176] {Default Queue} wl_pointer#3.motion(23634104, 264.84765625, 272.24218750)
[1919391.200] {Default Queue} zwp_relative_pointer_v1#24.relative_motion(5, 2159268055, 26.00000000, -4.00000000, 13.00000000, -2.00000000)
[1919391.219] {Default Queue} wl_pointer#3.frame()
[1919398.891] {Default Queue} wl_pointer#3.motion(23634112, 294.84765625, 266.24218750)
[1919398.917] {Default Queue} zwp_relative_pointer_v1#24.relative_motion(5, 2159276047, 30.00000000, -6.00000000, 15.00000000, -3.00000000)
[1919398.937] {Default Queue} wl_pointer#3.frame()
[1919410.916] {Default Queue} wl_pointer#3.motion(23634120, 328.84765625, 260.24218750)
[1919410.945] {Default Queue} zwp_relative_pointer_v1#24.relative_motion(5, 2159284104, 34.00000000, -6.00000000, 17.00000000, -3.00000000)
[1919410.966] {Default Queue} wl_pointer#3.frame()
[1919415.139] {Default Queue} wl_pointer#3.motion(23634128, 370.84765625, 252.24218750)
[1919415.163] {Default Queue} zwp_relative_pointer_v1#24.relative_motion(5, 2159292059, 42.00000000, -8.00000000, 21.00000000, -4.00000000)
[1919415.182] {Default Queue} wl_pointer#3.frame()
[1919423.188] {Default Queue} wl_pointer#3.motion(23634136, 414.84765625, 246.24218750)
[1919423.214] {Default Queue} zwp_relative_pointer_v1#24.relative_motion(5, 2159300056, 44.00000000, -6.00000000, 22.00000000, -3.00000000)
[1919423.235] {Default Queue} wl_pointer#3.frame()
[1919431.098] {Default Queue} wl_pointer#3.motion(23634144, 462.84765625, 238.24218750)
[1919431.127] {Default Queue} zwp_relative_pointer_v1#24.relative_motion(5, 2159308052, 48.00000000, -8.00000000, 24.00000000, -4.00000000)
[1919431.146] {Default Queue} wl_pointer#3.frame()
```

this is what I get when I run AWT.java on my machine (it's Plasma 6 though)

Can you share complete WAYLAND_DEBUG log for 5.27 please?

Created attachment 185803 [details]
WAYLAN_DEBUG output from KUbuntu 24.04

(In reply to Vlad Zahorodnii from comment #12)
> Can you share complete WAYLAND_DEBUG log for 5.27 please?

Certainly. See attached.

[3506763.459] wl_output@18.mode(1, 1280, 800, 60000)
[3506763.468] wl_output@18.scale(1)
[3506763.470] wl_output@18.geometry(0, 0, 0, 0, 0, "", "Virtual-1-unknown", 0)
[3506763.474] wl_output@18.done()
[3506763.476] zxdg_output_v1@19.logical_position(0, 0)
[3506763.479] zxdg_output_v1@19.logical_size(1280, 800)
[3506763.481] zxdg_output_v1@19.name("Virtual-1")
[3506763.483] zxdg_output_v1@19.description(" Virtual-1-unknown")
[3506763.485] zxdg_output_v1@19.done()

Are you running KWin in a VM? If so, it's possible that kwin receives absolute motion events, in which case, it'll not send relative motion events. It can be verified by running the `sudo libinput debug-events` command (in the VM).

> Are you running KWin in a VM?

Yes, in VirtualBox. Let me re-verify on hardware as well.

On hardware, relative motion events do get generated:
```
[4250268.289] wl_pointer@6.frame()
[4250270.799] wl_pointer@6.motion(1344961, 84.00000000, 274.00000000)
[4250270.822] zwp_relative_pointer_v1@3.relative_motion(0, 1344961736, -48.00000000, 6.00000000, -24.00000000, 3.00000000)
```

That being said, I would still expect `zwp_relative_pointer_manager_v1.get_relative_pointer` to fail in an environment where no events will follow. The client program doesn't seem to have any other way to learn that the interface it relies upon is not functional.

(In reply to Maxim Kartashev from comment #17)
> On hardware, relative motion events do get generated:
> ```
> [4250268.289] wl_pointer@6.frame()
> [4250270.799] wl_pointer@6.motion(1344961, 84.00000000, 274.00000000)
> [4250270.822] zwp_relative_pointer_v1@3.relative_motion(0, 1344961736,
> -48.00000000, 6.00000000, -24.00000000, 3.00000000)
> ```
> 
> That being said, I would still expect
> `zwp_relative_pointer_manager_v1.get_relative_pointer` to fail in an
> environment where no events will follow. The client program doesn't seem to
> have any other way to learn that the interface it relies upon is not
> functional.

From the kwin side, we only forward events that we receive. Maybe kwin could synthesize relative motion events, but we also don't know if it's okay to do so. Only the app knows what should happen in that case.

On Wayland, pointer events are arranged in frames (wl_pointer.frame). For example

- wl_pointer.motion()
- zwp_relative_pointer_v1.relative_motion()
- wl_pointer.frame()

means that there was a single motion event (wl_pointer.motion and zwp_relative_pointer_v1.relative_motion provide information about it). If you receive

- wl_pointer.motion()
- wl_pointer.frame()

it means that there was a motion event but only with absolute coordinates (the app could compute a delta value in such a case if it is okay).

Also note that apps should process/dispatch pointer events after receiving a wl_pointer.frame rather than doing so immediately as individual events arrive.

> ...
> it means that there was a motion event but only with absolute coordinates
> (the app could compute a delta value in such a case if it is okay).

I'm afraid the specification does not support this approach. Here's a quote from https://wayland.app/protocols/relative-pointer-unstable-v1:

"Relative motions are not coupled to wl_pointer.motion events, and can be sent in combination with such events, but also independently. There may also be scenarios where wl_pointer.motion is sent, but there is no relative motion"

So even if KWin currently guarantees that a frame event will follow the motion and relative_motion events and they are always grouped together, who's to say that the order remains in future versions after some refactoring, etc?

That part of the spec mentions that only relative motion events can be sent (without the corresponding wl_pointer.motion event). Think of video games that lock the pointer in the center of the window: the absolute position doesn't change but there are still delta values that can be sent.

FWIW "The order of an absolute and relative motion event originating from the same physical motion is not guaranteed." clarifies that the compositor can send relative and absolute motion events in any order.

If the compositor doesn't put relative and absolute motion events in a single frame, it's a compositor bug (but in all fairness, the protocol could be more explicit about it), the clients won't be able to say for sure whether there's only one or two motions and what the final pointer position is.

It sounds like this is just a bug in the VM (driver) not forwarding relative motion events from the host?

🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!

🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.