[Bug]: raspberry pi ${color anycolor} turns text black

[rschell]

What happened?

I have three Debian x86_64 machines on 6.2.9 which display as expected, with argb_visual set to true.

I also have four raspberry pi 4b machines where, if I place any ${color xxxx} text in the text field, the text colors turn black and cpu/memory graphs disappear.

My workaround is to remove all references to ${color} in the text field of .conkyrc and use a default_color setting in the config field, which results in:

I don't know was is missing from the Raspberry Pi software configuration (running 6.1.19 kernels), any clues? These .conkyrc setups where working just fine prior to 1.18.

When started in a terminal window, no error messages are produced when the .conkyrc file is reloaded: conky: '/home/ron/.conkyrc' modified, reloading... conky: desktop window (1200028) is subwindow of root window (3a2) conky: window type - normal conky: drawing to created window (0x3000002) conky: drawing to double buffer

Version

1.18.1+ currently 1.18.3

Which OS/distro are you seeing the problem on?

Linux (other) [edit] all running xfce4 using xfwm4 compositor

Conky config

conky.config = {
    background = true, total_run_times = 0,
    double_buffer = true,
    update_interval = 1.0,
    alignment = 'top_right', gap_x = 10, gap_y = 10,
    minimum_width = 250, maximum_width = 400, minimum_height = 5,
    use_xft = true, font = '123:size=8',
    draw_shades = false, draw_outline = false, draw_borders = false, draw_graph_borders = false,
    own_window = true,
    own_window_type = 'normal',
    own_window_transparent = false,
    own_window_argb_visual = true, own_window_argb_value = 120,
    own_window_hints = 'undecorated,below,sticky,skip_taskbar,skip_pager',
    no_buffers = true,
    cpu_avg_samples = 2, net_avg_samples = 1,
    default_color = "gainsboro",
};

conky.text = [[
${font Arial:size=20}Pi-CNC
${font Arial:bold:size=10}SYSTEM ${hr 2}
${font Arial:bold:size=12}$sysname $kernel ${font Arial:size=10}$alignr $machine$font
Frequency $alignr${freq_g cpu0}Ghz
Uptime $alignr${uptime}

${font Arial:bold:size=10}CPU ${hr 2}$font
Temp: $alignr ${exec vcgencmd measure_temp | cut -c6-9} C$font
1  ${cpu cpu1}% ${alignr}${cpubar cpu1 8,195}
2  ${cpu cpu2}% ${alignr}${cpubar cpu2 8,195}
3  ${cpu cpu3}% ${alignr}${cpubar cpu3 8,195}
4  ${cpu cpu4}% ${alignr}${cpubar cpu4 8,195}
${cpugraph}

${font Arial:bold:size=10}MEMORY ${hr 2}$font
MEM $alignc $mem / $memmax $alignr $memperc%
$membar

${font Arial:bold:size=10}HDD ${hr 2}$font
/home $alignc ${fs_used /home} / ${fs_size /home} $alignr ${fs_used_perc /home}%
${fs_bar /home}

${font Arial:bold:size=10}NETWORK ${hr 2}$font
IP on end0 $alignr ${addr end0}
IP on wlan0 $alignr ${addr wlan0}

Down $alignr ${downspeed end0} kb/s
Up $alignr ${upspeed end0} kb/s

Downloaded: $alignr  ${totaldown end0}
Uploaded: $alignr  ${totalup end0}

#${font Arial:bold:size=10}${color Tan1}UPS ${color DarkSlateGray}${hr 2}
#${apcupsd localhost 3551}$font${color DimGray}Voltage: $alignr   ${apcupsd_linev}
#Charge: $alignr   ${apcupsd_charge}
#Load: ${apcupsd_loadbar}
#Time Left: $alignr   ${apcupsd_timeleft}
#Last: $alignr   ${apcupsd_lastxfer}
]];

Stack trace

No response

Relevant log output

No response

[bi4k8]

~This may be a 32-bit compatibility issue. I'll try to get a test system set up to see where the problem is.~

I guess the RPi 4B is actually 64-bit. I'm not sure what the issue could be.

[bi4k8]

Does setting own_window_argb_visual to false change the observed behavior?

[rschell]

The userland is 32 bit, the kernel is 64 bit. Changing kernel to 32 bit doesn't change the display, so I don't think its kernel related.

Changing argb_visual to false with a ${color Tan1} results in a black window with black text that is not visible. Using argb_visual = false and without a ${color Tan1} is a black window with default_color text.

With argb_visual = true with a ${color Tan1}, window is transparent with black text as above in second screen shot.

Using just ${color} has same effect.

