Closed GNSS-Stylist closed 3 weeks ago
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
tysm! Ive been having this problem for a while, see issue #77653 I will check whether this has fixed it once i have time.
Touch handling with the device/OS mentioned in this issue seems to be broken in current master ( 61accf060515416da07d913580419fd8c8490f7b ) differently than before.
With the current master this issue's MRP works as follows:
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...
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.
Tested versions
Reproducible in v4.3.dev.custom_build [c7f56d327], 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:
https://github.com/godotengine/godot/assets/50438441/7fbf24bd-d653-482f-9477-767e426e5a92
This does not happen when the SubWindow is embedded (setting "Display->Window->Embed Subwindows" changed in Project Settings):
https://github.com/godotengine/godot/assets/50438441/59fe73bb-3c59-4787-9ec9-72c782cb2c9a
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:
https://github.com/godotengine/godot/assets/50438441/0ff7b005-bd92-47f2-a996-1f58ce977b32
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)