The way I use Lutris today is nothing more than a prefix manager, I click add game, set up my prefix, and install my games manually.

New features will be unlikely, but not entirely off the table if there’s a really good reason to include them.

Given this, wouldn’t simply bookmarking the last Lutris release that you find acceptable be an easier way to meet your needs?

Or are you trying to guard against Lutris disappearing or retroactively changing old versions?

Interesting. This one looks more powerful than most attempts I’ve seen.

One of my key questions is addressed in the FAQ:

Hard link or symlink? What about a Mo2 style vfs?

• They all achieve the same goal but each comes with downsides
• Hard links can be loaded fast and take up no space, However when the source file is removed the hard link is removed which can cause issues. The hard linked file must also be on the same drive as the source file. They also look like normal files and report as taking up space which can cause confusion
• Symlinks can be created between drives and are distinguishable from normal files. Removing the source file stops the symlink from working but the symlinked file still shows as a symlink and can be easily removed. The downside of these are they much worse than hard links when playing with large modlists as they take longer to load. The manager allows you to freely swap between both methods and symlinks may be fine for smaller modlists.
• Mo2 style vfs (FUSE and overlayfs): These have the benefit of not moving any files to the game directory. I have added both of these to a test build, Neither provided any real benefit over hardlink/symlink and caused more issues than it was worth.

https://github.com/ChrisDKN/Amethyst-Mod-Manager/wiki

Does this one have some advantage over !linux@programming.dev or !linux@sopuli.xyz or !linux@lemmy.zip or !linux@linux.community or !linux@sh.itjust.works ?

Response to your edit:

I am not among those who downvoted, but since you asked, I’ll offer a guess as to why so many people did:

1. The way you phrased your second sentence, it could be interpreted to mean that you consider the story to be inappropriate here. Perhaps some people (especially those who read Lemmy while in a hurry) thought that was what you meant. It could have been made more clear if you had written, “this was reported…”.

2. This story is relevant to people all over the world, while the complaint you received was that it concerns a US company. Those two things are not mutually exclusive. I believe more than a few members of this community, maybe even most, recognize that fact, and find it unacceptable for their news channel to obstruct information that concerns them just because the source happens to be in the US.

   To be clear, the rule here forbids “United States Internal News”. The rule does not forbid “News emerging from the United States”. Since the policies of a major global reference source like Wikipedia are clearly not US internal news, some community members surely recognize that flagging it for removal was inappropriate. I happen to share this view, and this is not an isolated incident.

   Once in the past, I submitted a scientific report, and it was removed here on the grounds that the scientists were in the US. The post was not “United States Internal News” and did not break any of the community’s rules. It was scientific research, without geographic or political boundaries. It was relevant to everyone. And yet it was denied visibility to us, the members here. I found that absurd, and deeply concerning: This community, which positions itself as a global information source, was filtering out information in a way that we have come to expect from state-owned media in authoritarian regimes. And it was presuming to treat scientific research as though it were somehow invalid just because it had been done in the US.

Edit:

In any case, I hope this helps you to understand some likely reasons why your comment received downvotes.

Those of us who have walked in the moderator’s shoes for long enough will come to understand that sometimes it’s the complaint that is misguided, not the target of the complaint, and that broadcasting such complaints (as you did here) gives them an air of validity that they do not deserve.

I considered that the nonprofit organization behind Wikipedia is in the US, but decided that World News is appropriate in this case, since a great deal of the world relies on it, and since its content comes from international contributors. So I guess our thoughts are mostly aligned.

Thanks for allowing it.

That’s strange.

To make sure I’m not hallucinating, I booted a Debian Trixie installer live image just now and plugged in a game controller. Sure enough, lsmod showed the joydev module loaded, and /dev/input/js0 appeared. Between that and the Trixie system I mentioned earlier, I think I’ve confirmed that js devices are still created by default.

I wonder why your system doesn’t have them.

Have you tested on a fresh boot, without starting any games or game-related software? I ask because it’s possible that the device node is being created, but something else on your system is removing it. Do you use the Dolphin emulator by any chance?

Edit: I would expect the joydev module to remain loaded even if the device node was removed. This really does seem strange.

