Controller doesn't work in some games

rezo552 commented 11 months ago

Is there an existing issue for this?

[X] I have searched the existing issues

Is your issue described in the documentation?

[X] I have read the documentation

Is your issue present in the nightly release?

[X] This issue is present in the nightly release

Describe the Bug

In some games the controller is not being recognized (linux host) while I dont have the same issue when using Steam link. The only difference I can see: The controller appears like this when using Sunshine:

[193895.683930] input: Microsoft X-Box 360 pad as /devices/virtual/input/input38

The controller appears like this when using Steam: [193918.271611] input: Microsoft X-Box 360 pad 0 as /devices/virtual/input/input40

Expected Behavior

No response

Additional Context

No response

Host Operating System

Docker

Operating System Version

Debian GNU/Linux 12 (bookworm)

Architecture

64 bit

Sunshine commit or version

Sunshine version: v0.20.0.1303defb67c586447a03185d60eb20bea91a8eff

Package

Linux - flatpak

GPU Type

AMD

GPU Model

5700G

GPU Driver/Mesa Version

Mesa 23.2.1-1

Capture Method (Linux Only)

No response

Config

# If no external IP address is given, Sunshine will attempt to automatically detect external ip-address
# external_ip = 123.456.789.12

# Set the familly of ports used by Sunshine
# port = 47989

# The private key must be 2048 bits
# pkey = /dir/pkey.pem

# The certificate must be signed with a 2048 bit key
# cert = /dir/cert.pem

# The name displayed by Moonlight
# If not specified, the PC's hostname is used
# sunshine_name = Sunshine

# The minimum log level printed to standard out
#
# none -> no logs are printed to standard out
#
# verbose = [0]
# debug   = [1]
# info    = [2]
# warning = [3]
# error   = [4]
# fatal   = [5]
# none    = [6]
#
min_log_level = info

# A list of commands to be run before/after all applications.
#   If any of the prep-commands fail, starting the application is aborted.
global_prep_cmd = [{"do":"/usr/bin/xfce4-minimise-all-windows","undo":"/usr/bin/sunshine-stop"}]

# The origin of the remote endpoint address that is not denied for HTTP method /pin
# Could be any of the following values:
#   pc|lan|wan
#     pc: Only localhost may access /pin
#     lan: Only those in LAN may access /pin
#     wan: Anyone may access /pin
#
# origin_pin_allowed = pc

# The origin of the remote endpoint address that is not denied for HTTPS Web UI
# Could be any of the following values:
#   pc|lan|wan
#     pc: Only localhost may access the Web Manager
#     lan: Only those in LAN may access the Web Manager
#     wan: Anyone may access the Web Manager
#
# origin_web_ui_allowed = lan

# If UPnP is enabled, Sunshine will attempt to open ports for streaming over the internet
# To enable it, uncomment the following line:
# upnp = on

# The file where current state of Sunshine is stored
# file_state = sunshine_state.json

# The file where user credentials for the UI are stored
# By default, credentials are stored in `file_state`
# credentials_file = sunshine_state.json

# The display modes advertised by Sunshine
#
# Some versions of Moonlight, such as Moonlight-nx (Switch),
# rely on this list to ensure that the requested resolutions and fps
# are supported.
#
# fps = [10, 30, 60, 90, 120]
# resolutions = [
#     352x240,
#     480x360,
#     858x480,
#     1280x720,
#     1920x1080,
#     2560x1080,
#     3440x1440,
#     1920x1200,
#     3860x2160,
#     3840x1600,
# ]

# Sometimes it may be usefull to map keybindings.
# Wayland won't allow clients to capture the Win Key for example
#
# See https://docs.microsoft.com/en-us/windows/win32/inputdev/virtual-key-codes
#
# Note:
#   keybindings needs to have a multiple of two elements
# keybindings = [
#   0x10, 0xA0,
#   0x11, 0xA2,
#   0x12, 0xA4,
#   0x4A, 0x4B
# ]

