Quoting: torstenchrI've tried reaching out to derrod (developer) on github but it seems like this issue is not taken serious.... :(

Seems to be this issue [External Link], which is part of this issue [External Link], and currently have an unreleased hotfix ready [External Link].

View this comment - View article - View full comments

With support back it allows you to use AMD FSR 1 on top of any Vulkan game (or DXVK / VKD3D-Proton) running through GE-Proton by using WINE_FULLSCREEN_FSR=1 %command% as a Steam launch option.

https://discord.com/channels/110175050006577152/522638111042437132/1131869082162045020 [External Link]

According to GE, you no longer need to do so. Here is everything on how it works on the latest Proton-GE version:

if you want to change the mode and/or set custom mode yes, but you do not need WINE_FULLSCREEN_FSR=1, it's on by default. It does not get used if the game res is set to the same as the monitor res and if the game is not in full screen

[...]

by default these settings are enabled:
WINE_FULLSCREEN_FSR=1 WINE_FULLSCREEN_FSR_MODE=balanced

In order for them to work correctly, you must set the in-game resolution to smaller than your monitor, and set the game to fullscreen mode. Otherwise FSR is not applied

[...]

if you're using gamescope you do not need to touch GE-Proton FSR settings,use gamescope's settings instead, it has fsr built in. and no, multimonitor is not an issue

Note that Ph42oN later corrects the modes that "it should just add all of the resolutions, not just balanced if not using WINE_FULLSCREEN_FSR_MODE".

View this comment - View article - View full comments

Still wish for ProtonDB option. It'd be one less extension on my browser, and I could use the Steam client's Store browser itself instead of my browser without worrying about missing the compatibility ratings.

View this comment - View article - View full comments

Quoting: akselmoEdit: I think they don't have enough players in their lootbox circus, so this is their last hurrah trying to get players?

They don't have lootbox anymore, just a stupid battle pass and per-item purchases, but they are being desperate after a bunch of people declared the game dead following the cancellation of the PvE campaign.

View this comment - View article - View full comments

I personally want this to be turned on, opt-out by default. I saw the proposed design and it seems fine to me. And the potential benefit to me is that Fedora and Gnome may stop being so out of touch that so many people uses the thing they refuse to ship by default for no reason and see any other user experience issues on the platform.

View this comment - View article - View full comments

Quoting: CanadianBlueBeerIf I set monitor scaling to 125%, then steam seems to be the right size.
Everything ELSE is too large though.

sigh (and the scaling button in steam does nothing)

You can probably fool it for Steam by appending your desired scaling through env vars. AFAIK the env var related to scaling for GTK are either `GDK_SCALE` or `GDK_DPI_SCALE`, and for Qt I think it should be `QT_AUTO_SCREEN_SCALE_FACTOR` (checked with `env | grep -i scale`).

View this comment - View article - View full comments

Quoting: alexleducI have set the environment variable with an export so that it's permanent, but Steam doesn't seem to use it. I does work when ran from the command line with:
steam -forcedesktopscaling 1.5
or
STEAM_FORCE_DESKTOPUI_SCALING=1.5 steam

Launching it from a Plasma shortcut or just having steam start on boot ignores the environment variable (at least on X11)

`export` only sets the variable for the current terminal session, to make it "permanent" you need to put it somewhere else like `~/.profile` or `~/.bashrc` (there's a hierarchy to it, but I can't remember ever since I made home-manager's nix sort it out for me).

As for setting env vars in shortcuts, you're best off using kate/kwrite to edit the .desktop file manually, and prepend `env VAR=value` in the `Exec=` field.

View this comment - View article - View full comments

Well, to all the people who asked "If snaps is a universal package manager, when can I use it to install my kernel?" here you go.

For me, it's an interesting project. Snaps, while having certain issues with their GUI portion, for the most part seems to work pretty well on the back-end and non-GUI stuff. But it's just not for me, as I'm already too invested in Flatpak and Nix to deal with a Snaps-exclusive system. I guess I could invest further into Conty, but I like Nix as a way to manage my config and Flatpak for its sandboxing with certain apps.

Besides, I really like the cloud-native approach of uBlue, and while I considered trying out blendOS v3, in the end I'm not interested in doing package installation to host natively anymore and would rather use GitHub to test, build, and pull an image from (gotta love being able to charge Microsoft to build me my Linux system lol). So it's uBlue and Vanilla OS 2.0 only for me.

Quoting: Mountain ManI guess I don't understand how an immutable distro is significantly different in terms of security and stability from the current way of doing it with a locked root account. Aren't they basically different paths to the same end?

After dealing with Arch (glibc and grub update anyone?) and managing Ubuntu PPAs for the past few years, I just don't have the patience to deal with system updates and installing packages anymore. I want my system update to always succeed and I don't need to monitor it.

This is why I like uBlue's approach. System updates are done by GitHub, who compiles the image with all the packages I need (including the printer packages I specified), and I always get the latest successful builds. If an issue occurred, then I can see the log, and it wouldn't get shipped to me. Worst case, I could just rollback to a previous update and go on with my day.

This is how I want my system to be managed, and this works well for me.

View this comment - View article - View full comments

Quoting: adolsonTime will tell. It's still early days, but so far, we're seeing the opposite effect due to Proton. Which, by the way, was the worry back in the Loki/LGP days (when I switched to Linux) with Wine/WineX and later on, Cedega.

For native games, I think the problem is that targeting Linux is such a moving target, that unless the engine is purpose-built for it, devs won't pursue it. Indie games has been pretty good in doing it, but then you got issues like the recent glibc issue, which really doesn't help.

OTOH, people does target Steam Deck more now, which ensures some form of compatibility with Linux devices. With Steam's Linux Runtime Container plus Proton archives, that would actually be a sustainable target with decent long-term compatibility as well.

I heard that GOG Linux games is just outright unmaintained, so if you ask me, the current state is MAJOR improvement even if it's not the ideal everyone wants.

Not knowingly, in most cases, which was my point.

We're past the point in time where people shops for operating system. What matters is that some form of Linux is shipped, by default, on a device that customer buys and devs are starting to adopt more as an additional target.

Again, this is all pretty theoretical at this point, and even with Steam Deck, the numbers are abysmal - as they have always been. I'm still not seeing anything to celebrate at this point in time.

Personally, I'm celebrating the upward momentum. It's there. It's not the greatest yet, but momentum is important in making Linux stays in public consciousness and more importantly, manufacturer's.

View this comment - View article - View full comments

Quoting: EikeWhy? The reason for Flatpak that I'm aware of is getting newer software, but Steam is updating itself...

Personally, I want to see more focus on Steam Flatpak. It's just more convenient to have a way of installing apps that works across distribution families. Plus, Flatpak is oriented towards GUI apps, and as it improves, it would have less issue with communicating between apps compared to Nix with its wrapping, Distrobox with podman/docker limitations, or Conty/AppImage/runimage with their specific image-based limitations.

Flatpak-Sync is also coming soon, so that'd make syncing between devices even easier compared to the current jank git-based solution I have.

It's not about Steam specifically -- it's about the ecosystem, and Flatpak's ecosystem is getting really good for my preferred usage.

View this comment - View article - View full comments