ValveSoftware / Proton

Compatibility tool for Steam Play based on Wine and additional components
Other
24.33k stars 1.06k forks source link

Proton 8.0-4 wrong reporting of certain HID devices crashes Unity games #7284

Closed Skillfur closed 8 months ago

Skillfur commented 11 months ago

Compatibility Report

System Information

I confirm:

Symptoms

Certain HID devices that reports multiple sub devices crashes Unity games

Reproduction

Plug in device that is reported in system as multiple devices like a gaming mouse (in my case Roccat Tyon) that reports itself as a keyboard, mice and a joystick, causes the Unity engine to freeze

Most likely same problem as in #5658

F41S3 commented 11 months ago

Same issue for me, crashing on proton 8.0-4

FoxbitDreamtail commented 11 months ago

good news, with proton GE the game doesn't crash for me until I exit, then it crashes instead of exiting normaly, GE 8-14.

alasky17 commented 11 months ago

@Skillfur @F41S3 Could you please get a log with +hid? The easiest way is to add this as a launch option: PROTON_LOG=+hid %command%.

Also - @F41S3 Are you also using a Roccat Tyon or some other input device with the same behavior?

F41S3 commented 11 months ago

@Skillfur @F41S3 Could you please get a log with +hid? The easiest way is to add this as a launch option: PROTON_LOG=+hid %command%.

Also - @F41S3 Are you also using a Roccat Tyon or some other input device with the same behavior?

Using Corsair K65 RGB Mini, notably it has a mouse input option using the function keys.

I'll provide a log in the next 4hrs.

Skillfur commented 11 months ago

@Skillfur @F41S3 Could you please get a log with +hid? The easiest way is to add this as a launch option: PROTON_LOG=+hid %command%.

Also - @F41S3 Are you also using a Roccat Tyon or some other input device with the same behavior?

Here's the log with +hid option, after the unity logo the game freezes

steam-1966720.log

edit: read thru the log and read the comment on #5658-1084668275 about one of the HidP_SetUsages() providing usage set to 0, and I'm seeing similar thing in my log but with HidP_GetSpecificButtonCaps and HidP_GetSpecificValueCaps Yeah scrap that I think I missunderstood the fucntion they provide

Skillfur commented 11 months ago

And here's the log after launching the game without the mouse being connected steam-1966720.log The game starts fine and I can exit it without any issues

ivyl commented 10 months ago

I've managed to reprogram my keyboard (QMK) to expose a single endpoint with mouse and keyboard. Lethal Company did not crash for me. I even tried to make the raw HID device readable by the user (should not be the default for keyboards - keylogging) but no luck.

@Skillfur

  1. lsusb -v section that describes your mouse
  2. dmesg | grep hid-generic should show you line for your device, something like: [606070.114318] hid-generic 0003:3297:1969.0040: input,hidraw4: USB HID v1.11 Keyboard [ZSA Technology Labs Moonlander Mark I] on usb-0000:0e:00.3-2/input0. We are interested interested in the hidraw$NUMBER part.
  3. output of ls -lah /dev/hidraw$NUMBER
  4. output of hid-decode /dev/hidraw$NUMBER.

The raw hid device should not be readable by the user. Have you changed anything in your system configuration about that?

@F41S3 can you do the same with your keyboard ^ also a log of the crash would be handy.

ivyl commented 10 months ago

I had another look at your log @Skillfur and it looks like your device is also detected as joystick. The descriptor you get with hid-decode is even more interesting now.

112430.344:0064:0090:trace:hid:sdl_add_device Making up serial number for ROCCAT Tyon White: 0300131a7d1e00004b2e000011010000.0
112430.344:0064:0090:trace:hid:sdl_add_device joystick id 0, axis_offset 0, desc {vid 1e7d, pid 2e4b, version 0111, input -1, uid 00000000, is_gamepad 0}.

I think the problem is that Linux kernel sees those joystick HID collections and exposes this part as a evdev / input device and that in turn confuses Unity which has certain expectations as of those devices.

You can try finding which devices those are from dmesg and take away read permissions. If that help then we are onto something.

Skillfur commented 10 months ago

So, the mouse reports itself as 4 distinct hid devices

