

I don’t think that’s the good idea even if possible to do with env variable. This should just work correctly, you either miss something in your system or hit some nasty bug of your distro/build or it’s general KDE bug
I don’t think that’s the good idea even if possible to do with env variable. This should just work correctly, you either miss something in your system or hit some nasty bug of your distro/build or it’s general KDE bug
Do you mean PROTON_USE_WINED3D=1 ? If so, you don’t have Vulkan compatible hardware (GPU from like before 2012) or missing drivers. With this flag you use OpenGL rendered instead, that is inferior in every way. If you try it on modern hardware with the right driver in place you’ll get much worse performance, if it even works. This flag shouldn’t be promoted generally.
If you run ancient GPU and want to always fallback to OpenGL, you can put the line
PROTON_USE_WINED3D=1
in /etc/environment
and reboot. No need to set that in properties for every individual game.
I’m pretty sure I used SyncThing from Flatpak at one point and it run great
Naaah, bootable USB stick is enough xD
Thank you very much Tim Apple
You don’t need to. Modem browsers will suspend unused tabs, cache them on drive and free up the memory, while quickly restoring as soon user activate them. On at least moderately fast systems this happens so quickly it’s hardly noticeable.
What you’re referring to as Linux is actually Uutils/Linux…
It literally hasn’t changed even a tiny bit since I first saw it in 2006 :)
I currently use Strawberry - a well maintained fork of the old Amarok player before they redone the UI for KDE 4. It does what I care the most:
I have no idea how people keep recommending that distro to beginners and regular end users only based on what the experience is like right after installing it.
It was such a pain daily driving it for couple of months even for experienced user. updates breaking stuff every now and then, packages reverting versions oddly, causing conflicts in plasma packages, when using SteamDeck mode it would auto-install updates on boot without asking and bootlooping for no reason until I disconnect it from the network, plymouth theme changing randomly. Usually to troubleshoot I had to go to their Discord to see what broke this time. I mean, fine, but this is an unstable tinkerer purely community-driven distro, not meant for those who just want easy time dealing with their PCs. Besides, none of that shit happens on just regular plain Arch btw, once setup properly it updates just fine.
EDIT: maybe it’s any better in Nobara 41?
I mean, it is dead simple after all
Plot twist: he grabs you out of the bush and kiss
Also Hyprland… Yes, that’s the key - the desktop, not the distribution, though the „stable” distros don’t yet ship stuff new enough for this.
Yes, because back when I was learning almost 20 years ago I was able to google terms and read stuff for myself and it was also requirement for posting on forums, yet I was still getting a lot of help from the community. Times has changed it seems, so did the culture. Should I always assume ignorance and lack of interest? And now before I saw your comment I responded more comprehensively anyway, because why not, I’m not mad or anything. Should I take more time to write the response the first time around? Uh maybe idk
Desktop environments or window managers that support Wayland (one of the two displaying systems for Linux, newer one with aim to replace the obsolete one) and already implemented color management protocol in their compositors (programs that compose the image that is being displayed).
In essence, everything that has recent version of Plasma 6 or current version of Hyperland is able to do HDR. Soon there will be new version of GNOME that does that too.
Sooo… not Linux Mint, not Debian stable, not Ubuntu LTS.
Every single one that ships Wayland compositor that supports it. I’d say „finished” is still a bit of a stretch though, since HDR support in apps is still quite limited and the only way to play Windows games with HDR is via Gamescope.
If you come with expectations that you’ll just be fully catered no matter what your setup is and expect things to just work without ever trying to understand problems, you sure can be disappointed. Believe or not, most of the time those issues are out of control for Linux or the distros, as your hardware vendor made it to work on Windows and Windows only. Community is here to help you, but with your attitude it gets difficult no matter how much others try to help.
Pretty much because for some reason it’s broken mess in native games with SDL, and works nicely when using Proton, I noticed that too.
Hi there, having two dualsense and one ps4 controller, using them for ages on Linux and they mostly run great, but your issues doesn’t sound completely new either.
It’s very important on how you installed Steam and whether it’s native package or Flatpak. For Flatpak you might need special udev rules to allow the controller inside sandbox, usually can be installed using steam-devices package.
As others said, enable Playstation Controller support in Steam’s controller settings page.
Check if Steam overlay is functioning. In-game, press Shift+Tab and you should see the overlay and then you should be able to get to controller settings. Try out both with Steam Input enabled and disabled - by default I guess it depends on the game, but mostly enabling it will make it work for games that have issues picking up ds natively.
Test your controllers using something like jstest-gtk. Perhaps there is something else connected that acts as player 1 controller.
It should also be enabled by default for many games that does in fact have Linux native build.