Told you like 5 times…disable…steam-input…then

What made this distro distinctive, and for what features?

Kid…multiple people told you about steam-input. See my other comments.

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.

Just change the port Headscale is running on.

You also don’t want a reverse proxy out in front of Headscale. It doesn’t serve a purpose, and does nothing but introduce added complexity and performance degradation.

Just make an A record in your DNS that points to ‘vpn.whatever.com’ if you just want to treat it as a named host.

When I told you udev rules aren’t the problem. Now you’re trying to make it seem like Steam is a problem? What in the world…🤦

Sunshine IS the problem. You’re describing it yourself. If everything else works but Sunshine…then guess what, dawg?

Kid…look. You keep coming back here and asking this same question, and when people give you very specific answers you keep saying “Nuh-uh, cuzz…”.

You’re missing the point entirely, and you don’t want to listen. If everyone here is so stupid, then why are you here?

Duder…asked and answered.

You’ve asked the same question on a bunch of different servers and threads. You’ve been told what the issue is.

By creating new posts everywhere I don’t think you’re going to get a better answer than what you’ve been given.

If you just want things to work, just switch to something else. Nothing stopping you.

They have Open Source versions of their stack. Just run it yourself at no cost.

Am I missing something?

Also, use any other similar service which all have open source counterparts: Head scale/Tailscale, or ZeroTier.

The inputs are sent as they are received on the host is the point. There is no transcoding of the HID inputs.

It’s a Sunshine problem.

You’re having a problem with Sunshine. The udev rules work fine, because the controller is officially supported in the kernel. If it’s detected, it’s working fine.

If it’s NOT working with Sunshine involved, that’s a Sunshine problem.

Test with the calibration tools of your DE, and also under Steam. If everything works everywhere else, it’s not udev which is only responsible for detecting and capturing the device input.

If you think it’s a group problem, then…just…add your user to the group maybe?

Any RSS reader will work with RSS feeds. It’s an open standard.

Running from a Live image is not going to be performant for a number of reasons I won’t get into, but mainly that you’ll have a loop with some crucial systems back through that USB still. Not absolutely everything is always loaded directly into memory unless you ensure that it is.

The USB medium you’re using is probably slow, so any I/O access to that drive is going to cause performance hits briefly.

That being said: there isn’t going to be any appreciable difference between your two distros in a way that will blow your mind. The “gaming distro” is kind of a farce/myth, with package selection and user interaction being the biggest differences between them.

If the distros are on the same general kernel line, you’ll get very similar performance between them (check Phoronix benchmarks). CachyOS on certain benchmarks may see something like 5-10% in VERY specific areas that probably don’t even impact gaming that much, and you’d never register that difference as a user.

Just switch if you like it. It sounds like you have your other data separated already, so just install along side what you have, boot that, and try it out.

Just don’t be let down in when there isn’t a big performance difference. Also keep in mind that whatever tweaks any other distro has implemented for gaming, you can simply apply to whatever you’re running as well. There are no hidden tweaks, fixes, or proprietary knowledge in any of them that you can’t also apply to your running install.

I think you’re asking the wrong question here. You should be asking “Is my tech stack doing what I need and working for me?”.

If yes, then just keep doing what you’re doing.

If not, then figure out what’s wrong, and take steps to fix it.

Trying to “compete” - as it sounds like you may be trying to do - IS futile. But what are you competing over? Why would you feel the need to compete with the things you hate? That’s not where your battle is, it sounds like.

To be fair, you could play these games all day, and it still won’t register exactly what you’re doing because it lacks that repetition.

Try installing it across more machines and get some reps in that way:

• Maybe friends and family want to try it out
• Get a cheap VPS and host some basic services (not containers)
• Next time instead of installing a package for something you want to run, build from source
• Find a cheap laptop or two at a thrift store, garage sale, or Estate Sale you can beat on a bit

Having one machine working well just won’t get you the exposure you need. Identify some goal of anything you want working, and set about doing it the hard way.

Same way you started anywhere: practice.

Most people who use Windows cant, and don’t, need to fix a thing. Same thing in Linux.

The goal is to make the OS as compatible with as many machines as possible, to make sure that user intervention isn’t really needed, so you don’t really get that reflexive sort of knowledge unless you’re doing it for work and being exposed to it at a MUCH larger scale. Even then, you forget the things you don’t use frequently.

There tons of learning simulators out there for the basics. Just found this one. Give it a go: https://itsfoss.gitlab.io/post/test-your-bash-skills-by-playing-command-line-games/

Sorry, ma dude. This is 100% incorrect. Been doing this a long time, and have managed massive numbers of desktop sessions for enterprise end users.

Lookup dconf. It’s the tool that manages the underlying configuration engine for Gnome specifically.

Outside of the granularity there, you could also just lock everything to a group and exclude logged in users from that group. That’s a very simplistic way of explaining it, but achieves the exact same thing. You build a base image with only the apps the user needs, set execution to an inclusive group that user belongs to, and everything else to some other groups, and there you go. Dead simple.

Of course that’s not how you’d do it for an org with thousands of users, but you get the point.

Uhhhh yeah there is? You can customize any user profile and centrally control it just as you can on Windows. You can even PXE boot all workstations with new images whenever you want instead of relying on individual machines to issue updates, something that Windows isn’t capable of.

Not sure where you got this idea, but you’re misinformed.

For starters: Rails, PHP, and passthrough routing stacks like message handlers and anything that expects socket handling. It’s just not built for that, OR session management for such things if whatever it’s talking to isn’t doing so.

It seems like you think I’m talking smack about HAProxy, but you don’t understand it’s real origin or strengths and assume it can do anything.

It can’t. Neither can any of the other services I mentioned.

Chill out, kid.