# How long to wait in milliseconds for data from moonlight before shutting down the stream
# ping_timeout = 10000

# The file where configuration for the different applications that Sunshine can run during a stream
file_apps = apps.json

# Percentage of error correcting packets per data packet in each video frame
# Higher values can correct for more network packet loss, but at the cost of increasing bandwidth usage
# The default value of 20 is what GeForce Experience uses
#
# The value must be greater than 0 and lower than or equal to 255
# fec_percentage = 20

# When multicasting, it could be usefull to have different configurations for each connected Client.
# For example:
#       Clients connected through WAN and LAN have different bitrate contstraints.
#       Decoders may require different settings for color
#
# Unlike simply broadcasting to multiple Client, this will generate distinct video streams.
# Note, CPU usage increases for each distinct video stream generated
channels = 2

# The back/select button on the controller
# On the Shield, the home and powerbutton are not passed to Moonlight
# If, after the timeout, the back button is still pressed down, Home/Guide button press is emulated.
# If back_button_timeout < 0, then the Home/Guide button will not be emulated
# back_button_timeout = 2000

# !! Windows only !!
# Gamepads supported by Sunshine
# Possible values:
#   x360 -- xbox 360 controller
#   ds4 -- dualshock controller (PS4)
# gamepad = x360

# Control how fast keys will repeat themselves
# The initial delay in milliseconds before repeating keys
# key_repeat_delay = 500
#
# How often keys repeat every second
# This configurable option supports decimals
# key_repeat_frequency = 24.9

# The name of the audio sink used for Audio Loopback
# If you do not specify this variable, pulseaudio will select the default monitor device.
#
# You can find the name of the audio sink using the following command:
# !! Linux only !!
# pacmd list-sinks | grep "name:" if running vanilla pulseaudio
# pPipewire: Use `pactl info | grep Source`. In some causes you'd need to use the `sink` device. Try `pactl info | grep Sink`, if _Source_ doesn't work
# audio_sink = alsa_output.pci-0000_09_00.3.analog-stereo
#
# !! Windows only !!
# tools\audio-info.exe
# audio_sink   = {0.0.0.00000000}.{FD47D9CC-4218-4135-9CE2-0C195C87405B}
#
# The virtual sink, is the audio device that's virtual (Like Steam Streaming Speakers), it allows Sunshine
# to stream audio, while muting the speakers.
# virtual_sink = {0.0.0.00000000}.{8edba70c-1125-467c-b89c-15da389bc1d4}

# !! Windows only !!
# You can select the video card you want to stream:
# The appropriate values can be found using the following command:
# tools\dxgi-info.exe
# adapter_name = Radeon RX 580 Series
# output_name  = \\.\DISPLAY1

# !! Linux only !!
# Set the display number to stream.
# You can find them by the following command:
# xrandr --listmonitors
# Example output: "0: +HDMI-1 1920/518x1200/324+0+0  HDMI-1"
#                  ^ <-- You need this.
# output_name = 0

###############################################
# FFmpeg software encoding parameters
# Honestly, I have no idea what the optimal values would be.
# Play around with this :)

# Quantitization Parameter
# Some devices don't support Constant Bit Rate. For those devices, QP is used instead
# Higher value means more compression, but less quality
# qp = 28

# Minimum number of threads used by ffmpeg to encode the video.
# Increasing the value slightly reduces encoding efficiency, but the tradeoff is usually
# worth it to gain the use of more CPU cores for encoding. The ideal value is the lowest
# value that can reliably encode at your desired streaming settings on your hardware.
# min_threads = 1

# Allows the client to request HEVC Main or HEVC Main10 video streams.
# HEVC is more CPU-intensive to encode, so enabling this may reduce performance when using software encoding.
# If set to 0 (default), Sunshine will specify support for HEVC based on encoder
# If set to 1, Sunshine will not advertise support for HEVC
# If set to 2, Sunshine will advertise support for HEVC Main profile
# If set to 3, Sunshine will advertise support for HEVC Main and Main10 (HDR) profiles
# hevc_mode = 2

