search

ValveSoftware / steam-for-linux

Issue tracking for the Steam for Linux beta client
4.25k stars 175 forks source link

Remote Linux Client Controllers Not Visible on Steam Remote Play Together #6951

Closed ArtificialNebulae closed 3 years ago

ArtificialNebulae commented 4 years ago

Read First!

If you're affected by this bug, please click the :+1: below this bug report, and feel free to hit subscribe on the right. Do not add an additional post unless you have new information, such as if you find a workaround, you notice a functionality change, or if the issue appears to be fixed.

Summary

When attempting to start a Remote Play Together session, the host computer is unable to detect any remote Linux client controllers. Unknown whether this issue affects Windows and/or OSX clients as well (Update 2020.03.07: after checking the In-Home Streaming Bug Reports forum, there is one topic reporting the same issue, though no specific OS is specified: https://steamcommunity.com/groups/homestream/discussions/1/1749023631421591910/) Tested with both Linux and Windows hosts; only Linux clients were tested.

Your system information

Please describe your issue in as much detail as possible:

When attempting to start a Remote Play Together session, host does not see controllers from Linux systems. Mouse+Keyboard works (as well as M+K emulation). Both Linux systems (Ubuntu 18.04.4) had sufficient access to /dev/uinput (777 for both machines). Linux Client A (also Linux Host) has both an XBox 360 and Steam controller. Linux Client B has a PS3 controller. Windows host has a PS4 controller.

Tested with Linux Host to Linux Client on Broforce (274190), and Windows Host to 2x Linux Client on Tales of Vesperia: Definitive Edition (738540). In Broforce, controller only worked when M+K was enabled, and stopped working when M+K for client was disabled (which indicates controller was only working via M+K emulation). In Tales of Vesperia, only Windows host controller appeared; Player 2 was shown with M+K input options only (game did not allow changing to controller input for Player 2), and no input options for Player 3 were available (M+K or otherwise).

End snippet from streaming_log.txt from Broforce: https://gist.github.com/ArtificialNebulae/b52802040f258edc84f4b4be4b3594f3

Steam In-Home Streaming to Steam Link on local network for confirmed working with XBox 360 controller on Linux Host machine as of March 18 Beta. Also tested and confirmed working with Steam Remote Play on an Android phone using the Steam Link app.

Steps for reproducing this issue:

  1. Host a Remote Play Together session from Windows or Linux
  2. Invite Linux clients to join
  3. Host will only see local controllers; all remote Linux clients will only show mouse and keyboard available on host Remote Play GUI, and will not be able to perform controller actions in-game unless supported via M+K emulation.
ArtificialNebulae commented 4 years ago

To not clutter the original report as much, I'm going to put attempted workarounds I've seen posted around here:

  1. Host disconnects a second controller (which was supposed to make the controller switch to the remote client): does not work.
ArtificialNebulae commented 4 years ago

Re-tested March 18: Steam Beta still affected; stable release appears to work again.

ArtificialNebulae commented 4 years ago

Re-tested with today's stable client: mixed bag; some games are having trouble detecting my 360 controller with my computer as a client; when hosting games my controller is working fine. Steam controller appears to work for games that support it.

Tales of Vesperia (Windows host): 360 controller is detected by the game, rumble works, however input doesn't do anything on the server. Another Linux client using a PS3 controller has the same issue when joining the same Remote Play session. Steam controller appears to work. Divinity: Original Sin: 360 controller is detected by the game, but inputs do not affect the game. Steam controller does not appear to work. A Hat In Time (Linux host w/ Steam Play): both 360 controller and Steam controller are detected in-game, but neither work when co-op is enabled.

ArtificialNebulae commented 4 years ago

Re-tested with April 3 beta (second one, after Windows Xbox controller changes were reverted per the official changelog). Issue is still present; no other improvements or regressions were noted.

Charadon commented 4 years ago

Having the same problem, this really shouldn't be an issue

Charadon commented 4 years ago

I managed to fix this issue by using installing some udev rules (Found here: https://gitlab.com/Fabish/game-devices-udev) and after installing it, me and my friend could successfully play with controllers working

Hetti commented 4 years ago

I managed to fix this issue by using installing some udev rules (Found here: https://gitlab.com/Fabish/game-devices-udev) and after installing it, me and my friend could successfully play with controllers working

Probably no xBox controller?

Charadon commented 4 years ago

Even the xbox controller didn't work, which is weird, because even before adding those udev rules, he could use his controllers on emulators, but steam could absolutely not see any controllers, and nor would any game launched from steam be able to use the controllers.

Hetti commented 4 years ago

I gonna try to write an udev rule for xBox controllers and see if this would work. My problem is that the Controllers of the Linux Client show up in the Remote Play Interface of the host, but no inputs received by the host from the client.

Hetti commented 4 years ago

I've just tested it: I could neither reproduce your success with the udev rule with a Logitech F310 Gamepad as Linux Client Nor could I get the other Linux Client running with a udev rule for the xbox controller.

I tried the following udev rule for xbox Controller, but can't say if it's correct. It could be that something is wrong!

# Xbox One Controller; USB
KERNEL=="hidraw*", ATTRS{idVendor}=="045e", ATTRS{idProduct}=="02d1", MODE="0660", TAG+="uaccess"

We gonna need to wait until Valve patches this :(

Charadon commented 4 years ago

It's not just the udev rule that one repository does. It also does something related to making a config file called uinput.conf in /etc/modules-load.d/. Out of curiousity, what Distro are you on? I'm on Manjaro, and my friend was on OpenSUSE Tumbleweed

kryksyh commented 4 years ago

Having the same problem, this really shouldn't be an issue

Are you sure you were having exactly this issue we are discussing? While I have no problem using any controller locally in any native game nor steam itself I am unable to play in RemotePlayTogether mode with any controller.

Using rules provided by the repo https://gitlab.com/Fabish/game-devices-udev doesn't make any difference. As far as I understand those rules are used to set up correct access permissions upon connection, which are already correct. And looking in rules.d I see that there is a bunch of rules provided by steam package doing mostly the same as the rules by Fabish.

Probably this issue is related to controller handling in the steam itself and is not related to udev.

kryksyh commented 4 years ago

By the way, can this issue be distro related? I am using Arch Linux.

Charadon commented 4 years ago

Edit: Made an assumption based on file-name. Steam package does indeed include these rules on arch linux

As for if I think i was having the same issue, it's hard to tell. But it matches some symptoms, you could see the controller in remote play, but it couldn't receive any inputs. Out of curiosity, do you have the udev rules on both the server and client?

ArtificialNebulae commented 4 years ago

I appreciate everyone's comments; hopefully they'll be helpful to Valve for tracking down the cause of the issue.

@Charadon What controller are you using? I think this issue is specific to controllers that do not use the hidraw device kernel, which is what those rules target. My Steam controller works fine on Remote Play Together, and I know the device permissions are correct since I've installed the steam-devices package.

In regards to your later comment, I have mainly been testing with a Windows host (if it was a Linux host, I would check permissions of /dev/uinput first). The strange thing is, is that rumble from the remote game appears to work, but button inputs don't, which I mentioned in an earlier comment.

@Hetti That rule will never get triggered, given that the 360 controller (and possibly XBone controller, which I don't know about since I do not own one) uses the kernel's xpad driver instead of the hidraw driver. The equivalent rule would be something like:

# Xbox One Controller; USB
KERNEL=="input*", ATTRS{idVendor}=="045e", ATTRS{idProduct}=="02d1", MODE="0660", TAG+="uaccess"

If you want to verify that permissions are not the issue, make sure that device permissions (probably /dev/input/js[0-9]) are either 666 or better. Some systems may set the device file group to input; adding that group to your user account could be safer than a blanket permissive chmod.

Again, I don't think this is necessarily a device permissions issue, as I've tinkered with controller device permissions to no avail myself.

@kryksyh Given that between this issue and the possible duplicate #7052, I think we've established that this affects Ubuntu 18.04.4, Manjaro (Arch), and OpenSUSE, so it seems rather unlikely to be a distro-specific issue.

kryksyh commented 4 years ago

The strange thing is, is that rumble from the remote game appears to work, but button inputs don't

Yes, it's the same with my setup. Local Linux and remote Windows 10, remote host detects my gamepad, it rumbles when clicked on, but no inputs are detected.

My Steam controller works fine on Remote Play Together

I can confirm this also.

kryksyh commented 4 years ago

Ok, I have tested a bunch of controllers with no positive result whatsoever:

  1. PS3 Sixaxis over USB
  2. PS3 Sixaxis over Bluetooth
  3. Xbox 360 wired
  4. Logitech PS3 Chillstream
  5. Gamecube adapter with Gamecube controllers
  6. Nintendo Switch Joycon with hid-nintendo driver

Only Steam Controler works.

kryksyh commented 4 years ago

I guess it should be noted that parsec is working just fine.

Hetti commented 4 years ago

The strange thing is, is that rumble from the remote game appears to work, but button inputs don't

Yes, it's the same with my setup. Local Linux and remote Windows 10, remote host detects my gamepad, it rumbles when clicked on, but no inputs are detected.

The strange thing is, is that rumble from the remote game appears to work, but button inputs don't, which I mentioned in an earlier comment.

Can confirm this also. Rumble gets triggered on Clients xBox 360 Controller by deactivating Client Controller on the Host

I also tried Linux Client on Linux host with Arch/Manjaro.

nolddor commented 4 years ago

Affected by this bug. OS Debian Bullseye kernel 5.5.0-2-amd64 using current stable linux Steam client

I'm unable to play with my friend if he (Win10) host the game. My keyboard and mouse are detected and works OK. He is able to rumble my controller remotely. Both controllers are detected if I host the game. Everything is fine with this setup.

Regards

ollieh commented 4 years ago

Also experiencing this on Archlinux, kernel 5.6.3-arch1-1, steam client version built on Apr 27.

Window 10 host, Archlinux guest, M+K from guest works but no controllers except steam controller. Tried two logitech F310 controllers, and some no-brand controllers from Argos, none work, although steam controller works.

These controllers work in other games and the big picture menu, as well as using tools like jstest and sdl2-jstest, so both the older joystick api and the newer evdev-based api are working.

blastermaster77 commented 4 years ago

I have the same problem, I play on Ubuntu 20.04 LTS and my brothers in Windows 10, whit remote play their keyboard is detected but not their controllers, they use an xbox one controller and a dual shock 4, I tried with navitive games and proton games and same thing, this bug is driving me nutz. please fix. cant enjoy playing with them since we are in lockdown here in Puetor Rico due to corona. sad! 😭

loutr commented 4 years ago

I do encounter the same problem on Debian Buster (stable), using xboxdrv and an Xbox One controller (either wired or via bluetooth), when I try to use Remote Play with a Windows 10 user. I can use it nonetheless with any Steam games in my library locally.

nacho692 commented 4 years ago

Affected by this bug using an xbox360 controller

Host Windows 10

Guest OS Manjaro 20.0.3 Kernel 5.6.19-2-MANJARO Steam 31 Jul 2020

lfzawacki commented 4 years ago

Just leaving a comment to say I'm also affected by this bug. Using Steam Remote Play hosted on Linux I can't receive controller input from other players that are using Linux. When the guest uses Windows 10 it works as expected.

Host info: Linux Mint 19.3 Linux kernel 5.4.0-42-generic Steam 31 Jul 2020

ArtificialNebulae commented 4 years ago

Given that this issue appears to be pretty widespread, I'm going to put a note in the summary asking anyone else affected to add a :+1: to the top level and not add a "me too" comment unless there's new information such as a workaround, change in behavior, or if the issue appears to be fixed.

@slouken If there is any additional information we can provide to help bisect the issue, please let us know.

Turkeysteaks commented 4 years ago

After experimenting with my laptop when this wasn't working when going from my (Ubuntu 20.04) to my gf's (Ubuntu 20.04) PC, I have found a few things that may or may not be useful. Note that testing was done from mainly streaming castle crashers, and a little cuphead.

Using a controller I already used on my own PC on my laptop (specifically an official White DS4), as well as a controller on my PC (an official black DS4), nothing worked at first. I can see that there is a client controller, can make it rumble, however in game the inputs do nothing.

Then, after 30 seconds or so, my PC recognised it with the config I had given it ages ago when I used it personally. It then instantly started working as expected.

I believe that the host must have a config with the controller for it to work. I'm currently testing this theory.

So, I grabbed a random gamepad (it's a logitech F310) that I've never used on either PC before and plugged it into my laptop (replacing the white DS4). I then booted Castle Crashers on the PC and invited my laptop, and as I expected, the host could see both controllers still but the F310 controller input was not detected. the F310 has no feedback so I can't confirm that rumble was working, but I'd expect so.

Next step, is giving F310 a config tied to my second account, not my main one to see if that works. Booting up the game, inviting, Host detects Clients controller, but again receives no input.

Now trying to log in as Main account on Laptop, giving the F310 a config tied to the main account, and then logging back into the correct accounts. Did the whole shebang again, and unfortunately there was still no input coming from the F310, same situation.

I then tried plugging the F310 into the main PC and it detected it with the config I set it when logged in with main account on the laptop. Plugged back in to lappy and tried again. Still no luck.

It's entirely possible that the F310 is the culprit in my tests, but I don't have a third DS4 to test it on, nor an XB1 controller.

I hope this is useful to anyone else though, maybe you'll be able to find a fix.

Edit 27/10/20: After giving the white DS4 to my girlfriend, we got home and plugged controllers into PCs (I built them both, very similar specs and both on ubuntu 20) and tried remote playing. Again, this did actually work - waited a minute or so and then it popped up with 'White DS4 detected' using the same configs as I had previously given it at my own desktop. It then worked flawlessly. In the same play session, I was playing with another friend who was using an official XB1 controller on a windows laptop. This also worked fine. I am not sure if Linux to Linux is the problem, or just Linux clients, or anything at all right now but I hope this is useful progress to you all

hermpes commented 4 years ago

I'm also affected. Windows client also not having controllers detected when connecting to linux host.

Remote Play Together Client Controller not detected

Issue transferred from https://github.com/ValveSoftware/steam-for-linux/issues/7357. @hermpes posted on 2020-09-11T02:51:35:

Your system information

Please describe your issue in as much detail as possible:

While hosting, the client (Windows 10) controller was not detected. This issue also exists if the windows machine is hosting, the linux client's controller is not detected.

Both machine's controllers are detected if they are the host.

Steps for reproducing this issue:

  1. Host game with Linux Host and Windows Client or Windows Host and Linux Client
iiBangBang commented 4 years ago

Hmm.... When I first setup my machine (Linux Mint Running ryzen5 APU) I had THIS issue. No controllers detected.... however I noticed that parts of the controller were still functional (IE mouse on controller) and a few other mapped buttons. So I decided to take the controller to my host machine and fully reconfigure it there (using Steam Big Picture of course.)

Now my Xbox and PS4 controller both work just fine.... Bluetooth and wired. Not sure what the "Play Together" means... I'm assuming this is for local Co-op play and I might have this post all wrong but.... the controllers do work in remote play if you first configure them on the host windows machine.

When attempting to start a Remote Play Together session, the host computer is unable to detect any remote Linux client controllers. Unknown whether this issue affects Windows and/or OSX clients as well (Update 2020.03.07: after checking the In-Home Streaming Bug Reports forum, there is one topic reporting the same issue, though no specific OS is specified: https://steamcommunity.com/groups/homestream/discussions/1/1749023631421591910/) Tested with both Linux and Windows hosts; only Linux clients were tested.

Your system information

  • Steam client version (build number or date):

    • Stable, Feb. 27: Working normally
    • Beta, March 7: Issue Present
    • Beta, March 18: Issue Present
    • Stable, March 26: Issue Present
    • Beta, April 3 (second): Issue Present
    • Beta, April 16: Issue Present
  • Distribution (e.g. Ubuntu): Ubuntu 18.04.4 LTS
  • Opted into Steam client beta?: Yes and No (see above)
  • Have you checked for system updates?: Yes (all Linux clients updated and restarted)
  • Other Info: Both Linux clients have the steam-devices package installed, so udev rules should not be a factor.
Turkeysteaks commented 4 years ago

Hmm.... When I first setup my machine (Linux Mint Running ryzen5 APU) I had THIS issue. No controllers detected.... however I noticed that parts of the controller were still functional (IE mouse on controller) and a few other mapped buttons. So I decided to take the controller to my host machine and fully reconfigure it there (using Steam Big Picture of course.)

Now my Xbox and PS4 controller both work just fine.... Bluetooth and wired. Not sure what the "Play Together" means... I'm assuming this is for local Co-op play and I might have this post all wrong but.... the controllers do work in remote play if you first configure them on the host windows machine.

This is an issue with Remote Play Together. Remote Play Together is similar to remote play in that you stream it to a different PC, however with Together, you stream it to multiple PCs at once across the world so that your friends can play local co op games with you, even from far away. Ie Castle Crashers or Stick Fight etc. It also even works on games that have no online capabilities whatsoever.

What you said may be applicable however. Like I said in my earlier reply, the only controllers that worked were my official DS4 controllers that had already been used and configured on my own PC, then given to my remote play together target. I shall have to test if this happens with normal remote play in my own house at some point, however I don't have a spare controller to use or anything. What this may mean is that currently the only way to make sure it works is to configure a controller on the host PC. It also doesn't work with the F310 in my case, meaning that it's likely only official controllers are working at this point. Not sure if this is of any help to anyone or steam, but that's what I'm finding. Might be a work around for friends that are able to meet. Either that, or even better would be some way to send a controller's data to another PC, which would allow it to work theoretically. I have no idea if that's even possible though

bernardodpc commented 3 years ago

I'm affected by this too. initially I couldn't remote play together in any form using controllers. they were not recognized when I hosted and when I was the client but I followed this instructions (https://steamcommunity.com/app/221410/discussions/0/523897277912430760/) and SOME GAMES now can recognize my friend's controller on windows when I am HOSTING.

I still couldn't play with him when I'm the client. steam just doesn't recognize my controllers when my friend is hosting on windows.

Distribution (e.g. Ubuntu): Ubuntu 20.04
Opted into Steam client beta?: No
Have you checked for system updates?: Yes
grizeldi commented 3 years ago

I'm affected by this as well. Remote play between my Linux box and a friend's Win 10 machine only works one way - when I'm the host. When he tried hosting, we ran into the problem described in this issue. We tried copying over the controller configs, as suggested above, but couldn't figure out where in Steam's UI such functionality is even located, especially for a game my account doesn't own. I tried switching to Steam beta, but that only led to remote play together crashing instantly when attempting to join a session.

Distribution (e.g. Ubuntu): Ubuntu 20.04
Opted into Steam client beta?: No (for yes, see above)
Have you checked for system updates?: Yes

Even though it is not going to be very helpful to people actually trying to fix the issue, we found a working workaround. When running the Windows version of Steam through Lutris (Wine + DXVK), remote play together worked just fine, so until this issue is fixed, this seems to be the only reliably working way to join remote play together sessions from Linux.

martin-ejdestig commented 3 years ago

@kisak-valve @slouken Ping. Is there any more information that can be provided to help solve this issue? Are there any plans to fix it? Is it supposed to work? I have refunded games just because this bug made it impossible to play remotely with others.

I have never gotten controllers working with Steam Remote Play Together in any game I tried. It does not matter if I run Linux or Windows for the host. And I have tried XBox 360 and XBox One controllers on the client (that work without any issues in Steam Big Picture mode and in games locally). I have chmod:ed /dev/uinput on the host to allow everyone to read and write (also on the client... even though I do not see why any devices would need to be emulated there...).

Below is a snippet from steam/logs/streaming_log.txt that shows that a local XBox 360 controller and a remote XBox One controller is being detected. The remote controller is also displayed in the Steam overlay next to the remote user. But no input is sent to the games I tried. (I tried keyboard input in some of them and that worked.)

[2020-12-29 21:45:44] Local Device Found
  type: 045e 02a1
  path: sdl://1
  serial_number:  - 0
[2020-12-29 21:45:44]   Manufacturer: 
[2020-12-29 21:45:44]   Product:      X360 Wireless Controller
[2020-12-29 21:45:44]   Release:      100
[2020-12-29 21:45:44]   Interface:    -1
[2020-12-29 21:45:44] !! Steam controller device opened for index 0.
[2020-12-29 21:45:44] Controller has an Invalid or missing unit serial number, setting to '45e-2a1-4384fa5'
[2020-12-29 21:45:44] Opted-in Controller Mask for AppId 389140: 0
[2020-12-29 21:45:44] Opted-in Controller Mask for AppId 455400: 0
[2020-12-29 21:45:44] BYieldingQueryAccountsRegisteredToController
[2020-12-29 21:45:44] Controller 0 mapping uses xinput : false
[2020-12-29 21:45:45] Fetching Config Sets 0
[2020-12-29 21:45:45] CClientJobFetchPersonalizationFileID
[2020-12-29 21:45:45] Controller 0 mapping uses xinput : false
[2020-12-29 21:45:45] Controller 0 mapping uses xinput : false
[2020-12-29 21:45:45] Set Account Config Sets 0 1 1
[2020-12-29 21:45:45] Controller 0 mapping uses xinput : false
[2020-12-29 21:45:45] Controller 0 mapping uses xinput : false
[2020-12-29 21:47:04] No cached sticky mapping in ActivateActionSet.
[2020-12-29 21:47:04] No cached sticky mapping in ActivateActionSet.
[2020-12-29 21:47:15] Controller 0 mapping uses xinput : false
... above line repeated 3 times
[2020-12-29 21:48:33] Remote Device Found
  type: 045e 02fd
  path: sdl://0
  serial_number:  - 0
[2020-12-29 21:48:33]   Manufacturer: 
[2020-12-29 21:48:33]   Product:      Xbox One Wireless Controller
[2020-12-29 21:48:33]   Release:      903
[2020-12-29 21:48:33]   Interface:    -1
[2020-12-29 21:48:33] !! Steam controller device opened for index 1.
[2020-12-29 21:48:33] Controller has an Invalid or missing unit serial number, setting to '45e-2fd-4384fa5'
[2020-12-29 21:48:33] BYieldingQueryAccountsRegisteredToController
[2020-12-29 21:48:33] Controller 1 mapping uses xinput : false
[2020-12-29 21:48:33] Controller 0 mapping uses xinput : false
[2020-12-29 21:48:33] Controller 0 mapping uses xinput : false
[2020-12-29 21:48:33] Controller 1 Gamepad uses xinput : true
[2020-12-29 21:48:33] Controller 0 mapping uses xinput : false
[2020-12-29 21:48:33] Controller 0 mapping uses xinput : false
[2020-12-29 21:48:33] Controller 1 Gamepad uses xinput : true
[2020-12-29 21:48:33] Controller 1 Gamepad uses xinput : true
[2020-12-29 21:48:34] Fetching Config Sets 1
[2020-12-29 21:48:34] CClientJobFetchPersonalizationFileID
[2020-12-29 21:48:34] Controller 0 mapping uses xinput : false
[2020-12-29 21:48:34] Controller 0 mapping uses xinput : false
[2020-12-29 21:48:34] Controller 1 Gamepad uses xinput : true
[2020-12-29 21:48:34] Controller 1 Gamepad uses xinput : true
[2020-12-29 21:48:34] Set Account Config Sets 1 1 1
[2020-12-29 21:48:34] Controller 0 mapping uses xinput : false
[2020-12-29 21:48:34] Controller 0 mapping uses xinput : false
[2020-12-29 21:48:34] Controller 1 Gamepad uses xinput : true
[2020-12-29 21:48:34] Controller 1 Gamepad uses xinput : true
... above 4 lines repeated 9 times
[2020-12-29 21:52:13] No cached sticky mapping in ActivateActionSet.
[2020-12-29 21:52:13] No cached sticky mapping in ActivateActionSet.
[2020-12-29 21:52:13] No cached sticky mapping in ActivateActionSet.
[2020-12-29 21:52:13] Controller device closed after hid_read failure
jcnils commented 3 years ago

Same here. Manjaro.

I can use a controller when friends connect to my game, but I cannot use a controller when I connect to a friend's game.

ArtificialNebulae commented 3 years ago

With the recent update to allow Remote Play Together using the Steam Link application on mobile and Flatpak, I re-tested both the embedded remote play client within the main Steam client, and the one that's a part of the Flatpak app.

As of the Steam Beta dated March 17, 2021, and the Steam Link Flatpak app 1.0.0.69, I can confirm that controller input still does not work on the main Steam desktop app, but it DOES work using the Steam Link Flatpak app. There's clearly something different happening with input handling on each of these applications, which I think might be the root cause of the problem.

RuiGuilherme commented 3 years ago

Same issue with Arch Linux with Xbox X/S Black Carbon -1914-

$ uname -a

Linux ArchLinuxRui 5.12.9-arch1-1 #1 SMP PREEMPT Thu, 03 Jun 2021 11:36:13 +0000 x86_64 GNU/Linux

$ pacman -Qn | grep steam

steam 1.0.0.70-1

game-devices-udev and steam-devices are installed:

And I created my own rules:

KERNEL=="hidraw*", ATTRS{idVendor}=="045e", ATTRS{idProduct}=="0b12", MODE="0660", TAG+="uaccess"

$ lsusb

Bus 001 Device 040: ID 045e:0b12 Microsoft Corp. Controller

$ l /dev/input

...
crw-rw-rw-+  1 root input 13,  0 jun 11 15:41 js0
crw-rw----+  1 root input 13,  1 jun 11 15:41 js1
...

issue

1 case: (Possible to fix by simply updating/adding udev rules)

  1. Linux Host
  2. Windows Guest

Linux(Host) controller works fine, but the Windows(Guest) controller doesn't work. (Steam detects all controls)

2 case:

  1. Windows Host
  2. Linux Guest

Windows(Host) controller works fine, but the Linux(Guest) controller doesn't work. (Steam detects all controls)

Edit about 1 case: I had not tested after setting UDEV rules, now the first case is working properly after update udev rules. Second case still not working. (Tested in Enter in the Gungeon)

bernardodpc commented 3 years ago

I don't know how to quote on github. I'll quote this way: "1 case:

Linux Host
Windows Guest

Linux(Host) controller works fine, but the Windows(Guest) controller doesn't work. (Steam detects all controls)

2 case:

Windows Host
Linux Guest

Windows(Host) controller works fine, but the Linux(Guest) controller doesn't work. (Steam detects all controls)"

in my case I was able to play as host with my friend. the configuration linux host + windows guest worked fine for me using those custom udev device rules.

but I couldn't play as guest so far.

has anyone tested this? https://www.reddit.com/r/linux_gaming/comments/li5snu/guide_steam_remote_play_together_fix_remote/

RuiGuilherme commented 3 years ago

@bernardodpc

I don't know how to quote on github. I'll quote this way:

Try it: image

Also: https://guides.github.com/features/mastering-markdown/

bernardodpc commented 3 years ago

@bernardodpc

I don't know how to quote on github. I'll quote this way:

Try it: image

Also: https://guides.github.com/features/mastering-markdown/

thanks haha I tried clicking on that thing but nothing happened by that time. now it worked

RuiGuilherme commented 3 years ago

in my case I was able to play as host with my friend. the configuration linux host + windows guest worked fine for me using those custom udev device rules.

Thanks for the notice! I tried again as first case (Linux Host + Windows Guest) and worked perfectly.
I did not test the first case after update as udev rules

ArtificialNebulae commented 3 years ago

It looks like there's been some activity on a related (possibly duplicate?) bug #7715, with the latest beta release notes indicating the issue has been fixed. I will re-test as soon as I can to confirm whether or not this issue is resolved.

blu2lz commented 3 years ago

Suffered from this bug for more than a year. Tested last week with stable client and it finally worked again! Thanks for the fix!

For the record: Test case 1: Two local controllers on Windows Host, two Linux clients each with one controller. Test case 2: One local controller on Windows Host, one Linux client with one controller.

ArtificialNebulae commented 3 years ago

Finally had a chance to test today, and Linux client controllers seems to be working on Windows hosts without issue as of the October 13 build. I would say this issue is resolved.