Displaying --Image-bg fails with hexcodes darker than #202020

[VGrol]

I've encountered some odd behavior. It appears that when passing --image-bg to Feh, it only accepts certain values. When it decides to reject them it'll default to the usual 'black'.

It appears to be threshold based and -V isn't listing anything peculiar. An example would be --image-bg "#202020" working fine, but dropping to #191919 would result in the standard black.

I've tried several parsing values and quite a few colours, it appears to be limited to certain darker values.

feh version 2.27 Compile-time switches: curl exif help stat64 xinerama

Attempted via Fish and Bash, both gave similar results. Called via Termite.

[amaurea]

I can't reproduce this on feh version 2.27 Compile-time switches: curl exif help stat64 xinerama on arch linux. --image-bg "#191919" is just slightly darker than "#202020", and still distinct from full black.

What happens if you take a screenshot of the background from "#191919" and examine the exact color of those pixels in an image editor? Are they really exactly "#000000"? Also, do you see any other discontinuous changes, for example at "#404040"?

[VGrol]

Any kind of content seems to display fine.

On actual backgrounds, thus via commands like --bg-center, it displays fine. It seems to be mostly confined to the feh picture window (by calling feh without arguements, like below).

feh ~/[DIRECTORY] --image-bg "#191919"

From what I've seen, any color variation that is lighter than #191919 seems to do fine, it's just that anything darker than #202020, such as 191919 or 101010 becomes 000000.

[ulteq]

From what I've seen, any color variation that is lighter than #191919 seems to do fine, it's just that anything darker than #202020, such as 191919 or 101010 becomes 000000.

I can reproduce it on Arch Linux (feh v2.27).

Both feh --image-bg '#191919' and feh --image-bg 'Gray12' produce black backgrounds for me.

[derf]

Hmm, I see a pretty clear difference between #202020, #1c1c1c, #151515, #101010, and #080808 on my system.

[Ferada]

Can't reproduce this (on Ubuntu 18.04, looks like via Wayland actually).

So if there's the wrong colour being rendered, the below should have zeros, right, maybe you could check that? This was on master.

$ gdb feh # in the folder where you want to run it
(gdb) set args --image-bg '#191919'
(gdb) b feh_create_checks
Breakpoint 2 at 0x555555574a30: file winwidget.c, line 609.
(gdb) r
...
Breakpoint 2, feh_create_checks () at winwidget.c:609
(gdb) next # until you hit the line below
...
627                             gib_imlib_image_fill_rectangle(checks, 0, 0, 16, 16, color.red, color.green, color.blue, 255);
(gdb) print color
$4 = {pixel = 1644825, red = 6425, green = 6425, blue = 6425, flags = 7 '\a', pad = 0 '\000'}
(gdb)

[VGrol]

I can reproduce it on Arch Linux (feh v2.27).

It might be isolated within Arch then, since that is also the Distro I was having trouble with (X11).

Can't reproduce this (on Ubuntu 18.04, looks like via Wayland actually).

So if there's the wrong colour being rendered, the below should have zeros, right, maybe you could check that? This was on master.

I'm having some trouble running the arguements above in GDB. I'm probably doing it wrong though.

Running gdb as feh and settings the args above results in feh not running due to no image being specified, if I append an image location, it runs a seperate feh window that locks up gdb. Passing the & argument works I suppose.

Anyways, passing the breakpoints as one line, results in a confirmation for each line; Make breakpoint pending on future shared library load? (y or [n]) Breakpoint 2, *line that was inserted here* Please answer y or [n].

Answering y or n doesn't really change anything. It'll claim the breakpoint 'feh_create_checks' is pending.

After that, print color, with or without the arguments posted below results in No symbol table is loaded. Use the "file" command.

[Ferada]

Yeah, I just copied what I had on the terminal, I've updated the order of commands, of course you need the breakpoint established before running it; also feh needs to have the debug info, then gdb feh, add the arguments there, then run it. I've added that and some comments - you might also be able to set the breakpoint on gib_imlib_image_fill_rectangle maybe ...

[ulteq]

I can reproduce it on Arch Linux (feh v2.27).

--image-bg '#191919' translates to red = 6425, green = 6425, blue = 6425, but the background is black nonetheless.

[Ferada]

Maybe Imlib2 does something weird? The pixel data still shows this for me immediately before it's sent to the drawable, is that also still valid for you?

...
(gdb) b gib_imlib_image_fill_rectangle
(gdb) r
...
Breakpoint 1, gib_imlib_image_fill_rectangle (im=0x5555557ca010, x=0, y=0, w=16, h=16, r=6425, g=6425, b=6425, a=255)
    at gib_imlib.c:267
267     {
(gdb) finish
Run till exit from #0  gib_imlib_image_fill_rectangle (im=0x5555557ca010, x=0, y=0, w=16, h=16, r=6425, g=6425, b=6425,
    a=255) at gib_imlib.c:267
0x0000555555574c11 in feh_create_checks () at winwidget.c:627
627                             gib_imlib_image_fill_rectangle(checks, 0, 0, 16, 16, color.red, color.green, color.blue, 255);
(gdb) x/x (unsigned int*) imlib_image_get_data(checks)
0x5555557c9c00: 0xf6191919
(gdb)
0x5555557c9c04: 0x00191919
(gdb)
0x5555557c9c08: 0xf6191919
(gdb)
0x5555557c9c0c: 0x00191919
(gdb)