# Force a specific encoder, otherwise Sunshine will use the first encoder that is available
# supported encoders:
#   nvenc
#   amdvce # NOTE: alpha stage. The cursor is not yet displayed
#   software
#
# encoder = software
##################################### Software #####################################
# See x264 --fullhelp for the different presets
# sw_preset  = superfast
# sw_tune    = zerolatency
#

##################################### NVENC #####################################
###### presets ###########
# default
# hp     -- high performance
# hq     -- high quality
# slow   -- hq 2 passes
# medium -- hq 1 pass
# fast   -- hp 1 pass
# bd
# ll     -- low latency
# llhq
# llhp
# lossless
# losslesshp
##########################
# nv_preset = llhq
#
####### rate control #####
# auto      -- let ffmpeg decide rate control
# constqp   -- constant QP mode
# vbr       -- variable bitrate
# cbr       -- constant bitrate
# cbr_hq    -- cbr high quality
# cbr_ld_hq -- cbr low delay high quality
# vbr_hq    -- vbr high quality
##########################
# nv_rc = auto

###### h264 entropy ######
# auto -- let ffmpeg nvenc decide the entropy encoding
# cabac
# cavlc
##########################
# nv_coder = auto

##################################### AMD #####################################
###### presets ###########
# default
# speed
# balanced
##########################
# amd_preset = balanced
#
####### rate control #####
# auto        -- let ffmpeg decide rate control
# constqp     -- constant QP mode
# vbr_latency -- Latency Constrained Variable Bitrate
# vbr_peak    -- Peak Contrained Variable Bitrate
# cbr         -- constant bitrate
##########################
# amd_rc = auto

###### h264 entropy ######
# auto -- let ffmpeg nvenc decide the entropy encoding
# cabac
# cavlc
##########################
# amd_coder = auto

#################################### VAAPI ###################################
####### adapter ##########
# Unlike with `amdvce` and `nvenc`, it doesn't matter if video encoding is done
# on a different GPU.
# Run the following commands:
# 1. ls /dev/dri/renderD*
#   to find all devices capable of VAAPI
# 2. vainfo --display drm --device /dev/dri/renderD129 | grep -E "((VAProfileH264High|VAProfileHEVCMain|VAProfileHEVCMain10).*VAEntrypointEncSlice)|Driver version"
#   Lists the name and capabilities of the device.
#   To be supported by Sunshine, it needs to have at the very minimum:
#       VAProfileH264High   : VAEntrypointEncSlice
# adapter_name = /dev/dri/renderD128

##############################################
# Some configurable parameters, are merely toggles for specific features
# The first occurrence turns it on, the second occurence turns it off, the third occurence turns it on again, etc, etc
# Here, you change the default state of any flag
#
# To set the initial state of flags -0 and -1 to on, set the following flags:
# flags = 012
#

Apps

{
    "env": {
        "PATH": "$(PATH):$(HOME)\/.local\/bin"
    },
    "apps": [
        {
            "name": "Desktop",
            "image-path": "desktop.png",
            "exclude-global-prep-cmd": "true"
        },
        {
            "name": "Steam Big Picture",
            "image-path": "steam.png",
            "exclude-global-prep-cmd": "false",
            "detached": [
                "\/usr\/games\/steam steam:\/\/open\/bigpicture"
            ],
            "prep-cmd": [
                {
                    "do": "",
                    "undo": "\/usr\/bin\/xfce4-close-all-windows"
                }
            ]
        },
        {
            "name": "RetroDeck",
            "output": "",
            "cmd": "\"\/usr\/bin\/flatpak\" \"run\" \"--branch=stable\" \"--arch=x86_64\" \"net.retrodeck.retrodeck\"",
            "exclude-global-prep-cmd": "false",
            "elevated": "false",
            "image-path": "\/home\/default\/retrodeck\/logo.png",
            "working-dir": "\/usr\/bin\/"
        }
    ]
}

Relevant log output

