HelloThisIsFlo
USB Device resetting and doesn't come back on quit
Hello! DeckPad works great for me but I am having one small issue and wonder if anyone else has any ideas?
I think this might be similar to closed Issue #9, so apologies for re-opening. It's happening on my deck as well. Feels like it might be a VirtualHere bug but I'm not sure.
Before launching DeckPad, steam controller is visible in various places:
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 13d3:3553 IMC Networks Bluetooth Radio
Bus 003 Device 002: ID 28de:1205 Valve Software Steam Deck Controller
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
(deck@steamdeck ~)$cat /proc/bus/input/devices
I: Bus=0003 Vendor=28de Product=1205 Version=0111
N: Name="Valve Software Steam Deck Controller"
P: Phys=usb-0000:04:00.4-3/input0
S: Sysfs=/devices/pci0000:00/0000:00:08.1/0000:04:00.4/usb3/3-3/3-3:1.0/0003:28D E:1205.0001/input/input6
U: Uniq=MEDA21501215
H: Handlers=sysrq kbd event5
B: PROP=0
B: EV=100013
B: KEY=e080ffdf01cfffff fffffffffffffffe
B: MSC=10
I: Bus=0003 Vendor=28de Product=1205 Version=0111
N: Name="Valve Software Steam Deck Controller"
P: Phys=usb-0000:04:00.4-3/input1
S: Sysfs=/devices/pci0000:00/0000:00:08.1/0000:04:00.4/usb3/3-3/3-3:1.1/0003:28D E:1205.0002/input/input10
U: Uniq=MEDA21501215
H: Handlers=event7 mouse0
B: PROP=0
B: EV=17
B: KEY=30000 0 0 0 0
B: REL=1943
B: MSC=10
(deck@steamdeck ~)$ lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 13d3:3553 IMC Networks Bluetooth Radio
Bus 003 Device 002: ID 28de:1205 Valve Software Steam Deck Controller
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
I am able to see the touchpad data streams if I do something similar to:
sudo cat /dev/input/by-id/usb-Valve_Software_Steam_Deck_Controller_MEDA21501215-if01-mouse
Then I launch DeckPad and all the entries disappear when VirtualHere takes over the capture. The device works great remotely.
Quit DeckPad, and the entries momentarily re-appear, but immediately disappear again.
[sudo] password for deck:
[Tue Mar 12 11:49:59 2024] input: Valve Software Steam Deck Controller as /devices/pci0000:00/0000:00:08 .1/0000:04:00.4/usb3/3-3/3-3:1.0/0003:28DE:1205.0006/input/input26
[Tue Mar 12 11:50:00 2024] hid-steam 0003:28DE:1205.0006: input,hidraw0: USB HID v1.11 Keyboard [Valve S oftware Steam Deck Controller] on usb-0000:04:00.4-3/input0
[Tue Mar 12 11:50:00 2024] usb 3-3: usbfs: process 5385 (op33) did not claim interface 2 before use
[Tue Mar 12 11:50:00 2024] input: Valve Software Steam Deck Controller as /devices/pci0000:00/0000:00:08 .1/0000:04:00.4/usb3/3-3/3-3:1.1/0003:28DE:1205.0007/input/input27
[Tue Mar 12 11:50:00 2024] hid-steam 0003:28DE:1205.0007: input,hidraw2: USB HID v1.11 Mouse [Valve Soft ware Steam Deck Controller] on usb-0000:04:00.4-3/input1
[Tue Mar 12 11:50:00 2024] usb 3-3: reset full-speed USB device number 2 using xhci_hcd
[Tue Mar 12 11:50:00 2024] hid-steam 0003:28DE:1205.0008: hiddev96: USB HID v1.11 Device [Valve Software Steam Deck Controller] on usb-0000:04:00.4-3/input2
[Tue Mar 12 11:50:00 2024] hid-steam 0003:28DE:1205.0008: Steam Controller 'FVAAxxxxxxxx' connected
[Tue Mar 12 11:50:00 2024] input: Steam Deck as /devices/pci0000:00/0000:00:08.1/0000:04:00.4/usb3/3-3/3 -3:1.2/0003:28DE:1205.0008/input/input28
[Tue Mar 12 11:50:00 2024] hid-steam 0003:28DE:1205.0009: hidraw3: USB HID v1.11 Device [Valve Software Steam Deck Controller] on usb-0000:04:00.4-3/input2
[Tue Mar 12 11:50:00 2024] cdc_acm 3-3:1.3: ttyACM0: USB ACM device
[Tue Mar 12 11:50:00 2024] hid-steam 0003:28DE:1205.0008: Steam Controller 'FVAAxxxxxxxx' disconnected
I'm not sure if VirtualHere puts logs anywhere but will keep looking. Otherwise DeckPad works great and normal function is restored after a reboot. I did have the issue where the touchscreen input isn't registered, but that was solved by adding the default action set per Issue #1 .
Some more info:
Resetting the USB controllers by echoing the bus ID to /sys/bus/pci/drivers/xhci_hcd/unbind then bind causes the controller to disconnect and reconnect (you can see it happening in dmesg) but it still doesn't get picked up by Steam.
Re-launching DeckPad using the touchscreen actually still works perfectly!
VirtualHere is definitely closing - I can see the process matching the virtualhere_pid file in htop, and it disappears as expected on quit.
No worries at all for re-opening. I closed the other one because the person experiencing the issue had factory reset their steamdeck, so we couldn't reproduce. If it's happening to you too, and others as well apparently, it's good you filed an issue.
Also, I appreciate the investigate you've done already. I'm just looking at this now, as you can see from the pace of bug-fixes I don't have much time to dedicate to this project, but I'll spend some time here and there to try to fix this one. No ETA obviously.
I'm re-installing deckpad on my steam deck atm, after the latest update (haven't used in a while), I'll see if I can reproduce locally.
Also regarding #1, I've now added the instructions to the readme ✅, thanks for letting me know it solved the problem for you too 👍
Using this at the end of the script restores control on my deck (oled)
function reset_controller {
echo "0000:04:00.4" >/sys/bus/pci/drivers/xhci_hcd/unbind
sleep 1
echo "0000:04:00.4" >/sys/bus/pci/drivers/xhci_hcd/bind
}
System Update Channel: Stable
OS Version: 3.5.19
OS Build: 20240422.1
Kernel Version: 6.1.52-valve16-1-neptune-61
As far as my investigation as gone, 0000:04:00.4 is the address of usb controller that the built-in steam controller is connected to on the oled steam deck. As far as I can tell, the built-in steam controller is the only device handled by usb controller 0000:04:00.4. The address 0000:04:00.3 is another usb controller that seems to handle everything connected to the usb-c port on the steam deck.
There is a caveat though, i'm not entirely sure if these addresses are stable. If the usb controllers switch addresses for some reason, the script would reset the wrong usb controller, potentially interfering with other devices plugged into the steam deck. I don't have an lcd deck, so I'm not able to see if this works on it. Hopefully the lcd deck also uses the same address or has another usb controller dedicated to just the steam controller.
Perhaps a better solution would locate the steam controller first, and select the associated usb controller, or maybe there is another way to restore the steam controller after virtual here releases it.
Thanks for the explanation @joshwiker14.
Yes if we can derive it from the name, similarly to how I get the TOUCHSCREEN_ID, then it'd be a nice addition. However, I wouldn't be comfortable hardcoding the ID, for the same reasons you mentioned: I don't have access to a Steam Deck LCD anymore, and I'm also not sure the id is consistent across all Steam Decks.
Maybe I'll look into it at some point, but you're very welcome to submit a PR.
is there any progress on this? Because I'm on the LCD steam deck and am having the same issue of the deck not resetting the inputs. If y'all know what I should look for I can give data from my deck.
Using this at the end of the script restores control on my deck (oled)
function reset_controller { echo "0000:04:00.4" >/sys/bus/pci/drivers/xhci_hcd/unbind sleep 1 echo "0000:04:00.4" >/sys/bus/pci/drivers/xhci_hcd/bind }System Update Channel: Stable OS Version: 3.5.19 OS Build: 20240422.1 Kernel Version: 6.1.52-valve16-1-neptune-61
I tried this fix and it also worked for my LCD Steamdeck without any changes to the "0000:04:00.4" address.
@vaughnmonkey I have made pull request #19 containing this fix, though it finds the id for the USB controller instead of hardcoding the address. Can you verify that works on your lcd deck? Perhaps @HelloThisIsFlo will merge it after more testing.
Hi all,
After months of postponing, I finally got to it, and I wanted to test if this was working as expected ... but unfortunately I couldn't get Deckpad to run at all. Even on the main branch.
I haven't used it for months, so I'm on a fresh setup, I've followed my own README, but it never appears on the PC side of things.
Anyone experienced the same issue by any chance? Do you know if there's a fix?
Hi all,
After months of postponing, I finally got to it, and I wanted to test if this was working as expected ... but unfortunately I couldn't get Deckpad to run at all. Even on the main branch.
I haven't used it for months, so I'm on a fresh setup, I've followed my own README, but it never appears on the PC side of things.
Anyone experienced the same issue by any chance? Do you know if there's a fix?
I just tested, and i experienced the same issue. I was able to fix it by allowing tcp port 7575 through the steamdeck firewall. I have noticed some steam deck upgrades resetting the firewall configuration.
Ah cool. Thanks for the update @Stormageddon0
Unfortunately, I tried sudo firewall-cmd --add-port=7575/tcp
But it says it's already enabled: Warning: ALREADY_ENABLED: '7575:tcp' already in 'public'
And it doesn't work.
Did you do anything else?
hmm...I have tweaked various things like binding different firewall zones to different wifi connections,I also have a firewall rule for the vh usb client on my windows machine. sadly i dont currently have time to reset my steam deck and test for at least a few days. in the mean time, turning on firewall logging or inspecting the wifi traffic with wireshark may be helpful.
@Stormageddon0 That's perfectly fair. Thanks for the input nonetheless.
Maybe the rule on the client side could be something to explore, I'll try this out when I can give it some time
@HelloThisIsFlo I have not had issues connecting with virtualhere while using the default 'public' firewall zone so far...