Unresponsive Touchscreen
HelloThisIsFlo opened this issue · 25 comments
Problem
Some people reported the touchscreen is unresponsive. This is problematic because it means Deckpad can't exit properly, and that cause other issues.
Ideas
- Maybe the touchscreen has a different name on different SteamDecks?
I think I found the issue!
I did most my testing via SSH and I found I needed to explicitly set the DISPLAY envvar to be able to use xinput. But the value of DISPLAY is not always the same if we are locally on the machine vs accessing it via SSH. So, sometimes DISPLAY would point to the wrong value, and xinput would fail.
I then found out that the DISPLAY envvar should already be set when running konsole, so there's nothing to do to use xinput.
So I just removed the line below in bad9411
export DISPLAY=:1
As we can see I am no bash expert and I'm mostly hacking things around until they work 😅
Hopefully that fixes it 😊🤞
So apparently the fix didn't fix it. Unfortunate.
I have reports from reddit as well as #2
It's a very difficult issue to fix because it works very consistently on my SteamDeck. So, since I can't reproduce, I'm never sure if the "fixes" actually fix anything 🤔
It may be due to Steam OS 3.4. I haven't done this update yet, so maybe it breaks something ... but that's unlikely. Still, if that's the case, I'll fix it once I'll update.
@imstupidwithlinux Could you try the following?
- Run this command in Konsole and let me know what the result is
If it works (it fails if it returns
xinput --listUnable to connect to X server), then maybe could you try:- Get the touchscreen ID
This will give you a number, let's call it
xinput --list 2>/dev/null | grep -i -m 1 'touch' | grep -o 'id=[0-9]\+' | grep -o '[0-9]\+'ID - Query the state
(put the
xinput --query-state IDIDyou found on the step before)
- Get the touchscreen ID
It would be helpful if you could post the results here
It's not like the touchscreen doesn't work, it works but the script doesn't stop. Like I said it opens up the on screen keyboard when tapping on it.
And after I got it installed I experienced softlocked sleep mode, either it wouldn't go into it or it tries to and get a blank black screen where the steam button can still open the side menu, I don't want to blame this on you as I haven't installed this to my now factory reset deck
Oh, that's unfortunate, but yes it's 100% the script that causes this. There is a warning about it in the Installation instructions, with some simples steps to fix it: https://github.com/FlorianKempenich/Deckpad#setup-instructions
It's unfortunate you didn't see it, maybe I should make it more prominent somehow 🤔 Because yes, it's a pain to factory reset the deck for that.
What I mean by the touchscreen doesn't respond is that, yes the deck detects the touch, but Deckpad doesn't respond to the input. That's why the keyboard shows up instead of the exit and cleanup process being initiated
Yeah, having the same problem. The touch screen doesn't register the tap on "tap here to quit! > 0 < " so the whole thing is kinda borked. Would not advise running this script as is.
Edit - tried plugging in usb mouse and keyboard on a dock and clicking the >0< to close just gives [[M -1 text in the konsole, using your closing commands worked in a separate konsole, thanks for providing those but they don't stop the deck's button inputs being subverted and unresponsive so you still need to factory reset to clean everything up again.
Tried the steps you asked of LinuxUser above,
xinput command just doesn't work at all in the running exe or a separate konsole.
Overall your script works but won't let you close out of it on a currently upto-date deck. I would suggest adding a "close me".sh in the folder case of emergency so people have another avenue to end it. And hardbake holding R1+R2 + L1+L2 for 10 seconds to terminate the program cleanly and have this mentioned on the running screen too so people know how to close it. I appreciate you put a lot of time into this and I'm impressed it's working, just not being able to close the program is poor planning and form, sorry.
Hey,
Don't have much time to answer in details, but don't factory reset!. Please read the message I posted just above, as well as the 'Setup Instructions'.
It's unfortunate the script doesn't work for some people, but of course it is offered with almost no guarantees of any sort. All I guarantee is that it won't break your steam deck, just run the commands in the https://github.com/FlorianKempenich/Deckpad#setup-instructions
I've copy pasted them here:
sudo chmod 666 /sys/class/backlight/amdgpu_bl0/brightness
sudo systemctl unmask sleep.target suspend.target hibernate.target hybrid-sleep.target >/dev/null 2>&1
This will revert everything and the steam deck will be as new 👍
The first command re-enable brightness control, the second re-enable sleep
For me it did revert to its normal state after a reboot so I've never use this command
Quick update:
I updated to Steam OS 3.4, and the touchscreen issue still isn't there on my device. It works great. So I still have no idea what the problem is on some people's Steam Deck 🤔
However, when launching Deckpad, the window is now tiny on Steam OS 3.4. The fix is easy, I've updated the README.md and added a note at the top.
In short you just need to add --fullscreen to the launch options
Just as a note but its the same issue for me. Clicking on the 'exit' location instead just opens up the keyboard.
Hey,
What might happen is that the click is registered outside of the target, and if so, the keyboard will pop yes. Then you can just close it and try again.
To make hitting the target much easier, I've increased the active area by a lot. Hopefully that helps, let me know if it worked 🙂
As a reminder, to update the project, just run
cd ~/Deckpad/ && git pull
your initial assumption that touchscreen has a different name on different Decks seems to be true. in your script you're looking for the keyword "touch", which isn't present in xinput's output at least on my device and this guy's Deck (both of us has it named FTS3528). so I guess the script just fails to proceed further since the variable TOUCHSCREEN_ID simply isn't set. I changed it to TOUCHSCREEN_ID=13 (which is my touchscreen's ID) and it did quit as expected. SteamOS 3.4.6
UPD.: as I left this comment and went to play some games, I encountered the issue that it once again has stopped working. long story short, desktop mode on Deck seems to use Xorg, whereas gaming mode uses Wayland. that's why you went for grepping "touch" in your script, and that's why I see FTS3528 as a descriptor of my touchscreen. so my solution was to change this line to TOUCHSCREEN_ID=$(xinput --list 2>/dev/null | grep -i -m 1 'FTS3528' | grep -o 'id=[0-9]\+' | grep -o '[0-9]\+' | head -1) and launch Deckpad from desktop mode
Intersting @ElijahLaMoon, I'll check if I also have this FTS3528 reference on mine, if so I'll update Deckpad with your version of TOUCHSCREEN_ID.
One thing I didn't understand is: What's the difference between Xorg and Wayland from the point of view of the xinput command, does it return different results in these 2 different contexts?
One thing I didn't understand is: What's the difference between Xorg and Wayland from the point of view of the
xinputcommand, does it return different results in these 2 different contexts?
in fact, yes it does. in gaming mode xinput --list returns
WARNING: running xinput against an Xwayland server. See the xinput man page for details.
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ xwayland-pointer:10 id=6 [slave pointer (2)]
⎜ ↳ xwayland-relative-pointer:10 id=7 [slave pointer (2)]
⎜ ↳ xwayland-pointer-gestures:10 id=8 [slave pointer (2)]
⎜ ↳ xwayland-touch:10 id=10 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ xwayland-keyboard:10 id=9 [slave keyboard (3)]
whereas in desktop mode it returns
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech Wireless Receiver Mouse id=9 [slave pointer (2)]
⎜ ↳ Valve Software Steam Controller id=13 [slave pointer (2)]
⎜ ↳ FTS3528:00 2808:1015 id=17 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Power Button id=8 [slave keyboard (3)]
↳ Dell KB216 Wired Keyboard id=10 [slave keyboard (3)]
↳ Dell KB216 Wired Keyboard System Control id=11 [slave keyboard (3)]
↳ Dell KB216 Wired Keyboard Consumer Control id=12 [slave keyboard (3)]
↳ Valve Software Steam Controller id=14 [slave keyboard (3)]
↳ acp5x Headset Jack id=15 [slave keyboard (3)]
↳ FTS3528:00 2808:1015 UNKNOWN id=16 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=18 [slave keyboard (3)]
so here I see why you went for grep "touch" in the first place. however, for unknown reason to me xinput --query-state 10 seems to always return 0 on both evaluators no matter what I do with the touchscreen. that's why I couldn't quit the program in gaming mode. works fine in desktop mode though
Hi @ElijahLaMoon,
Thanks for the explanation. I tried it on my steam deck and I have the same as you: xwayland-touch:10 in gaming mode and FTS3528 in desktop mode.
So yes, I see why it doesn't work on desktop mode in the current state. Your workaround is good for that use case. But what I'm more confused is why it doesn't work in gaming mode for you, considering you have the same xinput --list output as I do.
Could you try to run this
xinput --list
sleep 2
xinput --query-state 10
sleep 5
exit 0
And at the sleep 2, before xinput --query-state is called, touch the screen somewhere. If you don't touch the before xinput --query-state it will return 0, on mine as well
How about just querying for either of the devices like this?
TOUCHSCREEN_ID=$(xinput --list 2>/dev/null | grep -i -m 1 'touch\|FTS3528' | grep -o 'id=[0-9]\+' | grep -o '[0-9]\+')
is this issue still live? really dont wanna brick my steam deck :/
@olee
That would probably work, I'd have to test it in both Gaming and Desktop mode. But ideally, I'd like to fix this for the gaming mode as this is how the tool is intended to be run. So adding compatibility to the Desktop mode is not my priority.
Also, the other issue you opened has a great idea for how to exit Deckpad: #8 If we manage to implement it, it would circumvent the need for any touchscreen interactions.
@JackDotJS It is (still live), just updating very slowly.
Whenever someone shares a suggestion, it takes me about 1-2h to try it out. Between regaining the context of the problem, setting up the environment, testing it out, etc... Bash and capturing physical device interactions is really not my cup of tea.
So, progress is slow, but from time to time I do give it a look and try things out 🙂
This project won't (most likely, can't be held responsible) brick your device, I don't see how it could.
It may leave it in an undesirable state, but I have instructions on the README on how to fix that state. That being said, with such experimental projects I would recommend you don't use it if you don't quite understand how it works, or how to revert the changes it does.
I FIXED IT!!!
In Game mode, from the Home screen, open the Deckpad App screen. Tap on controller settings. Edit Layout. Action Sets. Edit Icon next to "Default". Always On Command. System tab. Touchscreen Native Support. Back out. Launch Deckpad. Tap on the exit O.
Profit.
It was the controller settings the whole time. Touchscreen wasn't enabled fully since we have to basically build our own Non-Steam App for this, and the default controller settings don't include Touchscreen being enabled for Native Linux apps, like Konsole.
Oh WOW @Jeoshua, I think you might have found it! 🎉
I checked on Steam Deck, and indeed this was activated!!
I have no recollection of changing this setting, and some users seem to not have issue. So it seems on some system it's enabled by default, on others no. Seems surprising, but hey if that solves the problem, it's all that matters!!
I'll update the README in the next few days (or weeks, I'm quite busy at the moment), and I'll update people on reddit too.
Thanks a lot for your finding! I think it will help a lot of people!
I'm keeping this issue open until I've made the changes to the README
I've done a bit of work customizing my Deck before trying Deckpad, so it's possible that some combination of the things I (and others) have tried as far as customizations in the past has changed our default controller settings for new apps.
I also noticed an issue where the preparation script had an "exit 0" right before running a few more commands. That might be intentionally moving the logic to another part of the scripts, but I also removed that line to make it process the other parts of the script when installing.
