I installed FIM to look at images from the TTY on a Debian 12 laptop. This laptop has XFCE running in one virtual terminal, with a bare TTY in another virtual terminal. When I run FIM in the TTY, it gives me no error messages, but hangs indefinitely. When I press CTRL-C to stop it, my image briefly flashes on the screen (for only one frame, I think), and then it goes back to the terminal.

Running FIM in a terminal emulator in XFCE, obviously I can't output to the framebuffer, but the default display method of sdl works fine, as does the aa method. The "dumb" method hangs, never displaying anything.

Here are links to stacktraces:
https://0x0.st/XHz5.txt (FIM in XFCE in sdl mode, works)
https://0x0.st/XHzn.txt (FIM in XFCE in dumb mode, broken)
https://0x0.st/XHzd.txt (FIM on the TTY in fb mode, broken)

Note that the "--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---" line in the TTY/fb stacktrace is when I pressed CTRL-C.

Does anyone know what's happening here or how to fix it?

Thank you!

Usually my standard response to this is to build it yourself and see if that works. I had 0.6.0-rc0, just updated to 0.7.0 and they both work w/framebuffer. Even if the desktop is running, you should be able to switch to a (plain) TTY and view images.

Just tried (with 0.7.0) and I'm running into basically the same problem again. (I also gave myself rw permissions to /dev/fb0 through a "framebuffer" group, which they suggest.) This time, the image doesn't display for a frame after an interrupt -- just a flash of black. However, if I switch to another virtual terminal, then switch back, it works properly: i can see the image and interact with FIM. Also, if I run it via strace *with output to stderr*, it spins up a simple user interface, and occasionally, with small enough files, it will display them properly. This makes me think this is a timing problem, where running strace to terminal stderr slows it down enough that something happens in a different order.

The relevant syscall, which isn't happening until I switch back and forth through virtual terminals, is ioctl(3, FBIOPAN_DISPLAY, 0x561849335b20). It runs and returns 0 after switching; doesn't run at all until you switch VTs. (3 is a fd for /dev/fb0.)

Any idea why this happens? Race condition? Am I missing some key framebuffer library dependency or something?