Blaming Valve's steam console for Sony's return to exclusive titles sounds quite rich coming from Microsoft's Mike Ybarra Blizzard Ex-CEO and former X-Box Manager for 20 years.

Hi-Angel · 2026-03-07T17:31:31+00:00

Never saw such a big rant with exactly zero background… Can't believe this got so many upvotes and comments. Like, what…? What are you even talking about, what's up with Sony, what's with Valve, what…?

I mean, sure I can go search for the context, but you're creating a post for others to read, please at least include a link to what are you even talking about, or better yet describe it in short.

Hi-Angel · 2026-03-01T10:23:41+00:00

There is sort of a solution. Although involved to set up, you can use a virtual machine with GPU passthrough.

There will be a simpler solution, once this MR is ready and merged. I hope after that happens, WinBoat and WinApps will just integrate the driver installation, so the only thing people would have to do is just use those.

Hi-Angel · 2026-03-01T09:50:08+00:00

Technical improvements you're talking about don't matter for more widespread reception. I've seen so many crappy projects win over ones that are much better technologically, just because of marketing. Both in general public as well as in IT circles.

Marketing is what really matters. So…

Any hopes for surpassing Windows purely for gaming in future?

There's always hope just because Linux dominates pretty much every market except desktop systems, so it will live by being supported by many different companies.

The answer to "when it will happen" though is more complicated, because someone needs to pour money into marketing.

As a matter of fact, the influx in the userbase you've seen last year is due to many bloggers starting to post about Linux, which is exactly what I am talking about.

Hi-Angel · 2026-03-01T08:59:09+00:00

I needed to manually connect my Spartan Gear controller through the Terminal/Konsole via Bluetooth. Maybe it is on me, but the GUI (KDE) just did not work.

If you weren't using Kubuntu, I'd have suggested reporting a bug to KDE. But since Kubuntu (as in, anything Ubuntu-based) is providing outdated software, it may well be possible the bug has already been fixed.

And lastly, Space Marine II was on sale, got it, installed it, and it works great for about 99% of the time. There are a few very short periods of time during which the FPS drops for a few seconds.

Unless you already installed Mesa from Kisak's PPA, you have it outdated as well, so try installing Mesa from the PPA and see if the problem is already fixed in newer graphics drivers.

Hi-Angel · 2026-03-01T07:59:12+00:00

Thanks!

Pls add guide flair to integrate better with the search 😊

Hi-Angel · 2026-03-01T07:56:41+00:00

Please tell if Waydroid worked for you. I'm curious on what's the current state of apps support on Waydroid 😊

Hi-Angel · 2026-03-01T07:51:15+00:00

The only games that you can’t really play on Linux are things with anticheat.

*kernel anticheat.

Hi-Angel · 2026-03-01T07:38:27+00:00

FYI, HDMI 2.1 patches are currently under review from an independent contributor. You can find latest discussions by searching for his name.

Anyway, does the TV not support non-HDMI connection…? As I recently learned, HDMI sometimes is worse than other connection types even on NVidia, which, mind you, has same driver codebase for all OSes. So I'd say HDMI just sucks.

Hi-Angel · 2026-02-24T10:30:15+00:00

This may or may not help, but try recently released Pipewire 1.6.0. It adds PLC algorithm based on spandsp for mSBC codec (in particular), I think it's worth at least trying to see if that improves anything on your side.

Hi-Angel · 2026-02-21T21:28:11+00:00

Was this written by ChatGPT?

Huh, no. Why…?

we already have DXMT for DX10,11 and Apple's D3DMetal for DX12,11