[193895.683930] input: Microsoft X-Box 360 pad as /devices/virtual/input/input38
[193918.271611] input: Microsoft X-Box 360 pad 0 as /devices/virtual/input/input40

cgutman commented 11 months ago

In some games the controller is not being recognized

Can you provide some examples of games where the controller is working and non-working?

rezo552 commented 11 months ago

In some games the controller is not being recognized

Can you provide some examples of games where the controller is working and non-working?

For example RPCS3 (PS3 emulator)

ritlo commented 10 months ago

I noticed that Auto/DS4 emulated gamepad with a Dualsense controller doesn't work in Forza Motorsport.

When you push down on a face button, it will show ABXY on the interface, and as soon as you let go it switches back to keyboard keys. X360 works as it should. The issue appeared after updating to the latest Moonlight release with PS controller input support.

datapush3r commented 9 months ago

I'm having similar issues with my PS5 controller. It use to be emulated as an Xbox controller but now that it's emulated as a DS4 controller, it barely works with anything. I'd much rather have the option for it to be emulated as a Xbox controller.

ReenigneArcher commented 9 months ago

I'm having similar issues with my PS5 controller. It use to be emulated as an Xbox controller but now that it's emulated as a DS4 controller, it barely works with anything. I'd much rather have the option for it to be emulated as a Xbox controller.

Explicitly set Sunshine to use a Xbox 360 gamepad in the config UI.

LizardByte-bot commented 6 months ago

It seems this issue hasn't had any activity in the past 90 days. If it's still something you'd like addressed, please let us know by leaving a comment. Otherwise, to help keep our backlog tidy, we'll be closing this issue in 10 days. Thanks!

LizardByte-bot commented 5 months ago

This issue was closed because it has been stalled for 10 days with no activity.

Fell commented 1 month ago

I tried the latest git build which includes 2606, but the problem wasn't fixed for me.

What did fix it however was adding my user to the input group and installing game-devices-udev as well as udev-joystick-blacklist.

I did some testing and I could reproduce the virtual sunshine controller not being detected in Freds-Controller-Tester (added as a non-steam game). I also noticed that my Oculus Sensors showed up in the list when I ran evdev so I unplugged them. I think some games actually enumerate all gamepads (and only gamepads) while others just pick whatever is the first input device they can find. Freds Controller Tester detects both XInput and DirectInput devices, which should reflect what most games do.

Oh and, one last thing: All my controllers (including Sunshine) were always detected correctly when I enforced Proton 8.0-5 in Steam. So there must be something they changed in 9.0+.

gschintgen commented 1 month ago

I don't intend to dig too deep here (not knowledgeable enough...), but maybe you could provide some more information on how to reproduce or debug this further:

I tried the latest git build which includes 2606, but the problem wasn't fixed for me.

Which games are/were affected? (Are there free games among them?)

What did fix it however was adding my user to the input group and installing game-devices-udev as well as udev-joystick-blacklist.

Interesting. Did you by any chance check the solution steps independently? I.e. if it worked after you installed the 3rd package the first two might have been unrelated?

I did some testing and I could reproduce the virtual sunshine controller not being detected in Freds-Controller-Tester (added as a non-steam game).

Did this controller test app give different results before and after your fix?

How did you run it? Add it as external game/app to Steam? With Steam Input or without?

What is your actual physical controller? Did you configure Sunshine to emulate a XboxOne controller or DualSense5?

Going forward it'd be nice to exclusively use the newer builds. The new input library has replaced the old one, so any report (and fix!) should be based on the inputtino code.

Oh and, one last thing: All my controllers (including Sunshine) were always detected correctly when I enforced Proton 8.0-5 in Steam. So there must be something they changed in 9.0+.

What is your OS? Anything noteworthy? (non-standard kernel version, or driver PPA etc.)

Fell commented 1 month ago

Which games are/were affected? (Are there free games among them?)

Affected games I have tested:

Did you by any chance check the solution steps independently?

