deleted by creator

I like my 8bitdo controller but I have an older model so can’t speak for the more recent ones.

Mesa 25.0.0 Release Notes / 2025-02-19

[ 5067.696] (II) Applying OutputClass “AMDgpu” to /dev/dri/card1

Make sure that you actually have permission to that /dev/dri/card1 device. This may be arranged by udev or “video” group membership.

Regarding AMD vs Nvidia, unless you need CUDA you probably made the right choice. This sounds like a config issue and you’d probably be dealing with the same thing with Nvidia too.

Thanks, I see that sdl2-compat-2.30.51-1 has landed in Arch since.

To be fair the “no USB support” window was quite short. USB started becoming available to consumers around 1998-1999 and there was some level of USB support in the Linux kernel within a few months. I remember using an early USB stack written by someone else that Linus didn’t like so he rewrote it from scratch. Even the new Linus stack was in place by 1999. We got USB-2 and 3 support pretty quickly too.

I’d start by comparing the following in the working vs non-working cases:

1. Is there a corresponding /dev/input/js* device?
2. If it’s there in both cases, any difference in permissions? Check both regular Unix perms using ls -l or stat and ACLs using getfacl

deleted by creator

1. The basics: high quality terminal emulation with utf-8 and directcolor support
2. Customization is by simple git friendly text config. Build time config (ala st) is acceptable if done in a reasonable way.
3. A way to pipe panes into external commands to allow for customized url and other other data extraction. Built-in regexs are not always enough and doing it on the tmux side is not always ideal.
4. Control over key bindings and mouse behavior
5. Small, very fast, instantaneous startup
6. Very predictable behavior, no surprises
7. Minimal dependencies (including build time) are a plus. Definitely no 100MB+ electron beasts.
8. Support X11 since I am sticking with that for now
9. A codebase I can understand in case I need to change it. Simple and fast build. For core tools like terminal emulators I must be able to build or modify them without much trouble.
10. Not too much extra junk. I don’t use menus, tabs, scrollbars etc so I don’t want the terminal to be huge or slow to support every feature others might want. I will put up with some extras if they can be completely disabled and don’t significantly affect performance or startup time or code complexity.
11. Absolutely no network service integration, no matter how well intended. The only acceptable network activity is talking to the X11 socket.
12. Longevity. I like to use my tools for years and years. I am interested in new tech of course but I don’t hop from one hype train to the next.

I know this is not everyone’s cup of tea but you asked what I want. And nowadays it’s at least as much about do not wants as wants.

I briefly tried ghostty when it was going around earlier. Slow startup time (~250ms if I remember right), the gtk-4 dependency and some weird defaults like the client side decoration (which I gather can be turned off in config) made me pass on it for now but might take another look in a few months. It didn’t seem particularly revolutionary to me either but there are plenty of much worse options out there too.

Ugh, that’s a pretty insane default. Thanks for the heads-up.

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.

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

Yep, original is Java and uses libGDX. Slay the Spire is mentioned in the showcase.

Roguelikes: DCSS, Shattered Pixel Dungeon, Nethack

Costs a lot less than therapy too.

For spot checks I just run sensors or watch sensors.
sar -m TEMP | grep amdgpu when I want to see history (needs the sysstat cronjob configured to collect sensors data).

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.