conky1.10.8-1+b1 on Buster breaks bl-conkymove

johnraff · 2020-11-03 09:38:42

This is an example of why set-and-forget doesn't always work. Our beautiful conky-mover script bl-conkymove no longer works on Debian Buster. Something changed between conky 1.10.6-1 (stretch) and 1.10.8-1+b1 (buster).

test
In a Lithium BL, Menu > Preferences > Conky > Move a Conky fails at the first step because xwininfo is unable to identify the conky window. Alt-mousedrag also fails to move it. Check with 'xwininfo' in a terminal:

john@lithium:~$ xwininfo

xwininfo: Please select the window about which you
          would like information by clicking the
          mouse in that window.

xwininfo: Window id: 0x3600003 "Desktop"

  Absolute upper-left X:  0
  Absolute upper-left Y:  0
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 1440
  Height: 900
...etc...

This seems to be true for all settings of own_window_type, transparency, placement "above" or anything else.

BUT if you edit the conky file, conky will detect the change and restart itself. Now xwininfo and mouse-drag (if own_window_type is 'normal') work as usual.
BUT restart the conky either with "Conky Manager" or "Reload Conkys" and it's sunk back into the root window again.

You can emulate editing the conky file by sending a SIGHUP to all conkys with 'pkill -x -HUP conky'. This also makes things work again, so that line could be added to the start of bl-conkymove as a workaround. It's a hack though, because I don't know why it works and it could break again at any time.

I've looked at the changes between Conky 1.10.6 > 1.10.7 and 1.10.7 > 1.10.8 but couldn't spot anything obvious to account for the different behaviour.

Does anyone have a suggestion for a cleaner way of fixing this?

damo · 2020-11-03 10:00:15

Strange. It seems to happen when started on a new root window, eg after login: a "desktop" conky is not seen by xwininfo.

xwininfo sees the conky first time, if I in autostart I do

bl-conky-session --autostart && pkill -x -HUP conky && bl-conky-session --autostart &

EDIT: I don't see any similar issues on github: https://github.com/brndnmtthws/conky/issues

Last edited by damo (2020-11-03 10:14:45)

unklar · 2020-11-03 16:00:26

I think it is not because of lithium BL-Conky, but because of package x11-utils.
In (stretch) Helium and (sid) Siduction xwininfo behaves as expected.

damo · 2020-11-03 19:31:22

xwininfo can see the conky as a child of the root window. Though it would need some major geometry wrangling for bl-conkymove to be able to use that information, I think, if there is more than one conky running.

$ xwininfo -tree | grep conky
        0x3600002 "conky (bl-laptop)": ("conky" "conky")  420x1012+0+0  +1491+-11

Could we backport x11-utils, if that version is working?

DeepDayze · 2020-11-03 19:42:00

damo wrote:

xwininfo can see the conky as a child of the root window. Though it would need some major geometry wrangling for bl-conkymove to be able to use that information, I think, if there is more than one conky running.
$ xwininfo -tree | grep conky
        0x3600002 "conky (bl-laptop)": ("conky" "conky")  420x1012+0+0  +1491+-11
Could we backport x11-utils, if that version is working?

version of x11-utils in Sid (7.7+5) and in Buster x11-utils (7.7+4). Stretch has x11-utils (7.7+3)

Maybe see the differences between the versions?

Last edited by DeepDayze (2020-11-03 19:43:05)

johnraff · 2020-11-04 03:09:43

I tried removing conky 1.10.8 from a Buster system and installing 1.10.6 (the Stretch version), and the problem went away.

Certainly, on Stretch/Helium everything is OK.
Debian Sid and Bullseye have conky 1.11.6 which I couldn't install easily on Buster because of its libc6 dependency.

Not ruling out x11-utils, but another reason to think conky is at least also involved is that with own_window_type = 'normal' Alt+left_mouse drag doesn't work when xwininfo is showing "Desktop".

It's not necessary to go via the BL scripts to test this: (terminal output edited a bit)

john@lithium:~$ pgrep -ax conky
4640 conky -c /home/john/.config/conky/netusers.conkyrc
john@lithium:~$ kill 4640
conky: received SIGINT or SIGTERM to terminate. bye!

