Manjaro Linux: Input.is_action_pressed() receives axis key when user touches right edge of laptop trackpad

[fuzhouch]

Godot version

4.1.2.stable.flathub [399c9dc]

System information

Manjaro Linux unstable rolling version, Gnome w/ Wayland (Help > Copy System Info output: Godot v4.1.2.stable (399c9dc) - Freedesktop SDK 23.08 (Flatpak runtime) - Wayland - Vulkan (Compatibility) - Mesa Intel(R) Xe Graphics (TGL GT2) () - 11th Gen Intel(R) Core(TM) i5-11320H @ 3.20GHz (8 Threads)

Issue description

Expected behavior

When I run my game within Godot IDE on Linux + Gnome desktop, the running game accepts keyboard input ("ui_accept" for jump, "ui_left" and "ui_right" for moving) to control character move. The character should stay if there's no input. It should only move when ui_left o ui_right key is pressed.

Actual behavior

At a random chances I can see the character moves when my hands leave keyboard, as if a ghost hand is pressing my keyboard. It can't be reproduced every time but happens in a relatively high frequency. In my experience the frequency is 1 hit per 3-5 launches.

When the ghost input happens, switching window focus does not solve this issue.

I tried to print return value of Input.is_key_pressed("ui_left") and Input.is_key_pressed("ui_right"). The output is true when the issue happens.

As it sometimes works completely fine, I can't exactly tell how it's reproduced in 100% stable rate. An observation is it can be triggerred quickly when I moves my finger on touchpad, either multi-finger move (flip desktop) or single-finger move.

A recorded example video is uploaded at: https://www.veed.io/view/9d6cb6c1-0607-4b45-a3c1-a5e990e578f1

Additional scenarios

1. The issue can be reproduced when the game is exported as standalone executable.
2. The issue can be reproduced on both Gnome + Xorg, and Gnome + Wayland. (So appears not a Wayland-specific problem)
3. The issue can be reproduced on both Linux kernel 6.4 and 6.5. (I switched kernels to make sure it was not a keyboard driver issue).
4. The issue can be reproduced on my own built Godot master branch, v4.2.beta.custom_build.b662d232a, on the same machine.
5. The issue cannot be reproduced on any of my Godot 3.5.3 game projects on same machine, no matter running within IDE, or exported as standalone binary.
6. The issue can not be reproduced on my Macbook Pro, OS macOS Sonoma 14.1 + Godot 4.1.2 official version downloaded from godotengine.org (version = v.4.1.2.stable.official [399c9dc].
7. I verified Gnome assesibility (repeated key, stick key) are disabled when the issue happens on my Linux box.

Additional information

OS: Manjaro Linux unstable (rolling build)
X11: package = libx11, version: 1.8.7-1
Wayland: package = wayland, version = 1.22.0-1

Steps to reproduce

1. Make sure the system setup is Manjaro Linux + Gnome (not sure whether other Linux distro can reproduce)
2. Open Godot and import project (https://github.com/fuzhouch/interactive-space-tour)
3. Click Run Project button to execute project.
4. Sometimes it's hard to reproduce, try switching desktop with mouse.

Minimal reproduction project

My project (GDScript-based): https://github.com/fuzhouch/interactive-space-tour

The all character moving logic is in Player.gd

[fuzhouch]

Hey folks, I understand such a random issue may be difficult to diagnose by just description. So, if you requires logs or operations to help diagnose, please kindly let me know. I may not be able to response immediately due to time zone difference but will reply in 1-2 days.

[d0x1n]

Hei,

Can you confirm that when the "ghost hand" happens, it hits the _physics_process but not the ui_right / left logic?

[fuzhouch]

Hei,

Can you confirm that when the "ghost hand" happens, it hits the _physics_process but not the ui_right / left logic?

Hi Dorin @d0x1n,

I may not fully understand your meaning of ui_left/ left logic. But if you mean whether Input.is_action_pressed() API returns value, then yes, it does.

My code snippet is pasted below. I added two print() lines for debugging purpose. The move_left and move_right variables immediately calls Input.is_action_pressed(), at the first two statements of _physics_process().

When the issue happens, the "move left" and "move right" messages are printed continuously. That means, _physics_process() is invoked, and then it calls Input.is_action_pressed() API. Meanwhile, the Input.is_action_pressed() API keeps returning true when keyboard is not touched.

Or, if you mean something in C++ layer, could you help providing some steps so I can log it?

My minimal project code path: https://github.com/fuzhouch/interactive-space-tour/blob/main/characters/Player.gd

EDIT 20231030:
I added a video as example: https://www.veed.io/view/19f43e2e-5206-472e-a0b4-612f1e38a340. Just pay attention to the Godot output window at the background. You can see the character immediately starts moving when game is launched, while the "moving right/left" message keeps printing, indicating Input.is_action_pressed() prints true.

You can also see my hands are completely off left/right arrow keys of keyboard, which are "ui_left" and "ui_right".

func _physics_process(delta: float) -> void:
    var move_left = Input.is_action_pressed("ui_left")
    var move_right = Input.is_action_pressed("ui_right")
    
    var direction: float = 0.0
    if move_left:
        print("move left")
        direction = -1.0
        if is_suite_on:
            action_status = STATUS_WALK
        else:
            action_status = STATUS_NOSUITE_WALK
    elif move_right:
        print("move right")
        direction = 1.0
        if is_suite_on:
            action_status = STATUS_WALK
        else:
            action_status = STATUS_NOSUITE_WALK
    else:
        if is_suite_on:
            action_status = STATUS_IDLE
        else:
            action_status = STATUS_NOSUITE_IDLE
    velocity.x = direction * speed
... # More code are skipped
....

[brcontainer]

@fuzhouch

There are some problems that invalidate what you said:

1. Input.is_key_pressed("ui_left") and Input.is_key_pressed("ui_right") shouldn't even work, because the is_key_pressed method expects a enum and not strings. More details in: https://docs.godotengine.org/en/stable/classes/class_%40globalscope.html#enum-globalscope-key

2. Your "Minimal reproduction" is not minimal.

3. As you said using "ui_right" it probably refers to the action builtin, I assume it should be configured like this:

---

@AThousandShips @d0x1n

Focusing on the problem, note that ui_right has 3 possible input types, D-Pad, Left Stick Right and Right key.

So it may not be a problem with Godot, but rather with your keyboard or other software that activates the "D-Pad" or "Left Stick Right"

To create a minimal example, simply create your own actions, isolating the roads into different actions, like this:

And create a single scene with "_process" printing the active keys, example:

extends Node2D


func _process(delta):
	prints("right_physical_or_unicode:", Input.is_action_pressed("right_physical_or_unicode"))
	prints("d-pad-right:", Input.is_action_pressed("d-pad-right"))
	prints("axis-0-plus:", Input.is_action_pressed("axis-0-plus"))

To make things easier, I created a minimal (really minimal 😁) example that you can test and confirm which one is actually being activated (D-PAD or Axis):

Manjaro-input.zip

Once you test the example I sent you, get the results in the godot console and update the "issue".

Note: just to reinforce, the problem is probably not with Godot, but with your keyboard or some specific software that is running on your system.

[fuzhouch]

Hi @brcontainer,

Thanks for your inputs. Let me try and get back to you.

Just to be clear on some points you made.

1. In my code I did use Input.is_action_pressed() not Input.is_key_pressed(). Thus it's not cauesd by string/enum problem. If you checked my code pasted in window. It clearly shows Input.is_action_pressed().
2. During the testing, there's no joystick connected on the machine. So it's a bit confusing to me that why you think a device can activate D-PAD or Axis.

Anyway, let's do this:

Let me create a project based on your Majaro-Input.zip, and make sure there's configuration only on keyboard. I will record a video and get back to you.

[fuzhouch]

Hey @brcontainer,

You are right, appears it's a problem on joystick input. (Thanks!)

I uploaded your minimal project to Github (https://github.com/fuzhouch/manjaro-input) and did a quick try on my machine. To make sure the enviornment clean I managed to do the following:

1. I turned off Steam running on my machine, which may detect joystick devices.
2. I turned off Bluetooth on my machine, which means all external physical joysticks are disconnected.
3. I modified your code a little bit, only print when Input.is_action_pressed() returns true.

The result is shown as video: https://www.veed.io/view/f299612c-5b6e-429e-852a-85db12870a0d?panel=share

A summary below:

1. The issue can be reproduced. It can be triggerred immediately on launched.
2. Only d-pad-right and axis-0-plus are printed. The right_physical_or_unicode is never printed.

So to answer the possible directions you pointed out:

• Is it ghost keyboard or ghost joystick? It should be "ghost joystick".
• Hardware joystick accidentially connected to decice? Given I have turned off Bluetooth (you can see it in video), there should not be any possibility that a Bluetooth joystick accidentially connected to machine.
• Software emulation that may trigger the issue? To make sure we have comparison, I also tried my Godot 3.5.3 game project (also support joystick) on the same machine. It does not have messy input at all. So software emulation is unlikely to be the root cause.

Btw, what confused most is Godot 3.5.3 does not have this issue (I created a minimal project just like yours for Godot3). To be honest, that's actually the biggest reason I think it a Godot 4 bug instead of system configuration bug. I was thinking Godot 3 and 4 should have similar input handling logic, but I can be wrong since I'm not expert on input logic.

Could you suggest any next steps?

[Zireael07]

I strongly suspected some sort of a joystick issue and/or broken joystick drivers from the description. I vaguely remember someone having superfluous inputs due to having a joystick plugged in/the joystick/touchpad drivers misbehaving

Similar issue #62598 (but they had inputs dropped not superfluous inputs appearing) and #16832 (receiving joystick when not focused)

[fuzhouch]

Thanks @Zireael07.

If I want to verify your theory, could you suggest a possible start point, e.g. which kernel module I need to check or udev rules? What information I should collect to help diagnose, e.g. dmesg output? This is the first time I started touching this area, so any starting point is greatly appreciated.

I checked and confirmed I didn't install any thirdparty drivers from either source or AUR.

Meanwhile, if it's a driver issue, there may be two more questions:

1. Why does Godot 3.5.3 project works fine on the same machine? Does Godot 3.5.3 and 4.1.2 uses different input drivers? (which sounds odd to me).
2. How can a driver functioning when there's no joystick connected? (If you check my previous video, you may have seen that I have disabled bluetooth from Gnome settings).

[Zireael07]

Ah, I missed the fact that 3.5 works fine

There was a ton of changes in Godot around input and joysticks specifically - this looks like a regression then

As for 2) that's exactly what a broken driver can do. Another possible culprit is your laptop touchpad, which can also be picked up as a joystick by SDL and can send superfluous events

[fuzhouch]

Thanks @Zireael07. I am just replying.

If I want to verify it's caused by a bad driver, could you suggest a possible start point, e.g. which kernel module I need to check or udev rules? What information I should collect to help diagnose, e.g. dmesg output? This is the first time I started touching this area, so any starting point is greatly appreciated.

Btw, I checked and confirmed I didn't install any thirdparty drivers from either source or AUR.

[fuzhouch]

Btw, I would like add one more context - I don't think I see less frequency on Godot 3 because I don't use it often. In fact, I uses Godot 3 more often than 4 on my machine.

Godot 3 is my main work system for my game, Tsetesg's Adventure which just released until last week. I just started working heavily on Godot 4 since last week, because I need to port my game from 3 to 4. Then I was bugged by the issue.

[fuzhouch]

Oh I forgot one thing -- I actually did try to identify whether this is a driver problem. Yesterday I switched between three kernels, 5.5, 5.6 and 5.1. Same issue happens on all kernels after reboot.

[brcontainer]

And you also made a mistake when writing the IFs (https://github.com/fuzhouch/manjaro-input/blob/e9dd79504421085ffe676a5e49ae88261b340f3c/mcve.gd#L12):

    if Input.is_action_pressed("axis-0-plus"): # <--- ERROR
        prints("d-pad-right:", true)
    if Input.is_action_pressed("axis-0-plus"):
        prints("axis-0-plus:", true)

Should be:

    if Input.is_action_pressed("d-pad-right"):
        prints("d-pad-right:", true)
    if Input.is_action_pressed("axis-0-plus"):
        prints("axis-0-plus:", true)

After correcting MCVE, test and see if it is indeed the Axis that is being fired randomly, then update the ISSUE title.

---

Will your game only run on computers?

If it's only going to run on computers or browsers, then you won't need the axis or the d-pad (if the intention is to just use the standard keyboard), then configure your own input actions, this will temporarily solve the problem.

I personally never use the builtin actions (with ui_ prefix), as I prefer to configure the project manually instead of using something that may change in the future.

[fuzhouch]

Hi @brcontainer

Oh you are my hero! Thank for pointing out -- Corrected and here you go - https://www.veed.io/view/1152ba86-e6c4-4ff1-8d5f-54f81afcc103?panel=share

It's on the same setup - Shutdown Bluetooth, close Steam, no other services like KDE Connect. From the output result it seems the only ghost is from axis-0-plus, no d-pad-right. So looks like d-pad is safe.

Will your game only run on computers?

Unfortunately the answer is no. The only reason I migrate from Godot 3.5.3 to Godot 4 is to port my game to Nintendo Switch. Running on Godot 4 is a requirement from my publisher.

Btw, I used to think this issue low priority, as Switch does not have keyboard. But now it appears to be a bigger issue to me, because D-pad/axis support is a must when I deliver the game. And axis seems more important due to Switch's gamepad layout.

I personally never use the builtin actions (with ui_ prefix)

Same with you. My project also defines my own input definitions (see screenshot below). But has you see, the issue can be reproduced on all three projects, no matter what name is.

[fuzhouch]

Hi folks, @brcontainer @Zireael07 @d0x1n ,

I suddenly get a new finding that should narrow down the investigation. The issue can be stably reproduced.

The trick is, when I scroll the right edge of trackpad, it generates axis input. If I click any part of the trackpad, the input stops. I've uploaded a new video to show it: https://www.veed.io/view/a427a61e-b231-4390-a5d3-701ba921072b?panel=share

That explains why I hit it so frequently. During development I mostly use keyboard on my laptop to play. I set key to WSAD (direction) and JKL (hide,fireball and jump). With this setting, my palm usually touches right edge of trackpad. Then the axis input is generated.

So @Zireael07 made a point that closesd to root cause. Why does Godot 4 treats trackpad as axis? Especially, I use double finger scrolling in my Gnome desktop. And one more thing -- even when debug window does not grab focus, it still receives axis input.

Morever, I also tried it in Godot 3.5.3 by mimicing @brcontainer 's Manjaro-Input project. Godot 3.5.3 does not respond to the right-edge scrolling at all. Is it a design change btw 3 and 4?

[brcontainer]

Ok, now update the issue title, to explain that the problem is with "Joypad Axis", and let's wait for the next investigations.

[brcontainer]

@fuzhouch I downloaded Godot3.5 and noticed a difference in the ui_right action:

1. In Godot4 we have the entries "Axis0+", "D-Pad Right" and "Right Physical or Right Unicode" for the ui_right input map.
2. In Godot3.5 we only have the "D-Pad Right" and "Right Physical or Right Unicode" entries for the ui_right input map.

In other words, this is probably why you didn't notice the problem in Godot3, because it wasn't configured to use Axis.

I created an MCVE for you to test in Godot3 on your Manjaro, test it and tell us if Axis is also printed in the Godot Console:
Manjaro-input-godot3.5.zip

[fuzhouch]

Sure, man @brcontainer, but this time I don't agree with you. :(

I have already verfied on a mimic app mentioned before for Godot 3.5.3. The code is uploaded to Github as well: https://github.com/fuzhouch/manjaro-input-3. As you suggested long ago, I have stopped using ui_* in all tests mentioned above, but created settings to mimic your manjaro-input.zip project.

Since you asked, I created two videos to compare the result. You should be able to see the two IDEs are running on same laptop at same time.

Godot 3.5.3: https://www.veed.io/view/98a03642-dbcf-4715-80cf-fb03ab1a77c6?panel=share
Godot 4.1.2: https://www.veed.io/view/dbfacd1b-e2fe-490a-bf26-7c5301bf3c07?panel=share

With the clips we can clearly see Godot 3.5.3 does not receive axis-0-plus event, while Godot 4 still receives when I slide my fingers on right edge of trackpad.

[brcontainer]

Sure, man @brcontainer, but this time I don't agree with you. :(

I have already verfied on a mimic app mentioned before for Godot 3.5.3. The code is uploaded to Github as well: https://github.com/fuzhouch/manjaro-input-3. As you suggested long ago, I have stopped using ui_* in all tests mentioned above, but created settings to mimic your manjaro-input.zip project.

Since you asked, I created two videos to compare the result. You should be able to see the two IDEs are running on same laptop at same time.

Godot 3.5.3: https://www.veed.io/view/98a03642-dbcf-4715-80cf-fb03ab1a77c6?panel=share Godot 4.1.2: https://www.veed.io/view/dbfacd1b-e2fe-490a-bf26-7c5301bf3c07?panel=share

With the clips we can clearly see Godot 3.5.3 does not receive axis-0-plus event, while Godot 4 still receives when I slide my fingers on right edge of trackpad.

The process of elimination exists in different contexts, such as mathematics, medicine, and the judiciary. In simple terms, this process that I have applied so far is what helped to detect that the problem is specifically in Axis and the last test I sent you is precisely to confirm whether it is a Godot4 bug or an external factor. As I said:

... this is PROBABLY why you didn't notice the problem in Godot3 ...

It probably indicates a possibility, this is not even a statement of fact. That's why I asked you to test the Godot3 MCVE that I created. It was thanks to the last test that we were able to verify the possible problem with Godot4.

👍👍👍

[fuzhouch]

No problem I totally understand. Thanks for keeping the feedbacks to me.

Btw, just curious, is it possible that other folks to reproduce this issue? I'm afraid it's unreasonable to diagnose via video.

[brcontainer]

@fuzhouch I couldn't reproduce the problem, I'm trying a different technology than Godot to create another MCVE to send you, something that captures any input, so we can identify which input on your Manjaro is accidentally mapped to the same as the "Joypad Axis". Basically it's a script that will capture everything related to the inputs executed on your Manjaro, I'm still coding, it may take some time.

[fuzhouch]

@brcontainer I see. Just take your time. And a quick note - I will be out tomorrow for meeting. So response may be slow in the next day. Just send me script when you are ready. I will get back to you ASAP.

[fuzhouch]

Hey folks, I believe I can confirm this issue is a dup of known issue, #59250. By printing all my input devices and events from my local machine, I can confirm my Trackpad is recognized by Godot 4 as a gamepad with device ID == 0. I also found a workaround from the original report (Thanks @vysker).

@brcontainer Let's close this issue. The fix should have been in master branch already. Let's wait for upcoming version for an official fix.