[  842.066932] hid-generic 0003:1E7D:2E4B.0006: input,hiddev97,hidraw1: USB HID v1.11 Mouse [ROCCAT ROCCAT Tyon White] on usb-0000:0d:00.3-3.1/input0
[  842.126969] hid-generic 0003:1E7D:2E4B.0007: input,hidraw2: USB HID v1.11 Keyboard [ROCCAT ROCCAT Tyon White] on usb-0000:0d:00.3-3.1/input1
[  842.133516] hid-generic 0003:1E7D:2E4B.0008: input,hidraw3: USB HID v1.11 Joystick [ROCCAT ROCCAT Tyon White] on usb-0000:0d:00.3-3.1/input2
[  842.141414] hid-generic 0003:1E7D:2E4B.0009: hiddev98,hidraw4: USB HID v1.11 Device [ROCCAT ROCCAT Tyon White] on usb-0000:0d:00.3-3.1/input3

The joystick part is mainly because the mouse has an analog thumb that can act as a joystick. Anyway, I haven't touched the permissions other than what the roccattyonconfig did, so every /dev/hidraw assigned to the mouse looks fine As far as I guess the first and the last hid that is reported by the mouse is also used for configuration like uploading keymaps and macros crw-rw---- 1 root roccat 240, 4 12-05 17:01 /dev/hidraw1 My default user is not a part of roccat group, without elevating privileges I have no access to any of the hidraws. However @ivyl your suggestion about joystick confusing either unity or the proton is correct, as yeeting /dev/input/event reported by a mouse that relates to the joystick, gets the proton going. in my case it was the /dev/input/event that the /dev/input/by-id/usb-ROCCAT_ROCCAT_Tyon_White_ROC-11-851-if02-event-joystick was linked against. Simply taking away permissions won't work as it only had root and the roccat group. Leaving /dev/input/js was fine.

That may also explain why NotITG (a rythm game) doesn't detect my dancemat but wine control ran under proton does, but I'll test that tomorrow if it changes anything

ivyl commented 10 months ago

@Skillfur thanks for the confirmation. There's nothing suspicious in the logs on Proton side, so likely it's Unity making assumptions. I've seen that happen with some games and with some Unity plugins. Surprisingly Lethal Company seems to be using Unity's native controller handling.

It's going to be annoying to debug and properly fix the issue without having one of those locally and it seems like a 2014 product that's hardly available. If you are up for collecting some more logs that would be great.

Can you share crash logs captured with PROTON_LOG=+hid,+input,+dinput ? This may have some more clues.

Also can you make the joystick hidraw device readable by your user and try launching the game with PROTON_ENABLE_HIDRAW=0x1e7d/0x2e4b to see if it makes any difference? Having same log as above for it would also be great.

Skillfur commented 10 months ago

That is true, I'm also searching form one moreof these mice as I fear that someday it will simply die on me Anyway Here's the log of the game freezing with no permission to hidraw steam-1966720.log Also Giving myself permissions to the third hidraw that is associated with the joystick part of my mouse (in my case it was hidraw3) and doing the PROTON_ENABLE_HIDRAW=0x1e7d/0x2e4b does launch previously non running unity games here is the log of the game successfully running steam-1966720.log

ivyl commented 9 months ago

Does the game work for you with Proton 7? If yes can I have a log with the same logging channels (PROTON_LOG=+hid,+input,+dinput) and the mouse connected using it? I struggle to find a difference that makes it work on Proton 7 for some folks (see Phasmophobia bug linked above).

ivyl commented 8 months ago

This should be fixed now in bleeding-edge. It would be great if you could give it a spin and confirm that it now works with the previously problematic devices.

Skillfur commented 8 months ago

@ivyl Sorry for not replying earlier, Somehow I missed the message I removed PROTON_ENABLE_HIDRAW from my globals and it appears that experimental bleeding-edge does fix that issue It would be nice to see that pushed into the wine codebase if You have means of communication with them as wine also appears to suffer from the same issue

ivyl commented 8 months ago

@Skillfur Thanks for verifying. FWIW Proton developers are also upstream Wine developers. I have first upstreamed the change to Wine and then cherry-picked it to our Proton tree :-)

See: https://gitlab.winehq.org/wine/wine/-/commit/e3431a02e1d23ad506512b906f244eae1db05035 and https://github.com/ValveSoftware/wine/commit/479e4d49f3b2bb8202fa043102d3038863c229f6

The change will be also a part of the next experimental and stable releases.

JT8D-17 commented 8 months ago

This should be fixed now in bleeding-edge. It would be great if you could give it a spin and confirm that it now works with the previously problematic devices.

The following Unity games that were previously choking on my Thrustmaster T.16000M and TWCS are now confirmed (completely) working again:

Thank you so much, @ivyl !

(And @Skillfur for opening the issue.)

Skillfur commented 8 months ago

@ivyl That's great to hear, Thank you to taking a look at that issue, and keep up the good work you guys :) Cheers