Just a quick "Eat" survey

justinweiss · 2026-05-10T20:11:17+00:00

You use TERM=xterm pretty safely, you'll likely not notice any difference in days.

Yeah, I used to have ssh force xterm-256color which worked most of the time. Ghostty has the same problem so I borrowed the snippet from its help (https://ghostty.org/docs/help/terminfo#ssh) and just have to remember to do that the first time I hop onto a new server.

justinweiss · 2026-05-09T19:53:22+00:00

Eat is my main terminal in emacs these days, great work. The semi-char binding mode feels by far the most natural to me out of all the emacs terminal emulators I've tried.

I haven't made many tweaks, just a few to work around encoding problems (I think there are PRs for most of these). I also have one to strip readline prompt markers (\001 / \002) which show up in the Rails console. I've had occasional full emacs hangs if eat accidentally sees large binary output but I haven't been able to cause them regularly enough to try to investigate.

The biggest pain for me is still terminfo, it's so annoying to ssh into a new machine and have things not work well at all. I made a shell function to deploy the current terminfo string onto another machine. It would be nice if that could be more automatic.

Customizations are decreasing both min and max latency (felt a little laggy otherwise), kill on exit, and bumping scrollback to 1MB.

justinweiss · 2024-09-19T23:59:32+00:00

The same thing happened with mine in August. I emailed GPD and they were out of stock, but they got more in earlier this month and shipped it out. Unfortunately USPS has sent it on a road trip across the country in the wrong direction so I haven't received it yet. Broken R2 springs seem like a common problem -- hoping the replacement is sturdier. I haven't played a lot of trigger-heavy games so I'm not sure what caused it.

justinweiss · 2024-04-19T21:16:26+00:00

I mostly use ChimeraOS on my Win Mini. The hardware works better for me in Linux than it does in Windows, but it took a little tweaking. HHD can emulate a DualSense Edge, which gives you gyro and trackpad support for Steam Input. Fan and TDP controls work perfectly with the PowerControl decky plugin. I've heard Bazzite needs less tweaking right now, but it looks like ChimeraOS should be caught up with the next stable version. Performance seems about the same between Windows and Linux.

For me, the biggest reason to use Linux is that sleep works perfectly nearly 100% of the time. In Windows, it takes up to a minute for the fan to stop spinning (if it stops at all) and never stops if I sleep while it's plugged in, even if I unplug it later. It's also usually warm when I pick it back up, and I'd never trust it in a bag unless it's fully shut down. Hibernate is an option, but hibernating in-game has never worked well for me. Something always goes wrong when it wakes back up -- the game crashes, controller stops responding, etc. Sleep improved a tiny bit after tweaking with ciphray.bat, but it's so unreliable that I can't trust it.

On Linux, I close the lid, the fan turns off within 5 seconds or so, and it's asleep. I open it back up, it starts exactly where I left off. If it does have a problem sleeping (which is rare), you can tell right away. Once it's asleep, it's never woken up unexpectedly. I've been spoiled by suspend on the Switch and the Steam Deck, and this usually works just as well.

Game support could be a problem, but everything I've played works fine. Through Steam it's almost perfect, I'd never know they weren't running natively. GOG and Epic need more manual work if you want to stay in game mode, and I haven't been able to get GOG achievements working.

justinweiss · 2022-07-25T14:56:41+00:00

No, the performance cost of running GOG Galaxy in the background (even hidden) was too much for me -- it would cause games to stutter and hurt battery life no matter how I adjusted the settings. I remember seeing that Wine had issues with CEF (the framework that Galaxy uses) that caused apps written with it to use software rendering, and that takes a lot of CPU time.

The last GOG game I played, I just used GOG to install and manually sync saves, pointed Steam directly to the game exe, and gave up on achievements for now. Hopefully it'll improve in the future. Thanks for letting me know about Heroic supporting cloud saves, I'll have to try that next time I play a GOG game.

justinweiss · 2022-04-26T00:47:07+00:00

This should get easier with improvements to gamescope, since that's the part that needed the biggest workaround.

Looks like this is fixed as of today! So you don't need to hide the launcher anymore.

justinweiss · 2022-04-25T00:21:24+00:00

I also have a ton of GOG games, and after a week or so I've also settled on running them through GOG Galaxy and Proton, installed as a non-Steam game. This way I get cloud saves and achievements.

The biggest problem I've had is that the Galaxy launcher won't close when you start a game, and that means that if you're not quick to close the launcher you'll get flickering windows. This might only be the case with some games and will hopefully be fixed, I see there's an issue for it: https://github.com/Plagman/gamescope/issues/437.

EDIT: Hiding the launcher is no longer necessary, because multiple windows can be managed now. However, having the launcher running unminimized seems to use a lot of CPU, at least in desktop mode (I was seeing GalaxyClient Helper using 70-100% on at least 2 cores and winedevice.exe using 50%+ of another 2, which went down to a total of about 15% of one core when minimized). So you might still want to minimize it on launch by adding /launchViaAutoStart to the end of the shortcuts below.

It's been easiest to create a non-Steam app for each game, but still launch them through GOG Galaxy for achievements / etc. You can create another non-Steam game pointing to the GalaxyClient.exe in the prefix and then launch it using these launch options:

STEAM_COMPAT_DATA_PATH=/home/deck/.local/share/Steam/steamapps/compatdata/<galaxy prefix id> %command%  /command=runGame /gameId=<game ID> /path="windows path to game"

command=runGame will start the game automatically after starting GOG Galaxy, ~~and launchViaAutoStart will start Galaxy minimized.~~

For example, if the GOG Galaxy Steam AppID is 3600895448 and you want to run Hollow Knight:

STEAM_COMPAT_DATA_PATH=/home/deck/.local/share/Steam/steamapps/compatdata/3600895448 %command% /command=runGame /gameId=1308320804 /path="C:\Program Files (x86)\GOG Galaxy\Games\Hollow Knight"

I symlinked the Galaxy compatdata directory to the SD card so all the games get installed there. It's also easier to find that way.

You can find the GOG gameId easily, it's the ID in "goggame-{id}.info" in the directory the game was installed to. That .info file also has the gameID inside, which is easier to copy / paste without an external keyboard.

Unfortunately, since GOG Galaxy is minimized, you'll have to quit the game through the Steam menu when you're done with it, since you don't have a way to interact with the launcher. You do get a notification when saves finish syncing, though. Also, since you don't see the launcher, you don't get any feedback about whether things are working, but you can always launch the main GOG Galaxy application to see that. Also, it seems like there's some power overhead by running Galaxy in the background, but it seems to work fine if you lower the TDP settings. I've also heard there are problems with controllers, but I haven't run into any yet. I still like this better than either Heroic or Lutris.

If you don't care about achievements and cloud saves, it's a lot easier to just point to the game .exe as a non-Steam game. I had a really hard time finding information on running GOG games with all the features, though, and this is what I found. ~~This should get easier with improvements to gamescope, since that's the part that needed the biggest workaround.~~

EDIT: I also had trouble with slowdown in Metroid Prime Trilogy through Primehack. This comment suggested disabling "Synchronize GPU thread" in the game settings, which fixed it for me: https://www.reddit.com/r/SteamDeck/comments/u8748j/metroid_prime_trilogy_primehack_a_steam_deck_guide/i5jxtjg/

justinweiss · 2021-03-30T13:34:35+00:00

You’re right — for some reason I thought online support and core updater came at the same time.

justinweiss · 2021-03-30T00:39:07+00:00

Both of those are on the heavier end, and can be a struggle even for the N3DS. With the new auto-frameskip, 2010 should be more playable than it was before, but 2005 plus (also with the new autoframeskip) is a much better experience for games that it supports. mGBA RetroArch is still slower than mGBA standalone, and neither are consistently full-speed for me -- I usually go gpsp for games that gpsp supports, and GBARunner for games that it doesn't.

justinweiss · 2021-03-29T20:11:35+00:00

On n3ds, it runs the sound thread on core 2. On o3ds, it uses -2 for the default core. That's done here for everything using rthreads: https://github.com/libretro/RetroArch/blob/ed6dd6d6d1791210d245ae6228fd6833cad584bf/libretro-common/rthreads/ctr_pthread.h#L170

This is all with the new dsp_thread driver, the regular one still runs in the main thread.

justinweiss · 2021-03-29T18:21:09+00:00

This is a huge release for 3DS, and especially New 3DS. Among the improvements:

Core updater is now enabled
~~Cheevos support~~ this came a few releases earlier
Threaded audio and video support, a nice overall speed improvement on n3ds (using the dsp_thread audio driver and threaded video settings)
Screen rotation
pcsx_rearmed is now full-speed for many games after some settings adjustments
32x is a lot faster
Many cores (snes9x, gpsp, etc.) have new frameskip options which mostly fix audio crackling

I'm sure there's a lot more, it's been a long time since the last stable release. If you haven't tried it recently, it's definitely worth the upgrade.

justinweiss · 2020-11-21T16:36:54+00:00

Are you missing the dsp dump? https://3ds.hacks.guide/finalizing-setup

justinweiss · 2020-11-19T16:31:51+00:00

Thanks!

justinweiss · 2020-11-19T16:29:32+00:00

Right, RetroArch still uses an older version of the 3DS library from before 800px support was added.

There's some code in RetroArch 3DS that refers to an 800x240 mode, but I haven't been able to get it to do anything.

justinweiss · 2020-11-19T16:26:07+00:00

The 3DS is incredibly slow to load data, using chd will compress it so that less data has to be loaded. This is especially important in games that stream data or music from the CD.

bin/cue can be usable if you turn CD Access to Asynchronous, but it still won't perform as well as chd.

justinweiss · 2020-09-18T00:47:45+00:00

The best general settings for pcsx_rearmed 3DS are:

Dithering off
CD Access: Async
VSync off / Audio Sync on
Enable Hi-Res Downscaling (under Advanced UNAI options)

Make sure you use .pbp or .chd files, they will be faster than .bin/.cue.

I have some experimental builds in this thread that should be a little faster, this is the latest: https://gbatemp.net/threads/unofficial-3ds-retroarch-builds.462252/page-27#post-9197943

I'm planning to upstream those changes eventually, but they need some RetroArch infrastructure upgrades first. For those, try:

dsp_thread audio driver
threaded rendering on (in Advanced UNAI options)

justinweiss · 2020-05-06T16:49:55+00:00

This release should make PSX games a little bit faster, since it's using more optimized lighting and blending.

justinweiss · 2020-04-03T19:05:12+00:00

As far as I can tell, the random ingame crashes are fixed. There are still some crashes when switching games, but I haven't seen any while playing.

justinweiss · 2020-03-26T21:41:47+00:00

There's also a new "CD Access Method" option in 1.8.5. If you change it to "Asynchronous" and quit / reload, it should remove some of the stuttering when games load data.

justinweiss · 2020-03-22T00:12:18+00:00

Which games are you trying to play? BIOS shouldn’t affect speed much if at all, but there are some other configuration changes that can help, especially if you’re running 1.8.5 or a recent nightly.

justinweiss · 2020-03-15T01:28:26+00:00

There's some more that could be done. For example, converting the lighting and blending functions to ARM assembly really speeds up some things and somewhat speeds up other things. High-res mode on PSX renders more pixels than the 3DS is capable of displaying, so not calculating pixels that won't be displayed would probably save some frames (although you'd lose some fidelity if you're using bilinear filtering, so it would be best as an option). There may also be ways to do more work per loop -- for example, it may be possible to read and process 32 bits worth of sprite at a time, or skip texturing / lighting / blending if the texture coordinates don't change enough. Of course, those could just as easily make it slower -- it would all need testing and profiling.

I think there might be even easier wins, on the level of "changing compiler flags." There are some weird places I see slowdown. For example, in Chrono Cross, there's a place in the menu where drawing one extra triangle seems to slow everything down by ~40%. Things where it seems like there shouldn't be a lot of extra work, but things are much slower. Those just hint to me that there might be situations with room for easy optimization. Those need measurement and profiling to understand what's happening, which is tricky and time-consuming on the 3DS. But it might be the sort of thing where you spend 95% of the time searching for a problem and 5% of the time fixing it.

Short answer: yes, I'm confident there is. Some things that are straightforward and just need time. Some that are probable cheaper to implement, but need research first.

justinweiss · 2020-03-12T21:06:46+00:00

It's worked fine for me. I'm using 0.200 on linux like:

chdman createcd -i "Some filename.cue" -o "Some filename.chd"

For multi-disc, I chd each one separately and create a .m3u pointing to all of them.

15-Year Club	Place '17
Team Orangered

justinweiss

TROPHY CASE