john@lithium:~$ conky -c /home/john/.config/conky/netusers.conkyrc &
[1] 4975
john@lithium:~$ conky: desktop window (100034e) is subwindow of root window (10e)
conky: window type - normal
conky: drawing to created window (0x3800002)
conky: drawing to double buffer
conky: forked to background, pid is 4979
[1]+  Done                    conky -c /home/john/.config/conky/netusers.conkyrc

# mousedrag does not work

john@lithium:~$ xwininfo

xwininfo: Window id: 0x600003 "Desktop"
# etc

john@lithium:~$ kill -HUP 4979
conky: received SIGHUP or SIGUSR1. reloading the config file.
john@lithium:~$ conky: desktop window (100034e) is subwindow of root window (10e)
conky: window type - normal
conky: drawing to created window (0x3800002)
conky: drawing to double buffer

# now mousedrag works

john@lithium:~$ xwininfo
xwininfo: Window id: 0x3800002 "netusers Conky"

DeepDayze · 2020-11-04 03:15:15

So then there's perhaps a bug in the version of Conky that's in Buster?

johnraff · 2020-11-04 05:10:54

^That's my theory, but I've really no idea atm.

Or else some tricky interaction between Buster versions of conky and x11-utils?

johnraff · 2020-11-15 06:06:48

damo wrote:

xwininfo sees the conky first time, if I in autostart I do
bl-conky-session --autostart && pkill -x -HUP conky && bl-conky-session --autostart &

I just had a look at bl-conky-session and with --autostart no conkys are killed, so this is layering a new conky on top of the previous one, which xwininfo can see as a separate window.

I think this will also work in autostart:

bl-conky-session --autostart && pkill -x -HUP conky

but as soon as bl-conky-manager is run the conky will be restarted and sink back into the root desktop.

As a workaround for bl-conkymove we could just put

pkill -x -HUP conky

at the top of the script, but that bypasses whatever the real issue is. We could just do that, though, and hope that the issue is fixed upstream before Bullseye...

johnraff · 2021-06-10 09:23:59

Just checked in a Beryllium VM (conky 1.11.6-2) and the issue seems to be gone.
It'll still need a real hardware test, but let's be optimistic...

Last edited by johnraff (2021-06-10 09:25:42)

DeepDayze · 2021-06-10 15:56:59

johnraff wrote:

Just checked in a Beryllium VM (conky 1.11.6-2) and the issue seems to be gone.
It'll still need a real hardware test, but let's be optimistic...

Would be cool to see if this can be backported to Buster...

My desktop rig has BL upgraded to Sid so I can test there later.

Last edited by DeepDayze (2021-06-10 15:58:04)

johnraff · 2021-06-11 05:08:42

DeepDayze wrote:

johnraff wrote:
Just checked in a Beryllium VM (conky 1.11.6-2) and the issue seems to be gone.
Would be cool to see if this can be backported to Buster.

Indeed, either a backport of 1.11.6, or else a patch based on finding what was causing the problem and applying the fix.

Any volunteers most welcome.

#1 2020-11-03 09:38:42

conky1.10.8-1+b1 on Buster breaks bl-conkymove

#2 2020-11-03 10:00:15

Re: conky1.10.8-1+b1 on Buster breaks bl-conkymove

#3 2020-11-03 16:00:26

Re: conky1.10.8-1+b1 on Buster breaks bl-conkymove

#4 2020-11-03 19:31:22

Re: conky1.10.8-1+b1 on Buster breaks bl-conkymove

#5 2020-11-03 19:42:00

Re: conky1.10.8-1+b1 on Buster breaks bl-conkymove

#6 2020-11-04 03:09:43

Re: conky1.10.8-1+b1 on Buster breaks bl-conkymove

#7 2020-11-04 03:15:15

Re: conky1.10.8-1+b1 on Buster breaks bl-conkymove

#8 2020-11-04 05:10:54

Re: conky1.10.8-1+b1 on Buster breaks bl-conkymove

#9 2020-11-15 06:06:48

Re: conky1.10.8-1+b1 on Buster breaks bl-conkymove

#10 2021-06-10 09:23:59

Re: conky1.10.8-1+b1 on Buster breaks bl-conkymove

#11 2021-06-10 15:56:59

Re: conky1.10.8-1+b1 on Buster breaks bl-conkymove

#12 2021-06-11 05:08:42

Re: conky1.10.8-1+b1 on Buster breaks bl-conkymove

Board footer