I’m not sure what you’re referring to.

Steam itself is only available as a 32-bit binary, if I remember correctly.

checks

Yeah, on my system, looks like a 32-bit binary.

If Steam runs a game, which can be either 32-bit or 64-bit, I believe you need to have libraries for the corresponding architecture for stuff that isn’t in the Steam Ubuntu-based collection of libraries, the stuff in ~/.steam/steam/ubuntu12*. If you’re running a 64-bit binary, you need 64-bit libraries, and for a 32-bit binary, you need 32-bit libraries.

I have GPU libraries for both architectures installed on my Debian system, like libdrm-amdgpu1:amd64 and libdrm-amdgpu1:i386, with multiarch.

One thing that I found out was that as “most-Minecraft-like” games for Minetest, there’s apparently Voxelibre (renamed Mine Clone 2) and Mineclonia (fork of Mine Clone 2). Just out of curiosity, if you looked at both, what made Voxelibre particularly appealing relative to Mineclonia?

I’ve played Minetest, even contributed some code IIRC, but that was some time back, haven’t ever played the derived games. Kind of thinking about maybe giving it a go now that there’s apparently more there.

voxelibre

I was going to ask “how does that compare to Minetest?” But after a bit of investigation, apparently it is a renamed Mine Clone 2, which is a game for Minetest.

No.

arent these controllers supported by fwupd?

Mine’s currently plugged in, and running fwupdmgr get-devices doesn’t have it show up as an updateable device, so I assume not.

Oh also I was surprised by the battery life; I think it was advertised as having 12 hours, but after 2 years of using it I happened to notice that I had 25-30 hours of playing time in a game

If it has a rumble motor, that probably dominates power usage. I don’t know how they come up with an “hours” number, probably work out some percentage of time that the rumble motor is active, but I could easily see that varying game-to-game.

Because my desktop doesn’t have Bluetooth, I usually use a wired Xbox One controller, though because of the micro-usb I can’t say I’m a fan.

It’s not hard to get a USB Bluetooth controller for a PC.

All that being said, I don’t really think that wireless is generally worthwhile for a PC, unless you have some kind of home theater setup in your living room. If you have a wire, you have plenty of power, no concern about battery life, no interference potential (though I haven’t had problems with Bluetooth, I have with proprietary 2.4GHz protocols), less moving parts.

With video game consoles, running a wire across someone’s living room was really obnoxious; the tradeoff makes a lot of sense there. But if I’m sitting right in front of the computer, none of that really applies. It avoids me maybe managing to wrap one cord around another, but that’s about it, and I don’t think that that’s enough of a benefit.

And I’d rather not be broadcasting unique Bluetooth IDs. Okay, probably not that big a deal from a privacy standpoint with desktop hardware that doesn’t move around, doesn’t have the kind of “tracking someone’s movements” concerns that Bluetooth devices that are carried around do, but I don’t really need every nearby cell phone telling Google or Apple when I’m playing a video game, having them build up a database spanning my whole life.

I use an 8bitdo Ultimate Bluetooth with Hall effect thumbsticks – which may be what you’re using – but in wired mode.

It, unfortunately, has a Nintendo-style button layout rather than an XBox-style layout, but at least when I bought it, and maybe still, you couldn’t get both an XBox-style layout and Hall-effect thumbsticks. They did sell replacement button caps and you could replace them, but Steam Input allows remapping.

I do think that it’s a little obnoxious that Linux doesn’t have One Unified System for creating up virtual gamepads or other controllers out of other controllers. Like, the technical plumbing to create virtual devices is there – you can create virtual libevent devices. But there isn’t a great backend for doing that systemwide and in a persistent fashion, no controllerd that takes some sorta description file setting up controllers both systemwide and on a per-application basis. Like, I should be able to have a virtual controller where if a program wants to fiddle the LED color, I just have, I don’t know, colored keyboard LEDs change or something like that. Or remap buttons, or set up macro functionality – which is what you want – or set up buttons to switch between multiple settings in-game or whatever.

It’s great that Valve’s doing some of that with Steam Input – and they do offer some neat things, like people sharing Steam Input configs on Steam – but I feel that we shouldn’t really need to rely on Valve for something like that.

Various controllers that I’ve used on Linux in the past:

• Playstation 2 controller. Worked great, used until it wore out. Had some kind of USB adapter, IIRC.

