Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows tablet (with touchscreen): Touches to non-embedded SubWindows are relayed to the main window #91099

Closed
GNSS-Stylist opened this issue Apr 24, 2024 · 4 comments · Fixed by #98318

Comments

@GNSS-Stylist
Copy link
Contributor

GNSS-Stylist commented Apr 24, 2024

Tested versions

Reproducible in v4.3.dev.custom_build [c7f56d3], 4.2.1 stable, 4.2.2 stable (compatibility renderer because Forward+ does not work on this device)

System information

Panasonic ToughPad FZ-G1 - Windows 10.0.19045 - GLES3 (Compatibility) - Intel(R) HD Graphics 5500 (Intel Corporation; 20.19.15.5058) - Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz (4 Threads)

Issue description

Touches to a non-embedded SubWindow's area seems to be relayed to the main window so that the relative coordinates stay the same. Video:

untitled5.mp4

This does not happen when the SubWindow is embedded (setting "Display->Window->Embed Subwindows" changed in Project Settings):

untitled6.mp4

The editor itself also handles touches somehow erratically. Sometimes for example menus open and sometimes not. I wasn't able to make much sense about this, but at least same kind of problem with SubWindow touches is present there as well:

untitled7.mp4

It looks like the (invisible) mouse cursor is actually moved to the touch position (I'm moving the cursor with external mouse before and after the press by touch, first showing a tooltip to better see when the (invisible) cursor is moved), but the press is not recognized.

Other applications have been working as excepted with this tablet, although I haven't been using many.

Steps to reproduce

Create a non-embedded SubWindow and try to manipulate anything there by touch. Touches are relayed to the main window.

Minimal reproduction project (MRP)

WindowsTouchInputBug.zip
First stumbled upon this in this project (in 4.2.1 & 4.2.2): https://github.com/GNSS-Stylist/AgOpenGPSSimPoC (touches from the settings-window are relayed to the main window)

@not-my-username
Copy link
Contributor

not-my-username commented Jun 10, 2024

I have also encountered this issue on various Dell and HP all-in-one PCs with touch screens, so this isn't just an issue with your device. I believe this may be related to the way Godot, by default, converts touch inputs to mouse clicks, as it seems to be sending the InputEvent to the wrong control node.

Both devices are using compatibility rendering for the same reason you are, and are running Godot version 4.2.2, tested on both windows and linux with the same issue

@Swarkin
Copy link
Contributor

Swarkin commented Oct 26, 2024

tysm! Ive been having this problem for a while, see issue #77653
I will check whether this has fixed it once i have time.

@GNSS-Stylist
Copy link
Contributor Author

GNSS-Stylist commented Oct 26, 2024

Touch handling with the device/OS mentioned in this issue seems to be broken in current master ( 61accf0 ) differently than before.

With the current master this issue's MRP works as follows:

  • With the fix Fix mouse emulation always sending events to the main window #98318: The slider works as expected, but checkboxes (in the SubWindow) do not change their state at all when touching.
  • Fix reverted: The slider will function as shown in the videos above (relaying the touches to the main window), but checkboxes still don't work.

So the fix fixed the slider but there is probably something else broken elsewhere now(?)

@Swarkin : Interested to hear about your experiences.
@alexkar598 : Did out test the MRP in this issue on your setup?

Edit: Tried the MRP with Linux (Mint 22 Cinnamon) and Godot 4.4 Dev 6 on the same device. Seems to work as described above on "Fix reverted"-part (The slider will function as shown in the videos above (relaying the touches to the main window), but checkboxes (in the SubWindow) still don't work.).

@alexkar598
Copy link
Contributor

Touch handling with the device/OS mentioned in this issue seems to be broken in current master ( 61accf0 ) differently than before.

With the current master this issue's MRP works as follows:

* With the fix [Fix mouse emulation always sending events to the main window #98318](https://github.com/godotengine/godot/pull/98318): The slider works as expected, but checkboxes do not change their state at all when touching.

* Fix reverted: The slider will function as shown in the videos above (relaying the touches to the main window), but checkboxes still don't work.

So the fix fixed the slider but there is probably something else broken elsewhere now(?)

@Swarkin : Interested to hear about your experiences. @alexkar598 : Did out test the MRP in this issue on your setup?

I was now able to run Linux (Mint live on USB-stick) on my device (tried it also when making this issue, don't remember why it didn't work). Once I get a new SSD to install Linux into (one in the device now is too small for Windows&Linux&stuff), I should be able to test also Linux-versions on this device. Twiddling with live-version is quite a hassle...

From my testing, I can replicate similar results. I noticed that the window focus does not get shifted properly on my setup. It seems this causes an extra mouse event being sent to the focused window. This in turn seems to prevent clicks if theres a focused control. Disabling on click focus for the checkboxes works around the bug for me. I'm unsure where the extra click event is coming from, it's device is 0 unlike the emulated clicks which have a device of -1.

That being said, I am doing all this over RDP as I lack a windows touch device and I get click events event if I turn off mouse emulation so perhaps its RDP injecting those mouse clicks godot.

On my linux machine (KDE + XWayland), window focus gets shifted properly no matter what and this issue is unreproducible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants