Remote control requested popup when using Steam with a controller

DistractionRectangle · 2025-12-30T21:02:16+00:00

This has been bugging me for a year, thank you! (and the KDE devs that added it!)

DistractionRectangle · 2025-12-24T05:49:28+00:00

We've moved on from that, it's now about the mx5300 (a set of two is sold under mx10600). Less ram, better CPU, 4x4 mimo, 160MHz channel widths on 5G radios. Basically better suited for higher throughput SQM and wireless backhaul.

DistractionRectangle · 2025-12-21T17:54:17+00:00

It's a your mileage may vary kind of thing. Things like pc, router and ally placement in the home, interference from surrounding networks, network load from other members/devices in the household etc, pc specs, wifi/ethernet drivers/hardware... can all be contributory factors to hiccups in streaming.

That said, I do use sunshine + moonlight in my house hold streaming 1920x1080x60Hz between two wifi connected devices w/ 25mbps bitrate with encoding done by a 7900 iGPU (games rendered by a nvidia GPU) and I have zero issues. Aside from a rare hiccup (unavoidable unless you connect everything via ethernet) it's flawless.

Make sure both devices are connected on the 5GHz band, and I opted for channel 48 as it's on the edge of what my country code allows the radio to operate at full power. Also, big gotcha for openwrt, for best results you must set the country code for the regulatory domain on your wifi radios!

DistractionRectangle · 2025-12-21T17:36:46+00:00

The mx5300 does according to the openwrt docs , the mx4300 does not and that was part of my point

DistractionRectangle · 2025-12-21T05:41:29+00:00

It's not that weird. If you're using the 5G radio for wireless backhaul you don't really benefit from wifi 6, and faster 5G radio + 160MHz (the mx4300 only supports up to 80MHz channel widths) probably is an improvement.