And this is with a game controller connected and powered on?

SDL, for example, which will use js devices depending on the circumstance.

Your own link points out that even SDL 1 — very old now — doesn’t use the js interface unless forced to do so.

In other words, people with stick drift can calibrate it away using the js API, and have it applied to SDL 1 games by setting an environment variable.

In any case, I don’t know why you’re campaigning so hard against my suggestion to start with the js API. It’s easier than calibrating evdev, it actually affects the generated stick values (unlike evdev), and there’s certainly no harm in starting with it. A more interesting pursuit would be determining whether any popular input libraries apply evdev’s deadzone/flatness value before passing stick readings to a game.

I’m running Debian trixie.

Debian Trixie does create js devices.

IIRC in the past, for a while when the evdev interface showed up, a problem was that games that could talk to both interfaces would sometimes get double input, because a number would aggregate all input from all joysticks, and so if one had both the js and evdev interfaces visible, they’d see it as two joysticks both; a fix was to not expose them via the js API, rather than leaving them exposed via both. I don’t know how that’s evolved over time, but it may have been a factor encouraging not exposing them by default. I’ve certainly seen the “double input” behavior myself, maybe ten, fifteen years back.

I’m looking at a Trixie system right now, and /dev/input/js0 appears just as expected. Is it possible that you modified your Debian installation way back then, to disable your js devices? Maybe you (or some package you installed) applied a udev rule to block them?

Most? I think you would need to measure that. A great many games rely on a library for joystick input. SDL, for example, which will use js devices depending on the circumstance. Some bypass both APIs in favour of raw HID protocol. And then there’s Steam Input.

In practice, I’ve found that calibration at the joystick API level took care of dead zone problems in most of the software where I noticed them. Of course, one’s results will depend on the game, which is why I suggested calibrating jsapi to start with, rather than calibrating only it.

Also, the evdev API’s calibration tools are not as well developed as those for the js API, making it harder to do. And its deadzone/flatness value did nothing at all to stick axis readings in my recent tests, suggesting that it wouldn’t fix stick drift anyway, unless a game deliberately applied the flatness before using the readings. (The fuzz value did affect the readings, but seems to be for smoothing out numeric noise, not fixing stick drift.)

What distro do you use that doesn’t create /dev/input/js* devices?

The Arch wiki has a lot of good info on this:

https://wiki.archlinux.org/title/Gamepad#Setting_up_deadzones_and_calibration

I would start with section 2.2.3: Joystick API deadzones and calibration, because the joystick API is the lowest common denominator for this stuff.

It is false because it is not what he said, and does not have the same meaning as what he said.

Moreover, your misrepresentation is damaging to the developer’s reputation, and misleading to everyone reading here. Please stop.

It is false because it is not what he said, and does not have the same meaning as what he said.

Libel requires the statement to be false.

Indeed. And your statement that you now describe as “paraphrasing” was false.

That’s not what he said.

https://www.merriam-webster.com/dictionary/libel

I think mpd is better suited to your purpose than any GUI media player.

Note that despite its network support, it can run and be controlled locally. Cantata uses it, for example.

The kernel log you posted appears to be from an X11 session. (Note the many instances of AppArmor allowing Xorg to do things.) You’ll probably need the Wayland logs if you want to troubleshoot Wayland.

Unfortunately, I can’t guide you, since I’m not using Nvidia or Wayland.

Since this is a gaming rig, I think it’s worth considering an X3D CPU instead of the 9700X. The extra cache has been known to help games quite a bit.

attempting to smuggle more than 2,000 queen garden ants out of the country.

It is believed that the intended destinations were the exotic pet markets in Europe and Asia.

Slow to change sucks on the desktop pretty often.

Subjective opinion there.

I like Debian on the desktop. It does what I need, gets out of my way, and minimises surprise changes in the software I use. In other words, it respects my time.

If I were new to unix admin (as OP appears to be) I might try something like openmediavault for a home server.

It’s important not to confuse emulator with hardware emulator. (Sadly, this confusion has been common on social media in recent years.)

A system can emulate another system without emulating hardware.