If no monitors are selected while proceeding with the option "Full screen on selected monitor(s)" the login background is corrupted.
Tested this bug on various platforms and server/client versions. The ThinLinc server was installed on Fedora37 in all test cases, and the default login background is used. server 4.14.0 client 4.14.0 Fedora37 : ✓ MacOS13.1 : ✓ Win10 : x (all black) server 4.14.0 client #2881 Fedora37 : ✓ MacOS13.1 : ✓ Win10 : x (all black) server #2976 client 4.14.0 Fedora37 : x (all white) MacOS13.1 : x (all white) Win10 : x (all white) server #2976 client #2881 Fedora37 : x (all white) MacOS13.1 : x (all white) Win10 : x (all white) It seems this bug is partially a regression from 4.14.0, although the Windows results hints 4.14.0 was not in a proper robust state.
Correction to comment 1: The Fedora37 machine used to host the server on happened to have xsri installed, but not xsetroot. This caused the background to exhibit the background image when xsri executed properly, and go plainly black when xsri failed. It's a bit unclear why it failed for Windows (10 & 11) while pummeling through on Fedora37 and MacOS13.1. My best guess is that in this special case of "no selected monitors", Windows and other platforms treat the dimensions a bit differently, which is why we are met with an xsri floating point exception on Windows, > /opt/thinlinc/libexec/tl-run-xstartup.d: line 40: 3945841 Floating point exception(core dumped) xsri ${color+--color "${color}"} ${image+--emblem "${image}" --scale-width 100 --scale-height 100} and not on the others. Re-testing with server 4.14.0 on an Ubuntu22.04 lacking xsri while having xsetroot, yields the expected plain blue background on all platforms (Fedora37, MacOS13.1, Win10&11). In conclusion: in this special case with no monitors selected, the old xsri solution happen to produce the background image in some cases while crashing in others, and the new implementation of drawing the background has some unresolved issues of its own.