using "${font Arial:size=20}$colorPi-CNC", $color without brackets, is treated as text and is displayed as "${colorpi}-CNC" edit: Added emphasis

[bi4k8]

I spun up a QEMU VM of RaspberryPi OS, built the latest git conky, and couldn't reproduce (the colors appear as expected both with an argb visual enabled and compositor running and without. What distro are you running, and does this still happen outside XFCE?

[rschell]

Using the Raspberry Pi distro, with rpi-update and raspbian testing. I'll setup a new OS and see what triggers the issue.

[rschell]

Starting with a new image, using the raspios-bullseye-armhf of 23-2-21, I setup conkyrc and xcompmgr in the LXDE desktop and it displays correctly.

Using rpi-update, switched to 6.1.21 kernel and in either 32bit or 64bit, the display is correct.

Bullseye which contains conky version 1.11.6.

Changing to Bookworm or testing things go south using LXDE, display similar to second screen shot.

Starting with a working 6.1.21 kernel (32bit armhf), and install Xfce4 (removing xcompmgr since Xfce has its own), display is still correct. Then switching to bookworm results in the same second screen shot.

[rschell]

Took this a step further, starting from Bullseye with 6.1.19 32 bit kernel, I added testing to the sources.list file, then selectively upgraded conky to 1.18.3. Same result like the second screen shot.

Besides conky, the following packages were upgraded: binutils binutils-arm-linux-gnueabihf binutils-common gcc-12-base libbinutils libc-bin libc-dev-bin libc-l10n libc6 libc6-dbg libc6-dev libctf-nobfd0 libctf0 libffi8 libjansson4 libstdc++6 libwayland-client0 libzstd1 locales rpcsvc-proto

[rschell]

Any other debugging you wish me to try. Version 19 hasn't shown up on the Debian/raspberry repos yet.

[muru]

I have the same issue, also running Xfce on Raspberry Pi, but I'm on a 3B+ running Arch Linux ARM (32-bit kernel and userland).

System details:

% conky --version | head -n1
conky 1.18.1_pre compiled 2023-02-24 for Linux armv7l
% uname -rm
6.1.28-5-rpi-ARCH armv7l
% cat /sys/firmware/devicetree/base/model
Raspberry Pi 3 Model B Rev 1.2
% DISPLAY=:0 xfwm4 -V
        This is xfwm4 version 4.18.0 (revision 7e7473c5b) for Xfce 4.18
        Released under the terms of the GNU General Public License.
        Compiled against GTK+-3.24.35, using GTK+-3.24.37.

        Build configuration and supported features:
        - Startup notification support:                 Yes
        - XSync support:                                Yes
        - Render support:                               Yes
        - Xrandr support:                               Yes
        - Xpresent support:                             Yes
        - X Input 2 support:                            No
        - Embedded compositor:                          Yes
        - Epoxy support:                                Yes

Some additional notes:

• Setting own_window_argb_visual to false makes the window use solid color set by own_window_colour but doesn't affect the buggy behaviour of ${color}.
• ${color foo} makes any after it text black, and any text before it uses the default colour. But once I use ${color foo} anywhere it's not possible to reset to the default colour later with ${color}. Shading and outline colours continue to work everywhere, however.

[muru]

I tried using i3 and picom instead of xfwm4, but the problem persists.

[rschell]

Problem still persists on 1.19.4 on Raspberry Pi

anybody notice the odd behavior in:

using "${font Arial:size=20}$colorPi-CNC", $color without brackets, is treated as text and is displayed as "${colorpi}-CNC"

[costispavlou]

I'm also having this issue. would be much obliged if anyone can help me

[tomybyte]

Hi,

same problem here. The Conky Text Color will be ignored after upgrade from Bullseye to Bookworm.

@:/# conky --version | head -n1 conky 1.18.3 compiled 2023-03-07 for Linux armv7l

@:/# uname -rm 6.1.61-v8+ aarch64

@:/# cat /sys/firmware/devicetree/base/model Raspberry Pi 5 Model B Rev 1.0

@:/# cat /etc/os-release PRETTY_NAME="Raspbian GNU/Linux 12 (bookworm)"

[rkanton]

Having the same problem after upgrade from Raspberry Pi OS Bullseye to Bookworm, on a 4B, with LXDE environment.

[Caellian]

@rschell @muru @costispavlou Can someone verify whether #1768 resolved this issue for them?

[rschell]

Can someone verify whether #1768 resolved this issue for them?

Just compiled 1.20.2_pre from cloned source this morning.

Display coloring is working now. Can't say if #1768 specifically resolved the issue, but 1.19.6 from "testing" still had the issue.

[Caellian]

Thanks. Closing this as resolved then. Let me know if this issue needs to be reopened.