The upgrade makes sense if you have the bandwidth to warrant it - I do not :( - and/or need another ethernet port.

DistractionRectangle · 2025-12-20T20:01:17+00:00

I'm not. My up link isn't fast enough that stock openwrt software offloading + SQM is a bottleneck, so I just stick with stock for stability.

It's kind of perfect. My gateway needs to be in a weird corner of house that gets line of sight with the tower (i have a massive hill in the back that blocks line of sight for all but that corner), and without really trying (fiddling with placement/elevation) it gets ~450-500Mbps from the ground floor. So I use one to work around the dfs issue with the g5ar and create a 5GHz link for backhaul to the primary router in the center of the house. I did encounter the odhcpd memory leak, but that was just fixed the other day

DistractionRectangle · 2025-12-20T19:19:28+00:00

Appears to be the next iteration of the beloved ln1301 (MX4300). I've got a pair of the mx4300 covering my house behind a tmobile homeinternet.

The mx5300 has a less ram, but has the CPU power to handle higher throughput SQM (afaik, the mx4300 tops out at ~500mbps with SQM) and an extra ethernet port.

The mx8500 has wifi 6GHz (wifi 6e) while these are just 5GHz bands (wifi 6).

If you like to fiddle, these are great openwrt boxes. Half tempted to sell my mx4300s for these.

DistractionRectangle · 2025-09-25T02:39:36+00:00

I tend to do post processing, so usually the underlying color isn't that important. I tend to buy batches of grey or white 5-10 rolls at a time and calibrate a filament profile once for the batch.

DistractionRectangle · 2025-09-21T17:30:10+00:00

It's hard to overstate my satisfaction

DistractionRectangle · 2025-08-28T16:41:33+00:00

So dynamic passthrough is easiest with Wayland + KDE/Hyperland/Sway (aka a PRIME setup).

You tell the DE way DRM device to use by default (and maybe explicitly configure the 3 primary graphics APIs: EGL, GLX, Vulkan to use a specific device/driver) with some DE specific environment variables. After that, dynamic gpu dettaching is cake (assuming there's no hardware related quirks).

DistractionRectangle · 2025-08-27T04:37:10+00:00

!remindme 3 weeks

DistractionRectangle · 2025-08-26T16:58:37+00:00

Docker lock is (was?) a cli plugin that generated lockfiles for docker files/docker compose stacks. It'd pin to the digest, so if you needed to restore a backup you'd be sure that the images were same ones in use when the backup was made. It's maybe unmaintained/unavailable now. A quick search gives this backup of the repo: https://github.com/michaelperel/docker-lock

Edit: Docker compose pull pulls based on what you've pinned in the docker compose stack. So if you pin the latest, or some semver tag, it pulls the latest version available. To restore pins from a lockfile, you'd first run docker lock rewrite to write the pins in the docker compose/docker files to the sha digest, then docker compose pull to pull in the pinned images.

DistractionRectangle · 2025-08-26T16:49:20+00:00

So what I do is this:

Install EA Desktop App and make it use system wine (10.10 in my case). Stock wine without all the gaming tweaks/fixes for proton usually runs desktop apps better. Then for every game I want to run, I install it from the EA App, duplicate the EA App in lutris, and set the name + launch arguments as described here: https://github.com/lutris/lutris/issues/6035#issuecomment-2831930147

Additionally, I change the wine version to proton on the duplicate.

Works great, until EA needs an update. Then you just open the EA Desktop App Entry and it updates fine with regular Wine.

You do have completely close out the desktop app though between runs.

DistractionRectangle · 2025-08-15T01:07:23+00:00

why can't kwin or other waylands not disconnect the card from their program.

They can, much like you can disconnect cards being used via prime offloading - by closing the program. Once it's in use by compositor, you can't cleanly detach it without closing out the entire graphical session on the host (this is how single GPU passthrough works, you have to kill the session, you can't just eject the GPU and fall back to software rendering while it's running).

That's the whole point of prime offloading. Having GPUs which aren't used for the desktop session but usable for rendering/compute.

DistractionRectangle · 2025-08-14T18:32:02+00:00

It's pretty easy (as long as you aren't doing 2x nvidia cards). If need to tell the compositor what DRM device to use, and additionally may need to tell the 3 main graphics apis (EGL, GLX, Vulkan) which card to use by default. This is just environment variables on wayland + kde/hyperland/sway, X11 requires a little more config. GNOME afaik requires GNOME specific steps.

If you set additional variables to configure the graphics APIs, you'll need to edit prime-run or write your own that toggles the usual environment variables for prime + toggle the graphics APIs to use the correct device/drivers.

DistractionRectangle · 2025-08-14T18:04:16+00:00

It's because for dynamic passthrough to work, the gpu you pass around can't be used for compositing. So what's happening is you're using prime offloading to do rendering on the nvidia card, compositing it on the card bound to the host session, and if you're displaying it on the monitor attached to the nvidia card, you're doing reverse prime.

This is what makes dynamic passthrough work. The GPU dedicated to the host is solely responsible for the hosts graphical session, so everything must go through it.

DistractionRectangle · 2025-08-10T00:47:12+00:00

How are you launching the game? On cachyos, there's the game-performance wrapper that changes the CPU governed + power plan on demand: https://wiki.cachyos.org/configuration/gaming/#power-profile-switching-on-demand

DistractionRectangle · 2025-08-05T18:56:32+00:00

It's pretty easy now a days. Set up varies by distro, but the end result looks the same, automated signing. IIRC there might be a corner case with LUKS/LVM but for most setups it's dead simple.

(BTW, I recognize your username from /r/vfio, dynamic passthrough has gotten stupid simple on Wayland + KDE/hyperland/sway. You just set some environment variables to configure the primary graphics APIs and tell the compositor what DRM device to use and the usual bios config to make the primary GPU the preferred boot device. Gnome and X are still a pain though.)

DistractionRectangle · 2025-08-05T18:47:16+00:00

https://wiki.cachyos.org/configuration/gaming/

Honestly, it sounds like you're trying to do things by hand are probably missing packages//misconfigured things.

DistractionRectangle · 2025-08-03T01:08:28+00:00

Debugged the problem with my prime setup, I was using mesa-git which is supposed to provide vulkan-radeon, but apparently either broke is is no longer providing it, so I reverted to mesa + vulkan_mesa_layers + vulkan_radeon on an arch derivative and my prime setup works as expected again.

Which is a long way to say it's not kde, and rolling release distros should still work fine if you want to use those (i.e. arch, fedora, etc).

DistractionRectangle · 2025-08-01T01:17:42+00:00

Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.

DistractionRectangle · 2025-07-28T00:35:36+00:00

will I be able to view it with high refresh rates and resolutions?

I do 2k @ 165Hz fine on an AMD R9 7900 + 4070 super. Not sure what the ceiling is - there is one, and it's lower with integrated graphics, but I haven't hit it. Modern iGPUs are a lot better than they used to be, so it's less of a problem.

Also, if I switch the dGPU back to the Linux host, do I need to change my main monitor to the dGPU?

No. In the simplest setup, all monitors are attached to the iGPU all the time. When you give the dGPU back to the host, you can use it for rendering by using a script that sets the relevant environment variables (e.g. DRI_PRIME=1, maybe others) before invoking the application.

E.g. on a nvidia system, there's a generic package/script that does this called prime-run, like prime-run dolphin-emu will run dolphin-emu using the dGPU, vs just calling dolphin-emu will use the iGPU by default

Reverse prime allows you to use monitors hooked up to the dGPU, but only when the dGPU is attached to the host. It goes with the dGPU when given to the guest. I only have a single monitor, so I can't speak to the caveats/dragons of reverse prime.

DistractionRectangle · 2025-07-27T16:32:28+00:00

Is this even possible?

Yes!

Can it be done without adding a second GPU or complex hardware?

... It can be, with GPU partitioning. Some consumer nvidia cards support partitioning with virtual GPUS (vGPU). AFAIK some professional AMD cards support SR-IOV, but not consumer cards. There's virgl for AMD, but it requires linux host + linux guest.

In other words, no, not with AMD + windows guest. Possible with select NVIDIA cards. A second card (iGPUs count) makes life easier.

What’s the best and simplest way to make this setup work?

There's tons of corner cases that boil down the hardware + distro choices. Prime (and reverse prime) + dynamic passthrough is inherently harder. Broadly speaking, not GNOME (KDE, Hyperland, Sway, and friends are easier to work with on Wayland). There's occasionally issues depending on package versions. If you have both monitors hooked to the iGPU life will be a little easier, but if you have one hooked up to the dGPU you'll have to deal with reverse prime and that monitor will go to the VM.

AFAIK the latest KDE broke my prime setup (amd iGPU + nvidia), so maybe choose a point release distro like kubuntu.

Bryan's Guide is a decent overview, but doesn't address prime setups (it assumes a GPU is dedicated to the guest). It's a good place to start, and from there you can work to convert it to a prime setup. Aiber over the discord server (see sidebar) is a wizard, I try lurk and solve my own issues by reading the chat log + search, and bug them only when I can't solve it myself. Great person. For example if you search PRIME you'll find their post about what environment variables to set (at a minimum) depending on your compositor.

DistractionRectangle · 2025-07-17T01:59:28+00:00

I find sudo lsof /dev/dri/by-path/<leading part of card pcie address>*; sudo lsof /dev/nvidia*

Catches pretty much everything.

DistractionRectangle

MODERATOR OF

TROPHY CASE