yaft locks console
mrsteve0924 opened this issue · comments
installed yaft on arch. but each time i call yaft my system locks up and i have to reboot.
i've added my user to the video group, added exported FRAMEBUFFER=/dev/fb0 to my .bashrc file and installed FBV.
anything else i should be doing to get this working?
using kernel 5.0.2-arch1-1 and running arch in virtual machine
appreciate any advice. thanks
I'll check whether yaft works correctly in my environments, because I'm not using latest arch now.
Please send error messages in your environments if you can.
- set
VERBOSE=truein conf.h - re-compile yaft
- run as
$ yaft > dump 2> err - paste error file here
One more question:
Can you use other framebuffer based software without any problem? (fbv, fbterm etc...)
i found the error file. pasted here: http://dpaste.com/38FGVEF
I tested yaft on archlinux (latest image and packages) and yaft works correctly.
And there is no error message in your error file.
A few questions:
- What happens if run yaft as root?
- Can you quit yaft by typing "exit" or using Ctrl-D?
can't run as root either. yes i can ctrl-D to get back to a prompt. i tried installing yaft and fbv on another machine with linux mint and it worked fine. must be something to do with using yaft on arch in a virtual machine. oh well. thanks for the help. i appreciate it.
I experienced this just now using Debian 9.8 (stretch) in VirtualBox. I was able to see yaft work by:
- Uninstalling all VirtualBox guest packages.
- Rebooting.
- Logging into another VT (console).
- Disabling sddm (KDE login manager).
- modprobe uversafb (after installing v86d). Prior to this, /dev/fb0 does not exist and and yaft fails on open() with some error messages.
This got me to the simplest working version.
(Sidebar: This let me try out yaft against jexer . yaft is the first terminal outside xterm successfully displaying mixed-mode text and sixel!)
@klamonte thanks for enjoying yaft :)
@mrsteve0924 I don't know the cause of this problem, but it may be some graphics hardware problem.
Please tell me the type of Virtual Machine (and graphics emulation device) that you are using. Virtualbox or VMware or qemu etc...
And output of fbset -i is also helpful.
(it's included in fbset package in Arch)
I need to re-produce this problem to fix.
Hi @uobikiemukot .
Thankyou for great project.
I have same Problem this issue.
- I use Archlinux
- Kernel version is
5.0.3-arch1-1-ARCH VERBOSE=trueerr file is https://termbin.com/szw2- same problem run root
fbset -iresult is https://termbin.com/zgwb
Let me know if we can give you any other information.
Hi,
I cannot re-produce this problem at the moment.
I'll test yaft with intel iGPU on latest ArchLinux.
@dohq You can use other framebuffer software (fbv, fbterm, mlterm-fb, etc...) without any problem?
@mrsteve0924 If you are using Virtualbox, please try to change graphics hardware settings.
I tested these devices:
- VBoxVGA: core dump by
vmalloc_to_page - VBoxSVGA: works (but color is not correct)
- VMSVGA: works well
fbv also fails with VBoxVGA. I think this problem is not caused by yaft.
@uobikiemukot
Thankyou for reply.
I checked other use framebuffer apps.
mlterm-fb: do not work(freeze)fbv: work finefbterm: work fine
hmm... isolate the cause is difficult 🤔 .
I have the same issue. But does yaft really lock the terminal? I don't think so. If I type e.g. ls, I won't see right away. But if I change to another tty and change back, I see the output.
I think yaft is simply being too lazy about updating the underlying framebuffer under certain drivers. I also have Intel i915.
I have the same issue. Also i915. C-d does close yaft. Switching tty reveals input is processed but the screen is not refreshed. tried with all combinations of conf.h options involving when the screen is refreshed. I'd like to get this to work, as fbterm / dvtm don't support sixel and don't seem to be changing that anytime soon.
We should figure out what fbterm is doing different.
I can confirm that fbterm does not suffer from this problem, neither does dvtm. So they are certainly a resource for this.
@ctrlcctrlv @TCCQ
I think I figured it out. It looks like fb needs to be activated after settings KD_GRAPHICS.
I have intel graphics and got yaft working with this patch.
https://unix.stackexchange.com/questions/58420/writes-to-framebuffer-dev-fb0-do-not-seem-to-change-graphics-screen
diff --git a/fb/linux.h b/fb/linux.h
index 5e572b6..3981815 100644
--- a/fb/linux.h
+++ b/fb/linux.h
@@ -99,6 +99,8 @@ bool set_fbinfo(int fd, struct fb_info_t *info)
if (ioctl(fd, FBIOPUT_VSCREENINFO, &vinfo))
logging(WARN, "couldn't reset offset (x:%d y:%d)\n", vinfo.xoffset, vinfo.yoffset);
}
+ vinfo.activate = FB_ACTIVATE_NOW | FB_ACTIVATE_FORCE;
+ ioctl(fd, FBIOPUT_VSCREENINFO, &vinfo);
return true;
}
diff --git a/yaft.c b/yaft.c
index 7b145aa..014746b 100644
--- a/yaft.c
+++ b/yaft.c
@@ -170,6 +170,11 @@ int main(int argc, char *const argv[])
if (setlocale(LC_ALL, "") == NULL) /* for wcwidth() */
logging(WARN, "setlocale falied\n");
+ if (!tty_init(&termios_orig)) {
+ logging(FATAL, "tty initialize failed\n");
+ goto tty_init_failed;
+ }
+
if (!fb_init(&fb)) {
logging(FATAL, "framebuffer initialize failed\n");
goto fb_init_failed;
@@ -180,11 +185,6 @@ int main(int argc, char *const argv[])
goto term_init_failed;
}
- if (!tty_init(&termios_orig)) {
- logging(FATAL, "tty initialize failed\n");
- goto tty_init_failed;
- }
-
/* fork and exec shell */
cmd = (argc < 2) ? shell_cmd: argv[1];
if (!fork_and_exec(&term.fd, cmd, argv + 1, term.lines, term.cols)) {Alright.
I can can confirm that @pnutbtr 's patch does fix the freezing issue. It's now reactive and seems to be stable. I did also notice that things like screen clears (C-l) and full screen management programs (less, more, man) do not scroll correctly. A screen clear just does the same thing as an enter in a shell (new prompt on the next line), and the screen management programs leave artifact lines around here and there. No clue if that is related or some other issue of mine.
@TCCQ did you install terminfo db? That usually happens when shell can't find terminfo files.
Yea that was it. A combination of running it out of the makedir and not make installing and not applying the patch correctly. It all seems good now.
As you can see, I made a PR for just the patch above.
@pnutbtr's patch is almost correct, but not quite, as it only runs once. The FB also needs to be activated every time the virtual terminal is switched to with Ctrl+Alt+Fn or it will lock up in the same way. I will submit a pull request soon.
@uobikiemukot are you still around and interested in this project? Do you want us to fork it to continue development elsewhere?