• A Logitech F710. The D-pad rolled to diagonals too easily for my taste, but other than that, perfectly fine, worked well for quite some years. Took removable AAs, which I liked (though that does come with some weight). Unfortunately, it uses a proprietary wireless protocol on 2.4GHz, and at some point, something in my environment started occasionally disrupting it. Bluetooth and wired controllers aren’t affected. I had to switch, couldn’t stand every now and then the controller not functioning for a brief period.

• Various XBox controllers. I don’t really like the XBox layout as much as the Playstation layout, but, eh, not a huge deal; they’re reasonably interoperable. And most vendors had adopted the XBox layout. However, I have something like three different controllers using potentiometers that have drift issues. Yeah, probably possible to hide that in software, increase size of the dead zone, but goddamn it, I want to have a controller that just works correctly. Prompted me to get a controller with Hall effect sticks, which have been fine.

• A PS4 controller. IIRC that worked, but in 2024, too many games on the PC recognize and set themselves up properly for XBox controllers, but not Playstation controllers. There’s another issue that could have been fixed with a controllerd exposing a virtual XBox controller…

I also have various non-gamepad controllers floating around, like a HOTAS setup and pedals. I would not buy a HOTAS setup these days unless you are really in love with a flight sim that uses it – gamepads with thumbsticks are “good enough” for analog input axes on the PC, and widespread enough that a lot of games will only support those.

But I can’t update firmwares

Use Windows VM with pass-through USB?

kagis

This guy did it on an 8bitdo controller via an Android updater:

https://old.reddit.com/r/8bitdo/comments/ttqwzm/is_there_a_way_to_update_8bitdo_pro_2_firmware_on/

Whether-or-not there should be more alternatives (and there are, like gitlab, savannah.nongnu.org, and such), I don’t think that GitHub being down is a good thing.

There are a lot of open-source projects for which it is the authoritative repository. Okay, granted, there are probably cloned copies of most of that, but there’s a lot of stuff that uses it; it’s disruptive.

And it’s the only source for issue-tracking for a number of those projects hosted there. Like, there are people who are trying to fix problems. This disrupts them.

It’s actually kind of interesting. I mean, not the software package, but I didn’t know that some of this hardware even existed until reading this.

Have you tried decreasing Starfield’s texture resolution to minimum to see if it persists?

EDIT: Or, better, just set the render quality to minimum, since that’ll test a number of other possible causes at the same time.

I haven’t used it recently, but last time I did, I used MO2 with vanilla WINE, just setting my WINE prefix to the Skyrim Proton prefix. WINE and Proton would convert the registry in the WINE prefix back and forth each time one launched. I haven’t used SteamTinkerLaunch.

Prior to that, I used Wrye Bash, which was a mess to get working in Linux – but could run natively, at least at one point, with some prodding. I’ve also run it under WINE. It took a lot of massaging. I don’t recommend that route unless you can program, know Python and are willing to get your hands dirty.

And I also had a stint where I wrote my own scripts to reconstruct the modded environment from scratch.

My most-recent attempt for Bethesda modding was in Starfield, with a much-simpler CLI mod manager, this. I have gotten some mods working but not others; don’t know if it’s a case-folding issue. Will need more experimentation. It doesn’t have the conflict-diagnosis tools that Wrye Bash does, or I assume MO2 probably does (though I haven’t run into). I don’t think it supports Skyrim, Fallout 4, or Fallout 76; that probably matters at least insofar as mod managers for those need to merge leveled lists. My (brief) impression is that the Starfield modding community is heading down the direction of avoiding needing the mod manager to do that, having a mod that merges that stuff dynamically at game runtime.

the performance is not great.

Uh. The performance of MO2 or Skyrim?

MO2…I don’t recall, it might not have been snappy, but I don’t recall it being especially unusable. Certainly not at the level that I wouldn’t use the software. I was using a reasonably high-end system, but I don’t think that it’s particularly resource-intensive. I was running off SSD, and maybe some of the stuff might have been I/O intensive.

Skyrim was fine from a performance standpoint. I mean, you can obviously kill performance with the right mods, but I assume that you mean “modding at all”.

EDIT: If you put a lot of mods into Skyrim, like, hundreds, it can take a while to launch. IIRC, one problem – not Linux-specific – there is that loose files aggravate launch performance issues. My understanding is that, where possible, use mods that merge files into a .BSA rather than loose files. A number of mods have multiple versions; pick the .BSA one.

