jstkdng
commented
8 months ago Hey, can you show the logs after running export SPDLOG_LEVEL=debug? They are located on /tmp/ueberzugpp-$USER.log
Closed lucas-mior closed 5 months ago
jstkdng
commented
8 months ago Hey, can you show the logs after running export SPDLOG_LEVEL=debug? They are located on /tmp/ueberzugpp-$USER.log
BennyOe
commented
7 months ago @jstkdng my st config is
There are quite a lot of patches used. I'm using this repo https://github.com/papitz/SimpleTerminal/tree/benni
But the bug was also happening on xTerm with no configuration added.
I don't know if this can be an issue with the window manager as well. I'm using dwm with also a lot of patches included. If you need any logs or want me to check something, I will be glad to investigate and help.
jstkdng
commented
7 months ago I'm checking the logs from the yazi issue and I noticed that st is returning bad ioctl values after the first run.
[2024-04-11 09:19:45.315] [terminal] [debug] ioctl sizes: COLS=0 ROWS=0 XPIXEL=0 YPIXEL=0
That could be an issue on st's side. Also tested xterm and I'm unable to reproduce the issue, can you reproduce the issue if you run plain ueberzug without yazi?
BennyOe
commented
7 months ago I tested it with {"action":"add","identifier":"preview","max_height":0,"max_width":0,"path":"/your/image-path.jpg","x":0,"y":0} and this worked. But with yazi it only works when I downgrade ueberzug
lucas-mior
commented
6 months ago Yes, using "max_width" and "max_height" without "scale":"fit_contain" works, however that's not the same behaviour. Small images dont get scaled up to make use of the available space. It seems to be me that "scale":"fit_contain" no longer works (in version 2.8.8 it still works).
lucas-mior
commented
6 months ago Or not. Using most recent ueberzug version still has the same problem, even using "max_width"and "max_height". So I guess I have to keep using version 2.8.8 for now.
Ornanovitch
commented
6 months ago I have the very same problem since today, when I updated ueberzugpp from 2.9.4-1 to 2.9.4-2 on Archlinux. But this bump of the pkgrel has only been triggered to fix some out of date/missing libraries... I don't know which one, but maybe this comes from a library.
jstkdng
commented
6 months ago Could be a recent sway update, I'll investigate
Ornanovitch
commented
6 months ago I personally don't use sway, I was more thinking about ueberzugpp dependencies like opencv or libxcb. Could it comes from sway if I don't use it?
Ornanovitch
commented
6 months ago I realize it's working again on my side since a reboot... so I suspect I have the same behavior as the one described in the original Yazi issue:
when I close the terminal without exiting yazi before and then reopen yazi in a new terminal the preview is messed up
Ornanovitch
commented
6 months ago Sorry for the multiple comments, but I just managed to identify a potential problem: with Yazi I navigated into a folder with hundreds of images. While everything looks ok on the ui side, a generation process seems blocked:
If I try to quit properly Yazi, it warns me:
1 task running, sure to quit?
In the meantime, here is the unfinished job from the ueberzugpp log:
[2024-05-11 13:07:12.939] [opencv] [info] loading file /tmp/yazi/5b580669acab7d41a304b978b4138b2a
[2024-05-11 13:07:14.583] [main] [info] Command received: {"action":"remove","identifier":"yazi"}
# nothing else afterBut If I force quit and re-open Yazi, everything works again (as of now), so maybe I had no luck yesterday...
jstkdng
commented
6 months ago Please do raise that issue with the yazi dev, looks weird.
Could it comes from sway if I don't use it?
Sorry, that was for another issue, don't mind it
lucas-mior
commented
6 months ago Update: It seems that ueberzugpp works fine until version 2.9.3. From 2.9.4 onwards, the following command does not work properly (bug described in the first comment):
dprintf(UEBERZUG_FIFO.fd,
"{\"action\": \"add\", \"identifier\": \"preview\","
"\"x\": %u, \"y\": %u, \"max_width\": %u, \"max_height\": %u,",
pane.x, pane.y, pane.width, pane.height);
dprintf(UEBERZUG_FIFO.fd, "\"path\": \"%s\"}\n", image.fullpath);After testing the git commits between the versions mentioned above, it seems that the commit that created the bug is 082e34e. The diff follows:
diff --git a/src/application.cpp b/src/application.cpp
index 721b7f7..7ba9148 100644
--- a/src/application.cpp
+++ b/src/application.cpp
@@ -219,22 +219,25 @@ void Application::socket_loop()
{
UnixSocket socket;
socket.bind_to_endpoint(util::get_socket_path());
- const int waitms = 100;
+ const int waitms = 100;
+ int conn = -1;
while (true) {
- int conn = -1;
try {
conn = socket.wait_for_connections(waitms);
- if (stop_flag.load()) {
- break;
- }
- if (conn == -1) {
- continue;
- }
} catch (const std::system_error &err) {
stop_flag.store(true);
break;
}
+
+ if (stop_flag.load()) {
+ break;
+ }
+
+ if (conn == -1) {
+ continue;
+ }
+
const auto data = socket.read_data_from_connection(conn);
for (const auto &cmd : data) {
if (cmd == "EXIT") {
diff --git a/src/canvas/wayland/wayland.cpp b/src/canvas/wayland/wayland.cpp
index 4f1457d..be9d622 100644
--- a/src/canvas/wayland/wayland.cpp
+++ b/src/canvas/wayland/wayland.cpp
@@ -190,6 +190,7 @@ void WaylandCanvas::handle_events()
{
const int waitms = 100;
const auto wl_fd = wl_display_get_fd(display);
+ bool in_event = false;
while (true) {
// prepare to read wayland events
@@ -199,20 +200,22 @@ void WaylandCanvas::handle_events()
wl_display_flush(display);
try {
- const auto in_event = os::wait_for_data_on_fd(wl_fd, waitms);
- if (Application::stop_flag.load()) {
- break;
- }
- if (in_event) {
- wl_display_read_events(display);
- wl_display_dispatch_pending(display);
- } else {
- wl_display_cancel_read(display);
- }
+ in_event = os::wait_for_data_on_fd(wl_fd, waitms);
} catch (const std::system_error &err) {
Application::stop_flag.store(true);
break;
}
+
+ if (Application::stop_flag.load()) {
+ break;
+ }
+
+ if (in_event) {
+ wl_display_read_events(display);
+ wl_display_dispatch_pending(display);
+ } else {
+ wl_display_cancel_read(display);
+ }
}
}
diff --git a/src/canvas/x11/x11.cpp b/src/canvas/x11/x11.cpp
index e64862a..5c12418 100644
--- a/src/canvas/x11/x11.cpp
+++ b/src/canvas/x11/x11.cpp
@@ -123,21 +123,24 @@ void X11Canvas::handle_events()
const int event_mask = 0x80;
const int waitms = 100;
const int connfd = xcb_get_file_descriptor(connection);
+ bool status = false;
while (true) {
try {
- const bool status = os::wait_for_data_on_fd(connfd, waitms);
- if (Application::stop_flag.load()) {
- break;
- }
- if (!status) {
- continue;
- }
+ status = os::wait_for_data_on_fd(connfd, waitms);
} catch (const std::system_error &err) {
Application::stop_flag.store(true);
break;
}
+ if (Application::stop_flag.load()) {
+ break;
+ }
+
+ if (!status) {
+ continue;
+ }
+
const std::scoped_lock lock{windows_mutex};
auto event = unique_C_ptr<xcb_generic_event_t>{xcb_poll_for_event(connection)};
while (event) {
diff --git a/src/terminal.cpp b/src/terminal.cpp
index 84c52fe..74a0af6 100644
--- a/src/terminal.cpp
+++ b/src/terminal.cpp
@@ -48,7 +48,10 @@ Terminal::Terminal()
logger = spdlog::get("terminal");
term = os::getenv("TERM").value_or("xterm-256color");
term_program = os::getenv("TERM_PROGRAM").value_or("");
- logger->info(R"(TERM="{}", TERM_PROGRAM="{}")", term, term_program);
+ logger->info("TERM = {}", term);
+ if (!term_program.empty()) {
+ logger->info("TERM_PROGRAM = {}", term_program);
+ }
open_first_pty();
get_terminal_size();
set_detected_output();why are you dividing the command into multiple writes?
dprintf(UEBERZUG_FIFO.fd, "{\"action\": \"add\", \"identifier\": \"preview\"," "\"x\": %u, \"y\": %u, \"max_width\": %u, \"max_height\": %u,", pane.x, pane.y, pane.width, pane.height); dprintf(UEBERZUG_FIFO.fd, "\"path\": \"%s\"}\n", image.fullpath);
jstkdng
commented
6 months ago I pushed a fix to master, please do test it
lucas-mior
commented
5 months ago why are you dividing the command into multiple writes?
dprintf(UEBERZUG_FIFO.fd, "{\"action\": \"add\", \"identifier\": \"preview\"," "\"x\": %u, \"y\": %u, \"max_width\": %u, \"max_height\": %u,", pane.x, pane.y, pane.width, pane.height); dprintf(UEBERZUG_FIFO.fd, "\"path\": \"%s\"}\n", image.fullpath);
Only for code organization. Also I use ueberzug commands in other scripts and they all shared the same problem, not only this C code.
lucas-mior
commented
5 months ago I pushed a fix to master, please do test it
It seems to be working, thank you very much.
jstkdng
commented
5 months ago Nice, closing then
Something happened between version
2.8.8and2.9.4, because in the former, everything works as expected, but on the later, the images are always displayed on the upper left corner and real size, no matter whatx,y,widthandheightoptions I pass. I have not changed my configuration (which I have used for years).