Unfortunately not, it was a pretty chaotic troubleshooting session because I just wanted to relax and play 😅 I don't know which step fixed it exactly.

Did this controller test app give different results before and after your fix?

Yes, I can say that much. It was my test subject because it was quick to launch, and as soon as it detected the gamepad correctly all affected games were also fixed.

How did you run it? Add it as external game/app to Steam? With Steam Input or without?

Add it as a non-steam game and keep all Steam Input settings default, which you can see below:

What is your actual physical controller?

I tested with both a PlayStation 4 DualShock 4 and an Xbox One controller, they showed the same behavoir in the beginning. During the troubleshooting I was focused on the DS4 controller on the client machine.

By the way, an interesting bit from the logs:

[2024:07:24:21:01:32]: Info: Gamepad 0 will be DualShock 5 controller (auto-selected by client-reported type)
[2024:07:24:21:01:32]: Warning: Unable to create virtual DualShock 5 controller: Permission denied
[2024:07:24:21:01:32]: Info: Gamepad 0 will be Xbox One controller (default)

It still works fine, but I thought you might want to know.

What is your OS?

Operating System: Arch Linux KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 Kernel Version: 6.10.0-arch1-2 (64-bit) Graphics Platform: Wayland Processors: 24 × AMD Ryzen 9 3900X 12-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Driver Version: 555.58.02

Everything is installed through system (or AUR) packages, no Flatpaks. Steam is using its included runtime.

Anything noteworthy?

My Steam is still affected by https://github.com/ValveSoftware/steam-for-linux/issues/11079, I wonder if there might be a general problem with Steam at the moment. Unfortunately, I didn't test any non-steam games.

Output of lsusb (including the two Oculus Sensors):

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 003: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
Bus 001 Device 004: ID 28de:2101 Valve Software Watchman Dongle
Bus 001 Device 005: ID 046d:c07d Logitech, Inc. G502 Mouse
Bus 001 Device 006: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
Bus 001 Device 007: ID 28de:2101 Valve Software Watchman Dongle
Bus 001 Device 008: ID 1532:0214 Razer USA, Ltd BlackWidow Ultimate 2016
Bus 001 Device 009: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
Bus 001 Device 010: ID 28de:2101 Valve Software Watchman Dongle
Bus 001 Device 011: ID 090c:1000 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash Drive
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 05e3:0626 Genesys Logic, Inc. Hub
Bus 002 Device 003: ID 0bda:0411 Realtek Semiconductor Corp. Hub
Bus 002 Device 004: ID 0bda:0411 Realtek Semiconductor Corp. Hub
Bus 002 Device 005: ID 0bda:0411 Realtek Semiconductor Corp. Hub
Bus 002 Device 008: ID 2833:0211 Oculus VR, Inc. Rift CV1 Sensor
Bus 002 Device 009: ID 2833:0211 Oculus VR, Inc. Rift CV1 Sensor
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

I actually re-tested with the two Oculus sensors plugged in, and the controller was still correctly detected by Freds Controller Tester. So that might not have been the problem, then. I also can't find any of my devices on that blacklist, so I think it's unlikely that that did anything either. I believe it was me adding myself to the input group.

Thank you for your interest, it's a sign of passion. I hope this helps you and others get closer to the solution.

gschintgen commented 1 month ago

Thanks for the detailed feedback.

By the way, an interesting bit from the logs:

[2024:07:24:21:01:32]: Info: Gamepad 0 will be DualShock 5 controller (auto-selected by client-reported type)
[2024:07:24:21:01:32]: Warning: Unable to create virtual DualShock 5 controller: Permission denied
[2024:07:24:21:01:32]: Info: Gamepad 0 will be Xbox One controller (default)

It still works fine, but I thought you might want to know.

That's probably because uhid is not loaded. (modprobe uhid) In fact I only ended up here because I have an open PR to set that up properly... https://github.com/LizardByte/Sunshine/pull/2906

Everything is installed through system (or AUR) packages, no Flatpaks. Steam is using its included runtime.

