https://www.amazon.com/DIOOEER-Dummy-Headless-Adapter-Emulator/dp/B0HBQJQSDS
This might not be what you want specifically, but this is the kind of thing that came to mind. Basically a stub that feeds EDID data into the GPU so it THINKS there is a physical monitor with any resolution you want connected.
There are more advanced models out there that will allow you to custom program the EDID that it feeds, so you can use higher resolution or frame rate or whatever.
For some people, the anticheat becomes the game.
I feel like I’ve heard stories about famous DRM crackers that don’t even play the games - the DRM battle is the whole point. And for some people, it’s not about cheating, it’s about beating the anti-cheat. It just sucks that when you beat the anti-cheat you have the side effect of ruining the experience for other players.
And also, some people are just REALLLLY pathetic and have to cheat at games to feel adequate.
And importantly, it seems to ship with mesa 26. Which fixes a DRM leasing, which means VR works. I was just able to play beat saber on my steamOS system.
Desktops can be installed on any ubuntu release. you could install xfce on kubuntu, or kde on base ubuntu. And what DE/WM you are using doesn’t matter in a quite a few scenarios, so it’s not worth bringing up in the same way that I don’t mention “Im using cachyOS niri wm”
I personally preferred xubuntu over kubuntu back in my *ubuntu days. etc etc. there are a lot of spins of ubuntu and when the only differentiator is DE (which you can also just install on base ubuntu), it’s easier to just talk about them all as a single overaching entity/family … ubuntu.
Talking about kubuntu inherently requires talking about KDE and ubuntu both, so people just skip the KDE discussion.
“Too many distro options” is already a complaint of a lot of non-linux users, so specifying every last spin can just drive people away.
Speaking of fsync vs esync vs ntsync.
As someone else has mentioned, proton or wine or games should not be able to cause “OS crashes”. If they do, its either an error happening somewhere else in the stack (a driver perhaps?) being triggered by the game, or you’re dealing with out of memory issues, and its struggling to clean itself up. I would suspect drivers (ie, make sure the system is updated) or memory, because those are the 2 aspects of a system that games tend to push the most.
But to your actual question: It’s a few things. The main thing that differentiates proton from wine, is that wine aims for maximizing global compatibility. Proton is focused on games, and is therefore able to make tradeoffs.
What if a new feature breaks MS Office because it changes how a function works, but doesn’t impact any games, and in fact, makes games fun 2-3x faster on average. Wine would not include this new feature. Proton would. They would put this into proton experimental.
But now they find out that while it makes MOST games faster, some games it causes to crash. Some games might use that same function MS Office does. so they don’t run properly. That might warrant a hotfix release. The point of numbered releases is to have points in time where most things are known working. If this feature had shipped into Proton 123, valve could pin the broken game to Proton 122, so now having different number versions makes sense to keep each individual game working optimally, while experimental and hotfix can be used for testing out new code (literally experimentally).
A great example of this was fsync. TBH, I have no idea what fsync is, but generally speaking, the games make a Windows function call that didn’t have a direct equivalent Linux function. Wine made a workaround to make sure this windows function did what it was expected to do, and there were several versions of the workaround. Some faster, some more reliable. And then eventually the function was actually added to the Linux kernel, so no work around was needed. For a while there, fsync vs esync was a big performance and compatibility concern. And now ntsync tends to cover this. Some games worked better with fsync and some with esync, and some with it all just turned off. But we need experimental proton versions to validate all of this.
QR codes on the net make no sense.
If I’m on the net… I’m already on the device that I want to visit a webpage from, just link to the webpage.
QR codes are for sharing something from one thing to another where there is no common interface other than a camera. The internet is already a common interface for sending me a URL, you don’t need a QR code.
For example:
If I were browsing on my phone, the only QR reader I have uses the camera. I can’t take a picture of my phone using my phone. I can’t use the QR code.
If I were on my PC, I dont have a QR reader at all except on my phone, and I’m on my PC, why would I want to switch to my phone.
Sharing a QR code on lemmy/piefed never makes any sense.
That’s really cool! It does sound like something I don’t particularly have a use for, but I see the appeal for others.
And giving it a test drive with flatpak is pretty simple, so no downsides for me there.
Keep up the great work.
This intrigued me so I grabbed it but I still dont quite know what I grabbed.
Is the whole point of this to be able to combine 2 controllers into 1 controller? Some of this feels niche, and like the people who need it will REALLY want it, but for most people, it does nothing beneficial, or am I missing something here that I should keep an eye on.
I believe wine has a WoW64 implementation now, to allow 32 bit software to run on 64 bit wine prefixes. Which means any windows games (unless they are 16 bit) can work on 64 bit non-multi-arch system.
Linux games are the core problem. But they also have a Steam Runtime where they ship the entire runtime libraries needed to run a game for compatibility reasons… and Steam Runtime 4.0 (which just shipped and/or announced a few days ago?) is set up for only 64 bit systems.
So if the answer is:
Then the answer is just “they’re getting around to it, they are only just now getting around to it for windows, and linux is a lower priority” because clearly its all possible.
So “What about linux?” is just asking if there is a timeline for the speed that things are moving in that direction.
Correct, so why does steam on linux still run as a 32 bit app and require 32 bit libraries to run games.
If IDEs from Flathub and CLI tools from Homebrew serve your needs, no further action is required. If deeper system integration is needed for VSCode (ie. devcontainers), Docker (ie. Podman is not sufficient), etc - then see below specialized images.
There is a whole Bazzite for Devs page that mentions Bazzite-DX for development to handle some things like devcontainers: https://github.com/ublue-os/bazzite-dx
Their main website also says:
Running a game, a development environment, a container for your Jellyfin server, or a utility only available on the Arch User Repository? You can rest assured it works here. Bazzite is developed on Bazzite.
At the end of the day, its an immutable fedora distro. Which may serve your needs. or may not. And bazzite’s primary focus is on gaming. It will most likely work (given a few criteria), but it may not given that is not their primary focus.
pre-ryzen AMD CPUs were always a bit on the budget side even when they were new. They were a bit more power efficient and cheaper, but never were amazing performance. So yeah, a 15 year old CPU is often rough, but a 15 year old low-mid end CPU is going to be even worse off.
Ive not had issues with Counterstrike 2 on linux, aside from wanting to play FaceIt or ranked matches that have stricter third party anticheat. And that’s just the anticheat being the problem.
I would venture a guess that linux is not “the problem” here and it’s more likely just aging hardware meeting increasing game demands.
The only time in recent years I’ve had specifically a problem with linux gaming performance (not related to anticheat), was playing VR on a pre-GCN AMD GPU which didn’t support async reprojection properly which caused quite a bit of stuttering.
Komodo Steam Deck Store rebranded to Komodo Station today. Which to me indicates that Valve’s distributor in Asia is already ready to begin selling more types of hardware. So that’s at least a positive sign.
https://github.com/FEX-Emu/FEX
My understanding is that FEX + Proton is the plan and just double up on the translations as appropriate.
Valve has supposedly just been heavily investing in fex.
Steam deck highlights that Windows -> SteamOS translation is good enough.
I’ve use my Index on Bazzite successfully with no issues, so I’m confident in SteamOS VR capabilities.
ARM-based is the only wildcard, but if fex works, then that’s not an issue either.
Then just onboard compute performance is the only factor. But like you said, even if this winds up only being a “stream everything, its a wireless index,” then I’m already excited.
There is an optional accessory for knuckle straps for these, mentioned in some of the 3rd party reviews.
Which somewhat implies the ability for custom knuckle straps and other accessories as well since they are detachable with mount points.
edit: screenshots from the LTT coverage:
And it is recognized in game by comparing the steam user ID of the other players on the server. Which means if someone else spoofs their name it won’t work. But if real Garry is there, achievement confirming it is him
Not detecting case fans sounds like it would be not communicating with the motherboard properly. Unfortunately every specific motherboard is going to have it’s own unique set of constraints. But generally this is all handled through “it87” i believe? But it87 can sometimes take some nonstandard params.
Here’s an example gist of instructions for getting things working on one specific motherboard. https://gist.github.com/bakman2/e801f342aaa7cade62d7bd54fd3eabd8
The wifi7 on my motherboard causes kernel panics pretty regularly, and the RGB isn’t properly exposed so I cant control(/turn off) any of the lights. Usually these things work themselves out with time as drivers for the new/nonstandard chips make their way into the kernel/libraries.
Another solution I’ve played around with, but it didn’t work super well… would be
krfb-virtualmonitorKDE’s remote framebuffer tool for making a virtual monitor to VNC into. For me it didnt do what i wanted because I have 3 other monitors and I couldn’t assure that things would launch directly into the virtual monitor… and it doesnt support any sort of dynamic resizing… But there might be something there.
I also hope that this kind of stuff improves in the future because of the Steam Frame. In Tested’s video, he calls out that he can only stream games at 21:9 if his 21:9 monitor is on. And other VR friends have pointed out the desire to dynamically resize content in the headset. So maybe this will get better in the future.
For me the issue is that i have a OLED 21:9 desktop, and streaming to my Steam Deck risks burn in on my desktop, and annoying black bars on my steam deck… I’d love to just have a 1280x800 faux monitor to stream to my steam deck, nothing needs to be visible on the desktop (headless, like you want).
But anyway tl;dr -
krfb-virtualmonitorvaguely worked but not for what i needed. Virtual monitors are definitely a possibility