there is a udev rule, 60-sunshine.rule, that doesn’t work on my fedora rig and I haven’t been a belt figure out exactly why it wont fire. I’m running fedora server with sunshine and sway streaming zero copy off the GPU with wlr capture. It works, but steams games are mapping Sony controllers improperly. It seems to be an issue around that rule not working, so I never get permission to the hidraw0 device the controller appears on during sunshine sessions. Manually chowing it into the input group solves that issue, but that’s not a very clean solution and wont persist across multiple sessions anyway. So, what can I actually do about this?

I suspect my use and sway and seatd instead of logind might be contributing to this but I’m not certain.

    • muusemuuse@sh.itjust.worksOPEnglish
      1·
      1 day ago

      no, it works fine in sunshine, dawg.

      if I fire up retroarch in sunshine, perfectly fine. If i fire up steam in sunshine, trainwreck.

      • just_another_person@lemmy.worldEnglish
        2·
        1 day ago

        Okay, so that’s not what you’re describing at all. You can tell because people are responding with information, and you keep introducing trusts and turns like we’re supposed to know WTF you’re even talking about.

        Here’s how a gamepad works under Linux normally in a very simplistic way:

        Kernel > udev > HID Gamepad > libinput > game

        Where libinput sanitizes the input from the device and handles mapping. What you’re saying you’re doing is messing with permissions on the input device for some reason (which is unnecessary by any normal means), and then wondering why it’s not working.

        You’re saying your stack is functioning correctly for everything but Steam+Sunshine, right? You were told previously that steam-input runs when Steam runs. It essentially overrides libinput when running. THEN you’re throwing Sunshine into the mix, whiches uses it’s own input library as well, and you’re wondering what the issue is here.

        I’ll say it again, because you’re not listening: if everything works fine without Sunshine running, Sunshine is the problem. Libinput+steam-input+inputtino is going to cause problems. You’ve been told this before multiple times.

        Now, if everything is broken without Steam OR Sunshine running at all, then you have a libinput problem because you’re just running Sway without all the helpers that any usual DE would have, but you keep arguing against that idea for some reason, and I don’t think you understand what you’re even saying. On a normally functioning system, you don’t mess with permissions on /dev devices. If something isn’t working as you expect, you have issues downstream.

        So either start looking at your input library issues as you’ve been told a dozen times, or maybe boot a LiveUSB and see if everything works as it should without you messing with things.

        • muusemuuse@sh.itjust.worksOPEnglish
          1·
          1 day ago

          This is not my assertion. I’ll explain more clearly to resolve the confusion.

          I use sunshine to access a sway session on my fedora server. Everything runs fine unless the app I’m running is steam or a steam game. For those specific cases inputs are mapped incorrectly on the Sony controllers until I manually changed the group for /dev/hidraw0 to input which the sunshine user is a member of. If I do that, everything works properly, including steam.

          That HIDraw device is not persistent. It is created and destroyed with each sunshine session, so manually assigning a group to it won’t stick. That’s the problem that udev rule is supposed to solve.

          You’re saying everybody is giving me solutions but you’re the only one I see speaking here aside from one other poster who posted once earlier. Who is everybody?