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.worksOP
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    2
    ·
    2 days ago

    I’ve asked but not been answered. You said in the other thread sunshine is the problem, not my Linux setup, but actually working with the developer earlier on this we found it is the host that’s the issue, we just dont have a clean solution to setting that hidraw0 permission. The devs literally demonstrated the problem. I was able to confirm their hypothesis. hidraw devices are set as root. They need permissions altered.

    As for your “use something else” suggestion, care to suggest something else to use? Sway is in the fedora repo, not external. It’s stable and supports zero copy off the dGPU. Do you have an alternative to sway I should consider? Sunshine was chosen over gamesonwhales because the security model is more practical for a server left running all the time. Gamesonwhales needs coarser permissions that aren’t great for a constantly running server doing other things unattended. Do you have an alternative for these I should consider? Fedora…well, I’m forcing myself to learn this fucking distro so it’s a self-inflicted wound here.

    Simply saying “sunshine is the problem” isn’t helpful. It doesn’t solve anything. It doesn’t diagnose anything. It doesn’t get anyone closer to answer.

    So tell me, what is this magical something else?

      • muusemuuse@sh.itjust.worksOP
        link
        fedilink
        English
        arrow-up
        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.world
          link
          fedilink
          English
          arrow-up
          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.worksOP
            link
            fedilink
            English
            arrow-up
            1
            ·
            edit-2
            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?