AUR is not supported by Sunshine. (There are reasons.) The official way is through this repo: https://github.com/LizardByte/pacman-repo (That's a recent development.)

I actually re-tested with the two Oculus sensors plugged in, and the controller was still correctly detected by Freds Controller Tester. So that might not have been the problem, then. I also can't find any of my devices on that blacklist, so I think it's unlikely that that did anything either. I believe it was me adding myself to the input group.

That might be it.

Here are the udev rules that are installed by Sunshine: https://github.com/LizardByte/Sunshine/blob/aa2cf8e5a9266d53b0e3ac2d7255b6854dfb574f/src_assets/linux/misc/60-sunshine.rules#L1-L2 TAG+="uaccess" instructs your OS to automatically grant the currently logged in user the necessary rights to /dev/uinput. uinput is used to emulate input devices by writing to /dev/uinput. https://www.kernel.org/doc/html/v4.14/input/uinput.html

But I don't know how these events are then passed on to userspace. Probably through /dev/input/eventXX devices. And access to those was (is?) controlled by the input group: https://wiki.archlinux.org/title/Users_and_groups#Pre-systemd_groups But why would your other controllers work?

The open questions are then:

Is it sunshine's responsibility to add the user to the input group?
or is your setup maybe "broken" in some subtle way?
Is this Arch-specific or does this also apply to other distros?

FWIW on my pc my main user is also a member of the input group. That's on Ubuntu. But I don't know if that was a manual addition or simply the default.

I'm writing this up as I'm researching it ... Look what I've found in the original PR https://github.com/LizardByte/Sunshine/pull/2315:

First we’ll add our user to the input group:

I remember testing this PR quite earlier on and I followed those instructions. So that's why I'm in the input group.

gschintgen commented 1 month ago

@ABeltramo or @Hazer might be able to provide some insight on those 2-3 last comments here regarding the interplay of uinput / uhid / input group. (Is being in the input group always necessary or only for DS5 via uhid? I guess we should add the input group setup to the packaging?)

ABeltramo commented 1 month ago

Warning: Unable to create virtual DualShock 5 controller: Permission denied

This is most likely a permission error on /dev/uhid, probably missing the added udev rule to enable that (or the kernel module is not loaded).

As for the rest of the issue I think you are missing additional rules, take the Xbox One joypad for example:

https://github.com/LizardByte/Sunshine/blob/9a82b6810ad5a5a3b2af1ca6581285b579a4031a/src/platform/linux/input/inputtino_gamepad.cpp#L26-L30

It'll match this rule from the game-devices-udev repo. Without that, it's not guaranteed that the joypad will be mounted with user permissions.

Is it sunshine's responsibility to add the user to the input group?

I'm not sure about this one, I'd say it's a packager responsibility since it's distro dependent.
I don't know why historically the Sunshine rules don't include the joypads, I thought it was dealt somewhere else as a dependency to one of those udev packages of rules or maybe we were just lucky that everyone has got Steam installed which packages this set of rules?

ReenigneArcher commented 1 month ago

Is it sunshine's responsibility to add the user to the input group?

I'm not sure about this one, I'd say it's a packager responsibility since it's distro dependent.

Hmm... we used to add the user to the input group (you actually added that)... but it was removed here.

https://github.com/LizardByte/Sunshine/pull/1127

Maybe these changes aren't compatible with the new inputtino stuff?

ABeltramo commented 1 month ago

Yeah, I've later learned the trick of using TAG+="uaccess" for standard desktop usage. I didn't mean to add the user to the input group again, I meant to add the following rules:

# PS5 DualSense (hidraw)
KERNEL=="hidraw*", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="0ce6", MODE="0660", TAG+="uaccess"

# Xbox One (uinput)
SUBSYSTEMS=="input", ATTRS{idVendor}=="045e", ATTRS{idProduct}=="02ea", MODE="0660", TAG+="uaccess"

# Nintendo Switch (uinput)
SUBSYSTEMS=="input", ATTRS{idVendor}=="057e", ATTRS{idProduct}=="2009", MODE="0660", TAG+="uaccess"