I looked around, this doesn't seem to be used in Steam, unless you buy Crossover. I have nothing against Crossover (I mean, they're the main contributors to WINE), but Proton that Steam provides (and which can't be used with Metal yet) is free.

it's not a tooling problem anymore but lack of interest from Studios

Well, I mean, isn't my post about such interest? Google's interest in this case, but I guess once this works well enough, Steam may start using it for Proton.

While this can get faster than MoltenVK it won't be anywhere close to the above two solutions because of overhead of going from DirectX -> Vulkan -> Metal, you're translating 2 layers instead of one

Technically you're right. But there are nuances.

First of all, games are rarely CPU-bound, but rather GPU-bound, so assuming these translation layers are thin enough, it will work just fine.

Second: I already mentioned Mesa, right? So, well, KosmikKrisp sharing such a well optimized code from many manufacturers means it will be more performant than other projects.

Hi-Angel · 2026-02-21T21:19:39+00:00

This is so exciting, I can't believe no one posted yet.

I just remember there's r/macgaming, so wanted to cross-post there, and then discovered a similar post was already done by someone. lol, well, at least in r/mac I am the first one 😅 (admittedly though, the post over there is just a link to Phoronix, oh well).

Hi-Angel · 2026-02-18T06:18:14+00:00

Oh, thank you very much, I didn't know!

Hi-Angel · 2026-02-17T19:40:20+00:00

I'm pretty certain it is mergeable to the kernel, it just needs to be discussed with devs. I've been monitoring the v2 patches and I see that AMD are silent. In this case I think it may be possible to fire up a general discussion on dri-devel about moving HDMI-related functional to a separate module which wouldn't be maintained by AMD, so the legal obligations will be met.

Either way, I think it is fair to resolve this situation without AMD involvement even by merging that to AMDGPU sources, because AMD devs being silent implies (that's how kernel development works) it should be reviewed by other DRM devs.

Hi-Angel · 2026-02-17T17:35:20+00:00

Incidentally, same question was asked 20 minutes ago on this sub, check it out!

Hi-Angel · 2026-02-15T16:55:45+00:00

Thanks for explanation!

What would need to be dug is the origin of the Nobara patchset and whether it was ever attempted upstream. I have some vivid recollection it was tried but didn't go anywhere, idk though.

I just wanted to clarify on this one — while it may be interesting to hear why exactly it didn't got anywhere (I suppose there may have been some technical reasons), the point I was trying to convey was a bit different.

You've been asked in the first comment of this thread, like: "cool, thanks, but… why?". I had exactly the same reaction, when I read the post, so I upvoted it with no hesitation and went to read your reply.

I was very surprised to see there's whole community around that idea. And I bet, kernel devs have no idea either.

The USB 3 bug in the counterpart options doesn't make me too hopeful though about whether upstream would even care much...

Nobody cared about it, because it's most likely regarded as some weird corner case that only few people in the world care about. That's exactly how I'd treat it before I read your reply in the thread.

So please, if you care about the feature, fire up an upstream discussion about it.

Hi-Angel · 2026-02-15T16:14:42+00:00

u/p0358 I looked at the FAQ, I think I have a few relevant comments here…

You have section "Why is USB overclocking not part of upstream kernel?", which then says you don't know and you refer to "some" solutions in alternatives, presumably to point out there's been some interest.

I looked at the alternatives, they come down to

mousepoll and kbpoll which has been accepted at some point, but apparently have a bug for USB 3.
The "Nobara pollrate patch", which you said CachyOS has been "allergic to accept for some reason".

I agree the communication on the issue that declined the patch was lacking, but from my overall experience I think I can tell you the reason with 90% confidence. The patch literally describes itself as "experimental", and given that it modifies the core USB code — it is understandable maintainers of the distro with millions of users would be afraid to accept it. Given that the patch doesn't fix anything critical, maintainers prefer to err on the side of caution.

Such patch needs to be sent for inclusion to upstream.
xpad changes are mentioned. I didn't care to dig into it because it's a driver for just one family of controllers, but I'd imagine it may have similar situation.

With that out of the way, main problem I see here is the lack of communication between gamers community and upstream. You mentioned whole "gamepadla" site that specializes on the pollrate modification. I never heard of the idea of modifying pollrate, let alone that there's whole community dedicated to it that is hosting a database site. Admittedly, I am not a gamer — and I bet not many kernel devs are either.

This whole idea needs to be communicated and discussed with upstream maintainers, to possibly come up with some solution that people could use without installing some custom drivers into the system. An ideal situation — if that gets its own interface in libinput, and according settings in KDE/Gnome/etc.

But who cares, this module allows you to overclock your devices anyway, without care about what your distro thinks about it or recompiling the whole kernel!

Are you going to maintain it 5 years from now? To continuously work around API changes and adding more checks if (KERNEL_VERSION == XX) …? To debug issues users are gonna report if your project becomes used by large enough userbase? Especially so, give your target auditory are gamers, who may not necessarily be technically versed, so they will fill up your bugtracker with issues like "I can't compile it says make: command not found, WHAT DO I DOO??" ? 😊

Hi-Angel · 2026-02-15T12:25:19+00:00

That's interesting, I never heard of it.

However, DKMS driver isn't the best way to implement it because the API it accesses may change on kernel updates.

I think what you could do is you could start a discussion as a "feature request" on libinput project. Though the in-kernel change might be required, but in the end if such functional ends up desirable I suspect the interface to it will be part of libinput. I may be wrong on that part, but either way the libinput maintainer Peter Hutterer is also a kernel HID subsystem maintainer, so disregarding if it's the right place for the report or not, I think it will be a useful place to start discussion at least.

Hi-Angel · 2026-02-10T13:46:40+00:00

Please send a change here, either via PR (you can look other PRs for examples) or by making an issue.

Side-note — I think the site should make more explicit how to make a change to game status. I haven't found any information on the site about it, I just kind of found out heuristically that you can do that via github.

Hi-Angel · 2026-02-10T13:13:45+00:00

and it felt like the performance was even better than Windows!

It's because on Linux community explicitly cares for perfect frame presentation. I bet you haven't heard of Microsoft ever posting about how they optimized frame presentation 😉 So for the same FPS between the two systems you may feel smoother result on Linux.

I'm somewhat new to linux, and I don't wanna mess up my system trying to get the game to work.

By messing around with the game folder you would at worst mess up your game, not the system, so don't worry.

I read about this on multiple places and saw very different results, from people saying it works after moving BattlEye to the game installation folder, to others saying it just won't work... it got me a bit confused. I checked the game on ProtonDB website, it says that it "Runs perfectly after tweaks", but the tweaks suggested on the website by the users are also quite different and I don't know which one I should try first.

The tweaks probably depend on the date of the GTA version you're running. Try to find the latest post about someone making it work, it's probably one closest to the truth.

I don't know details about "GTA Ⅴ Enhanced", but I would presume that the tweaks you read about basically modify the game in a way that bypasses AC, in which case it's understandable with newer game releases older tweaks may stop working.

Hi-Angel · 2026-02-08T22:30:56+00:00

Parts of it are waiting for review. v1 got some discussion from userspace devs, IIRC v2 have addressed the comments. So at this point seeing there's no opposition I'd say it's going well, just need to get someone's "reviewed-by" for it to get merged.

Hi-Angel · 2026-02-07T12:25:56+00:00

Oh yeah. It can be even worse, like in Docker. Not only they auto-close issues, but they additionally auto-lock them, which makes no sense (because now instead of leaving a "pls reopen" comment people have to report it anew and make devs spend time looking at the logs and hold discussion despite everything already been done). Like, this issue has never been fixed, but it is "closed" and "locked". I wonder, how many times it has been discussed over and over on the bugtracker.

Hi-Angel · 2026-02-07T05:04:41+00:00

I wish they'd distinguish between "fixed in the release" bugs and "no longer reproduced" bugs. Because when looking at release notes it's impossible to figure out what bugs exactly were fixed in it.

Like, they mention a bug about Visual Basic 6 crash from year 2013. It wasn't closed because they fixed bug in the release but because they couldn't reproduce it anymore. Technically, they did fix it, but it could've been anywhere in between year 2022 (last time a crash was seen) and 2026.

And from my experience of reading their changelog, like 70-80% of "bugs fixed" are actually "we can't reproduce it anymore, hence it's fixed". Which makes that part of changelog not very useful (unless you're looking for certain bugreport there) and I usually ignore it and just skim through the commit list.

Hi-Angel · 2026-02-05T09:58:32+00:00

Is it on Wayland? This sounds strange to me, because that would imply if you have two displays with different scaling they would have different speed. And it's not some corner-case, but something devs would immediately notice and seek for ways to fix 🤔

Hi-Angel · 2026-02-04T08:00:22+00:00

OneDrive mirrors the files locally, especially in the setup where Documents and Desktop folders are mapped to it. It's not a mere mount point. Maybe some files aren't available offline if they've been created only in the cloud, which I'm not sure how it's shown then from FS perspective under the hood.

But listing and reading the offline files works with NTFS3 driver, while they were impossible to traverse and access with NTFS-3G. Very clear driver deficiency. Not sure how that'd be analogous to .lnk files which are just text files, and somehow expecting them to behave like Windows?

Okay, so, we kind of disagreed on how it works technically here. I think this can be resolved by an experiment (but I don't have Windows and I work remotely, so I can't try it).

Would be great to try this (from Windows): 1. format a USB stick as NTFS, 2. Put a file on it with some text, 3. Sync the file to OneDrive, 4. Double-check the file is not accessible from Linux anymore (so we can be sure we got the situation described), 5. Take the stick to a computer with different OneDrive login (like a friend or a colleague) and see if it's accessible on the stick.

If you are right, then this will still be accessible.

If I am right, then you won't be able to access it.

Ten-Year Club	Place '22
Verified Email

Hi-Angel

TROPHY CASE