EDIT2: Skyrim, Fallout 4, and the Fallout 76 versions of Bethesda’s engine don’t really take much advantage of multiple cores the way the way the Starfield version does. I get buttery-smooth performance in Starfield; Fallout 76 invariably is a bit jerky when loading resources in a new cell. I don’t get a pretty consistent framerate at 165 Hz in Fallout 76 the way I can in Starfield. But I don’t know if that’s what you’re running into, without specifics of the performance issues. And that’s not gonna be a Linux-specific issue or anything that can realistically be resolved short of forward-porting the Skyrim, Fallout 4, and Fallout 76 games to the Starfield engine.

Yeah, I use Steam as a deb too.

I haven’t done it, but as long as Steam itself is isolated – as I expect flatpak Steam is – anything it launches will be too, and you can add arbitrary binaries. AFAIK, that works with Windows binaries in Proton.

https://help.steampowered.com/en/faqs/view/4B8B-9697-2338-40EC.

Referring to your response to dillekant, I’m not sure how much Steam buys you in terms of security, though, unless you’re buying from Valve. The flatpak might provide some isolation by virtue of being flatpak (though I dunno how many permissions the Steam flatpak is granted…I assume that at bare minimum, it has to grant games access to stuff like your microphone to let VoIP chat work).

https://docs.flatpak.org/en/latest/sandbox-permissions.html

Steam, itself as of today, doesn’t provide isolation, at all.

Adding a non-Steam game to Steam lets you launch from Steam, which might be convenient. Maybe use Proton, which has a few compatibility patches.

If I wanted to run an untrusted Windows binary game today on my Linux box, if it needs 3d acceleration, I don’t have a great answer. If it doesn’t, then running it in a Windows VM with qemu is probably what I’d do – I keep a “throwaway” VM for exactly that. It has read access to a shared directory, and write access to a “dropbox” directory. I wouldn’t bring Steam into the picture at all. I don’t want it near my Steam credentials (Steam credentials have been a target of malware in the part) or a big software package like Steam that may-or-may-not have been well-hardened.

It does get network access to my internal network – I haven’t set up an outbound firewall on the bridge, so a hostile binary could get whatever unauthenticated access it could get from my LAN. And it could use my Internet connection, maybe participate in a DDoS of someone or such. But it doesn’t otherwise have access to the system. It isn’t per-app isolation, but if the VM vanished today, it wouldn’t be a problem – there’s nothing sensitive on it. It doesn’t know my name. It can’t talk to my hardware, outside of what’s virtualized. It doesn’t have access to my data. There are no credentials that enter that VM. Unless qemu itself has security holes, software in the thing is limited to the VM.

I have used firejail to sandbox some Linux-native apps, but while it’s a neat hack, and has a lot of handy tools to isolate software, I have a hard time recommending it as a general solution for untrusted binaries. I don’t know how viable it is to use with WINE, which it sounds like is what you want. It has a lot of “default insecure” behavior, where you need to blacklist a program for access to a resource, rather than whitelisting it. From a security standpoint I’d much rather have something more like Android, where firejail starts a new app with no permissions, warns me if it’s trying to use a resource (network, graphical environment certain directories) and asks me if I want to whitelist that access. It requires some technical and security familiarity to use. I think the most-useful thing I’ve used it for is that it mostly can isolate Ren’Py games, cut network access, disk write access, and a number of games (though not all; arbitrary Python libraries can be bundled) can work with a reasonably-generic restrictive firejail renpy profile. It just requires too much fiddling and knowledge to be a general solution for all users, and “default insecure” is trouble, IMHO.

I do wish that there was some kind of reliable, no-fiddling, lighter-weight per-game isolation available for both Windows binaries and Linux binaries out-of-box. Like, that Joe User can use and I could recommend.

I did see something the other day when reading about an unrelated Proxmox issue, talking about Nvidia apparently having some kind of GPU virtualization support. And searching, it looks like AMD has some kind of “multiuser GPU” thing that they’re billing. I don’t know how hardened either’s drivers are, but running VMs with 3d games may have become more practical since last I looked.

EDIT: Hmm, yeah, sounds like QEMU does have some kind of GPU virtualization these days:

https://ubuntu.com/server/docs/gpu-virtualization-with-qemu-kvm

Need native performance, but multiple guests per card: Like with PCI passthrough, but using mediated devices to shard a card on the host into multiple devices, then passing those:

-display gtk,gl=on -device vfio-pci,sysfsdev=/sys/bus/pci/devices/0000:00:02.0/4dd511f6-ec08-11e8-b839-2f163ddee3b3,display=on,rombar=0