TO BE PROPERLY TESTED

gschintgen commented 1 month ago

As for the rest of the issue I think you are missing additional rules, take the Xbox One joypad for example: (...) It'll match this rule from the game-devices-udev repo. Without that, it's not guaranteed that the joypad will be mounted with user permissions.

To sum up so far: adding the user to the input group should, in theory, not be needed since ideally everything has TAG+="uaccess". In our case uinput and uhid are taken care of, but the resulting virtual USB devices with their respective vendor and product ids are not handled. They might remain inaccessible to the user.

gschintgen commented 1 month ago

Oh well, I was just about to write that same thing. :-) We need udev rules for the emulated controllers.

I'll just add those rules to my PR then? Loading uhid is also necessary for a good out-of-the-box experience...

ABeltramo commented 1 month ago

Yeah, we overlapped 😅 I think we'll have to add some proper rules for each virtual device, it should be fairly easy to test too; just force a joypad type from the Sunshine setting page and remove yourself from the input group. To test if the pad works the Steam settings page is probably the best one and it'll show all sort of inputs.
If you don't have a DualSense joypad I can test out gyro, motion, LED and touchpad; just ping me once you've got something!

gschintgen commented 1 month ago

To test if the pad works the Steam settings page is probably the best one and it'll show all sort of inputs.

Except that Steam provides its own rules, no? (for the emulated controllers, not for uinput/uhid) So I'll have to also move them out of the way temporarily? Or just check using e.g. gamepad-tester.com on a machine without Steam.

If you don't have a DualSense joypad I can test out gyro, motion, LED and touchpad; just ping me once you've got something!

Ok, thanks!

ABeltramo commented 1 month ago

Except that Steam provides its own rules, no? (for the emulated controllers, not for uinput/uhid) So I'll have to also move them out of the way temporarily?

True, they should be under /etc/udev/rules.d/ though. You can just copy the files out and reload them using

udevadm control --reload-rules && udevadm trigger

or reboot. You should be able to easily check if they aren't present because you'll lose access to /dev/input/event* if you aren't part of the input group.

gschintgen commented 1 month ago

Hm, just found this, provided by systemd (on both Ubuntu and Arch):

.../udev/rules.d$ grep JOY 70-uaccess.rules -C1
# joysticks
SUBSYSTEM=="input", ENV{ID_INPUT_JOYSTICK}=="?*", TAG+="uaccess"

This looks like it's intended to take care of all controllers? (Which would be reasonable for a desktop system.)

It probably can't hurt to add our rules but I'm not sure that I can even reproduce a situation where the emulated controllers are inaccessible. (But who knows...)

gschintgen commented 1 month ago

I did some more tests on a rather fresh and basic Arch VM without Steam or any other gaming "cruft" that could add non-default udev rules.

With sunshine-git (from yesterday) without any further manual modification:

Xbox One emulation works
Nintendo also
DS5 doesn't

If I use a build with PR #2906, DS5 also works right away since it makes sure uhid is loaded.

The aforementioned systemd rules seem to do their job just fine.

I tested using gamepad-tester.com in Firefox. The emulated controllers showed up using their name. The only weirdness is that all button pushes via moonlight produced button pushes in the VM except for the dpad which showed up as buttons, not as directional input. But that's probably due to the fact that the controller that I had handy is a bit of a niche controller ("Buffalo Classic USB Gamepad", SNES-layout) and somewhere there's an incorrect mapping. (Locally, i.e. in the browser on the VM host running Moonlight, gamepad-tester is showing correct directional input. Maybe Moonlight has a different/incorrect mapping file.) But input does go through and there are no permission issues except for uhid.

As for the recent report by @Fell we might have to just leave it at:

All my controllers (including Sunshine) were always detected correctly when I enforced Proton 8.0-5 in Steam. So there must be something they changed in 9.0+.

(unless there are more such reports coming in of course)

LizardByte / Sunshine