The two screen calibration clicks return the same position in Wayland

[thelabcat]

Click opposite corners of the touch area.
(1156, 549)
(1156, 549)
touch offset (1156, 549) 
touch size (0, 0)
dconf: symbol lookup error: /lib64/libdconf.so.1: undefined symbol: g_once_init_leave_pointer
Exception in thread Thread-1:
Traceback (most recent call last):
  File "threading.py", line 1073, in _bootstrap_inner
  File "DS_FPS_mousefix.pyw", line 175, in run
  File "DS_FPS_mousefix.pyw", line 260, in abs_to_rel
ZeroDivisionError: division by zero

[thelabcat]

Even by copy pasting the exact screen calibration code, I was unable to reproduce getting two clicks with the same position. I watched the program run in the console, and it's not because it's registering the same click twice (at least not directly). It waited for the second click to print the same coordinates again.

[thelabcat]

Confirming, neither this nor #7 affect the Windows version, even with the same old mouse, keyboard, and PyAutoGUI libraries.

[thelabcat]

Even by copy pasting the exact screen calibration code, I was unable to reproduce getting two clicks with the same position.

I was later able to reproduce by making the IDLE window lose focus, that is, clicking an area outside it. Note, if I clicked outside it and then clicked inside, the mouse position was reported correctly.

[thelabcat]

Using PyAutoGUI's Mouse Info app, I discovered that position stops reporting as updated when the mouse is not over IDLE or the Mouse Info window. Thus, the mouse position getting system is restricted.

[thelabcat]

PyAutoGUI uses Xlib, so the mouse module must be having a separate issue?

[thelabcat]

See https://github.com/boppreh/mouse/issues/142

[thelabcat]

PyAutoGUI uses Xlib, so the mouse module must be having a separate issue?

Oddly, the mouse module has the exact same behavior.

[thelabcat]

I caused Wayland to grant input control to Python first, but this did not make the position reporting work correctly.

[thelabcat]

Oh, the mouse module might just use the device reading for buttons, but still use xlib position sensing, which relies on XWayland, which is probably limited to the creating window.

[thelabcat]

Test to do: Have the mouse fix window maximized behind the emulator window, and see if that lets position reporting work as the mouse cursor is over both of them.

[thelabcat]

Test to do: Have the mouse fix window maximized behind the emulator window, and see if that lets position reporting work as the mouse cursor is over both of them.

Did not work. However, I found out that OTHER windows from DIFFERENT processes that are also using XWayland let the system work. Maybe if I could somehow make MelonDS launch with XWayland?

[thelabcat]

TYJ, that does work! See this article for information on how to do it:

So, to force a non-flatpak application to run in Xwayland, simply type in the terminal (or modify the launcher):

env -u WAYLAND_DISPLAY

For flatpak applications, it's a bit different.

Download Flatseal from flathub, change permissions of your application or game in Flatseal to remove the "Wayland" socket. In my experience, in versions of KDE lower than 5.23, you might need to disable "fallback-x11" socket as well.