You can read more about vGPU at kraxel and Ubuntu GPU mdev evaluation. The sharding of the cards is driver-specific and therefore will differ per manufacturer – Intel, Nvidia, or AMD.

I haven’t looked into that before, though. Dunno what, if any, issues there are.

EDIT2: Okay, I am sorry. I am apparently about four years out of date on Steam. Steam didn’t have any form of isolation, but apparently in late 2020, they added Pressure Vessel, some form of lxc-based per-game containerization.

I don’t know what it isolates, though. I may need to poke more at that. Pretty sure that it doesn’t block network access, and I dunno what state the container gets access to.

When people talk about things like sandboxing, they are almost always talking about library dependencies and not any kind of security context

Uh. I don’t think I can agree with you on this. Sure, Steam has a mini-Ubuntu distro, and there are a few packaging techniques to bundle libraries, but I’d say that that’s much less-common of a topic of discussion than security context.

Wikipedia talks about security context:

https://en.wikipedia.org/wiki/Sandbox_(computer_security)

The top hits on Kagi for “linux sandbox” are about security.

I was just wondering what would happen if I downloaded a game that was infected by a computer virus and ran it in Linux using Proton.

Depends on the mechanism. Some viruses will target stuff that WINE doesn’t emulate – like, if it tries to fiddle with Windows system files, it’s just not going to work. But, sure, a Windows executable could look for and infect other Widows executables.

Has this happened to anyone?

I don’t know specifically about viruses or on Proton. But there has been Windows malware that works under WINE. Certainly it’s technically possible.

How would the virus behave?

Depends entirely on the virus in question. Can’t give a generic answer to that.

What files, connections or devices would it have access to?

WINE itself doesn’t isolate things (which probably is reasonable, given that it’s a huge, often-changing system and not the best place to enforce security restrictions). On a typical Linux box, anything that you, as a user, would, since Linux user-level restrictions would be the main place where security restrictions would come into play.

I do think that there’s a not-unreasonable argument that Valve should default to having games – not just Proton stuff – run in some kind of isolation by default. Basically, games generally are gonna need 3d access, and some are gonna need access to specialized input devices. But Steam games mostly don’t need general access to your system. But as things stand, Steam doesn’t do any kind of isolation either.

You can isolate Steam as a whole – you can look at installing Steam via flatpak, for one popular option. I don’t use flatpaks, so I’m not terribly familiar with the system, but I understand that those isolate the filesystem that Steam and its games have access to. That being said, it doesn’t isolate games from each other, or from Steam (e.g. I can imagine a Steam-credentials-stealing piece of malware making it into the Steam Workshop). On the other hand, I’m not totally sure how much I’d trust Valve to do a solid job of having the Steam API be really hardened against a malicious game anyway – that’s not easy – so maybe isolating Steam too is a good idea.

Could it be as damaging as running in in Windows?

Sure. If it’s not Linux-aware, it probably isn’t going to do anything worse than deleting all the files that your user has access to, but in general, that’d be about as bad anyway. If it is Linux-aware, it could probably do something like intercept your password next time you invoke sudo, then make use of it to act as root and do anything.

I’m not familiar, but:

https://www.reddit.com/r/WindowsMR/comments/18nu45p/hope_for_wmr_on_linux_controller_track_reverse/

This was six months ago, when someone was talking about working on reverse-engineering it. It sounds like the project you want is “monado”.

https://monado.freedesktop.org/

Based on the table at the above link, it sounds like there is experimental support for the display only, and no controller support.

Experimental 6DoF tracking support with external SLAM/VIO systems is upstreamed but still being worked on. Tested with RealSense D455 and Samsung Odyssey+, Reverb G2, Oculus Rift S.

I don’t stand to gain by working on running a game in Proton if I can just run it natively in Linux, but if someone else wants to try and get it working and post their results, I suppose that’d be one more data point.

For me, the value in Proton is just the ability to run stuff that I can’t run natively in Linux.

Not familiar with it – never used gamescope myself – but there are various people talking about what may be your issue at:

https://github.com/ValveSoftware/gamescope/issues/782

and

https://github.com/ValveSoftware/gamescope/issues/1180

And they list other workarounds.

The -steamos3 thing looks like it might be worth a try.

I won’t recommend a particular model, but I will say that my experience with “touchpad control” based headsets, as compared to ones with mechanical buttons and switches, has not been very good. Controls are unreliable and too prone to being bumped. Unfortunately, a number of high-end headset makers seem to like making these