Quoting: DebianUser

Quoting: Cybolic

Quoting: DebianUser

Quoting: Cybolic

Quoting: CybolicThis sounds like something that could also be implemented with bspwm, so I'll be sure to keep an eye on what tweaks they're doing.

Here's a quick version for anyone interested. Thanks to mmstick for correcting me on the logic.
bspwm-scheduler.sh [External Link]

Thanks, seems interesting.
I see it uses bspc command, does it require bspwm ? or it will work under mutter with bscp command installed ?

It very much depends on bspwm. If there's another tool that continuously prints out the WID when the focused window changes, it could be adapted, but I don't know of any.

Maybe "xprop -spy -root _NET_ACTIVE_WINDOW" ?

Doesn't have correct knowledge about the PID of the active window. Half of your applications will either have no `_NET_WM_PID` or the `_NET_WM_PID` will be a bogus value like `2`.

View this comment - View article - View full comments

What ananicy does is only a fraction of what system76-scheduler is doing.

Quoting: Cybolic

Quoting: CybolicThis sounds like something that could also be implemented with bspwm, so I'll be sure to keep an eye on what tweaks they're doing.

Here's a quick version for anyone interested. Thanks to mmstick for correcting me on the logic.
bspwm-scheduler.sh [External Link]

Doesn't appear to be applying the background process priority to all background processes, or matching all descendants of a PPID and their descendants, descendants. It'd be easier to simply do

 
dbus-send --system --dest=com.system76.Scheduler \
    /com/system76/Scheduler \
    com.system76.Scheduler.SetForegroundProcess \
    uint32:${PID}

View this comment - View article - View full comments

Quoting: CybolicSeems that they're just giving a -5 nice value to the pid of the focused window and its parent processes, keeping track of those changes and setting them back to 5 when the foreground pid changes. This should be doable with a shell script :)

It's the other way around. The window manager provides the PID of the foreground window, and all of the descendants of that window get prioritized by the foreground priority, which by default is -5 but can be changed in a config. All other non-foreground processes are assigned the background priority of 5.

View this comment - View article - View full comments

Quoting: sprocketAs someone that is happy with Gnome 40 on Fedora 34, I question the wisdom of yet another Gnome fork.

Good for them and I hope their user base will be happy. But i feel this will just cause needless fragmentation.

It's not a fork. We have always had a customized GNOME session that differs from the default GNOME configuration.

Quoting: DorritYeah, what Linux needs is yet another desktop environment.

This is GNOME. It's not another desktop environment. It's a large improvement to our existing GNOME session experience.

View this comment - View article - View full comments

Quoting: LinasLast time I checked they were not making this into a standalone extension, because what they are doing requires more invasive changes than it is possible via the extension API. Don't know the current status though.

This can be installed on any GNOME distribution provided that you have a recent-enough version of GNOME and a TypeScript compiler. The rebuild script in the repository will change and disable a number of GNOME's default shortcuts to make way for Pop Shell's keyboard shortcuts though. That's really the only invasive change. It's all built on GNOME's extension API.

View this comment - View article - View full comments

Quoting: d10sfan

Quoting: mmstickI don't think users should be supporting products that aren't ported natively, regardless of whether they perform okay with some annoying bugs. This just sends the message that it's okay to keep porting more games in this manner, and we will only have less and less native ports. There's a lot that can go wrong with non-native ports throughout the course of time, and judging by their past history, I doubt they'll ever fix their broken games, nor will the developer re-port their games in the future.

If we wanted to play non-native ports then we'd just use Wine with Gallium Nine, without all these silly bugs. Even that dreaded Witcher 2 port runs better in Wine that it does the 'non-native Linux port' from this developer.

In regards to AMD, the open source drivers are perfectly fine, and even now support OpenGL 4.2 in the impending Mesa 11 and LLVM 3.7 update coming to a bleeding-edge distribution near you. The performance matches, if not exceeds, the Catalyst drivers in all games, and as demonstrated earlier, using Wine with Gallium Nine provides a lot of benefits for games being executed in that manner.

Would you prefer that Virtual Programming stopped releasing Linux ports then? And none of their games come to Linux? When have you tried Witcher 2 last? Works great for me here, and many others. This new port works very well. And Virtual Programming has shown they work on their games after the initial porting (look at the github and their betas for examples).

Also, eON is a bit in the middle between native and a "wine"-like wrapper. If the game works well and is well supported, how much does it matter? Personally, the problem becomes when a developer releases a lazy wine wrapper (wrap and done, no support), instead of going native or a wrapper like eON.

These eON ports can also give metrics for the developers and publishers who contract them out. As in, if they do well, they may decide to do an in-house native port next time.

Also, native ports have their own problems as well sometimes. Aspyr released KOTOR2 with a bug that broke the game when using with workshop mods. Shadow of Mordor was released with AMD having major issues. Both are either fixed or being worked on, and I think those porting teams are great, but no port will ever be perfect, native or no.

I tried Witcher 2 on Linux one month ago and it still runs significantly worse than running the Windows copy through Wine with Gallium Nine. Indeed, I would very much prefer that non-native ports are abolished henceforth and never allowed onto Steam. Non-native ports are not the way, nor will they ever be. Fixing a bug in a native port is easy, but resolving a bug in a non-native port? I don't think so. Either do a port correctly the first time or don't do a port at all. No port is better than a bad port.

View this comment - View article - View full comments

I don't think users should be supporting products that aren't ported natively, regardless of whether they perform okay with some annoying bugs. This just sends the message that it's okay to keep porting more games in this manner, and we will only have less and less native ports. There's a lot that can go wrong with non-native ports throughout the course of time, and judging by their past history, I doubt they'll ever fix their broken games, nor will the developer re-port their games in the future.

If we wanted to play non-native ports then we'd just use Wine with Gallium Nine, without all these silly bugs. Even that dreaded Witcher 2 port runs better in Wine that it does the 'non-native Linux port' from this developer.

In regards to AMD, the open source drivers are perfectly fine, and even now support OpenGL 4.2 in the impending Mesa 11 and LLVM 3.7 update coming to a bleeding-edge distribution near you. The performance matches, if not exceeds, the Catalyst drivers in all games, and as demonstrated earlier, using Wine with Gallium Nine provides a lot of benefits for games being executed in that manner.

View this comment - View article - View full comments

In order to gain support for OpenGL 4.1 (and soon 4.2) with RadeonSI, you need to have Mesa built against LLVM 3.7. Oibaf only builds Mesa against LLVM 3.6, sadly. If you were using Arch Linux, it'd be a simple matter of adding the mesa-git repository as that does build Mesa against LLVM 3.7.

View this comment - View article - View full comments