gnusenpai

I second this; it would remove the requirement for applications to have sufficiently performant resizing (as very few do and look good). Resizing more than one window at a time...

Good suggestion, I'll add it whenever I get around to redoing the theming.

This is definitely out of the scope of this project, but what is the use case?

@Loacoon1 Thanks for writing the issue for this. As for Star Citizen testing: the `sc-test` branch allows the game to run as normal, where 86148ec wouldn't. @doesthisusername's one-liner comment also...

I have been maintaining a DXVK build with the workaround on my [fork](https://github.com/gnusenpai/dxvk) that has been working for the Star Citizen LUG for some time now, if that might be...

If you are (or anyone reading this is) willing to compile your own MangoHud, here is a one-liner patch that allows non-element-affecting parameters to be used in conjunction with `MANGOHUD_CONFIG=read_cfg`...

Building ollama with https://github.com/ggerganov/llama.cpp/pull/4538 and (optionally, if you do CPU+GPU inference) https://github.com/ggerganov/llama.cpp/pull/4553 has made prompt eval significantly faster for me. (~60t/s vs. ~10t/s)

I've also been having this issue for some time now, it's kinda rare (once a week or less). No idea why it happens...

@devraza You cannot change the layout (master/dwindle) based on workspace *or* monitor (what this issue is about). The example given above just changes the orientation of the master layout.

Which kernel driver is in use here: kernel-open or proprietary?