I had similar worries about the AMD driver stability before I switched from NV about 5 years ago. But my experience has been great even back then and things have only improved since.

One data point to consider is that Valve is shipping the Steam Deck with an AMD AMU and stability and compatibility is paramount for that use case.

Any naming convention is fine as long as it’s meaningful to you. But it’s a good idea to keep your own repos separate from the random ones you clone from the internet.

What I see is an inexperienced developer who instead of systematically debugging the issue keeps trying random stuff hoping that it will somehow work.

Thanks. I tried to make sense of it and experimented a bit with making the same ioctl’s mentioned but couldn’t get it to work. I either didn’t get it right or it’s something else.

Maybe I will take another look later but for now my workaround is to just fire up Baba Is You which idles at a low cpu use and then run evfwd with the grab option so that Baba no longer gets the input.

Yes, that works too with one fairly big caveat: for some reason the Steam Deck’s controller is not producing evdev events until a game is actually running on the deck. So evfwd is not receiving events while the Steam UI is active. I haven’t been able to figure out yet why this is the case.

If you want to try it you can start a random game on the deck and then fire up evfwd on the controller device and using the -g (grab) flag to avoid passing events to the running game.

Edit: while we are talking about the Steam Deck: when ssh-ing to the deck it can be helpful to turn off wifi power management to avoid lag: iw wlan0 set power_save off

It’s been mostly Isaac as usual but I picked up Shotgun King: The Final Checkmate yesterday and I like it a lot. It’s a fast-playing roguelite with a neat idea that’s implemented well. The game mechanics remind me of Hoplite on mobile.

The game is currently on sale and has a free demo. It has good controller input and low resource use, a great fit for the Deck.

I picked this up about 2 months ago. Took me about 100 hours before I could put it down.

Backpack Battles. It’s an inventory management based auto-battler. Chill game and I like spatial puzzle a lot.
The game uses the Godot engine and it runs great on the deck. The UI is very smooth and thoughtfully designed.
A neat thing about the battle system is that it’s fully asynchronous. No matchmaking delay and it even works offline. I believe it works by preloading a number of opponent-builds at the beginning of the run.

Too much if I am honest about it. Currently obsessed with DRG: Survivor and I’ve put in an embarrassing number of hours in the last couple weeks.

It depends. If there is any money on the line or don’t want to burn bridges then I’d do the smart thing, whatever that is. Otherwise I’d just skip it.

Picked up Deep Rock Galactic: Survivor a few days ago and I’m now 20 hours in, really enjoying it. It’s a very thematic translation of the original DRG into a survivor game. The terrain and mining are a great addition to the survivor formula, it’s not only for resource collection but it also gives a new twist to the positioning puzzle. The game seems very well suited for more content so I hope that it will keep coming.

If you have an email workflow that you like then something like rss2email might be an option. You simply feed your incoming rss into your email. You’ll want to auto-tag (or otherwise organize) these emails to keep them separate from regular emails. Then you use your usual email tools to organize them further.

I’ve been using such a setup for the past 15 years.

Great idea!

I’ll probably stick with Firefox but I will set this up using the Vimium browser extension which has a very similar hint based link selection.

Currently on sale for $17.99, new low.

Roguelikes: DCSS, Shattered Pixel Dungeon, Nethack

Costs a lot less than therapy too.

Autotype is already solved - ydotool, wtype and dotool exists (and possibly others as well).

These tools work by creating a virtual keyboard so they don’t let you send input to a specific window. The input goes to whatever happens to be focused at the moment. This makes them less reliable than the X11 equivalents and unusable for tasks where you need to guarantee that the right window gets the input.

Those of us who use the autocd feature of shells “execute” directories all the time. For example I’d type just /usr/bin RET if I wanted to cd to /usr/bin.

not having kludges 42 levels deep

There are already almost a hundred extension protocols and you need dozens of them to implement just barebones desktop functionality. If you look under the surface the Wayland ecosystem is arguably already more complex than X11 ever was and it’s only going to get worse.

There is a fairly compact Thinkpad USB keyboard which would be much easier to connect if you can make it fit somehow. It has the trackpoint but no trackpad.