Passing -a 16 causes wrong colors
#213
Comments
|
That's odd. Is there anything special about your setup - an odd client/server OS, CPU, architecture, anything? I can't reproduce with just using |
|
On 01/02/18 15:43, Karl Mikaelsson wrote:
That's odd. Is there anything special about your setup - an odd
client/server OS, CPU, architecture, anything? I can't reproduce with
just using `-a 16` with the most basic tests - any further details
would help.
What resolution does your screen have, and what graphics device do you
use? If I know that, I could find a similar system here.
|
|
I used a 2560x1440 Dell monitor with Intel graphics when testing. |
|
Very strange. If a change the resolution with With the debug level increased in the source code directly, here is the difference in the output. Do you spot anything there? |
|
No, I'm not seeing anything strange in that log output. |
|
Any hint, which function/variable I have to inspect to see what color is used? |
|
Good:
Bad (passing
|
|
Just checked with the most recent sources (master). Although I saw this issue some time ago (alas can't remember which Windows version it was). I'm not even sure that I saw this issue with the most recent rdesktop:( @paulmenzel, could you please check that this issue does exist in the latest master (i.e. build from clone and not from release tarball)? |
|
On 01/04/18 14:42, Alexander Zakharov wrote:
@paulmenzel, could you please check that this issue does exist in the latest master (i.e. build from clone and not from release tarball)?
Sorry, I forgot to mention, that I already tried that (to get debug
messages), and it’s still reproducible.
|
|
The culprit seems to be in the code below. With By the way, passing |
|
I could just be misinterpreting your intentions, but wouldn't this patch just overwrite whatever color depth you specify to |
|
It’s not a patch, it’s just for showing where it seems to make a difference. I have no clue, where in the code execution |
|
From what I could grep, |
|
If I break on the first access to |
|
Watching Does somebody know, what is happening in |
|
I guess the culprit is here (rdp_process_bitmap_caps(): line 1085 in rdp.c 1076 /*
1077 * The server may limit depth and change the size of the desktop (for
1078 * example when shadowing another session).
1079 */
1080 if (g_server_depth != depth)
1081 {
1082 logger(Core, Verbose,
1083 "Remote desktop does not support colour depth %d; falling back to %d",
1084 g_server_depth, depth);
1085 g_server_depth = depth;
1086 }But I don't know whether this is intentional or not. |
|
On 01/04/18 16:46, Alexander Zakharov wrote:
I guess the culprit is here (**rdp_process_bitmap_caps()**: line 1085 in rdp.c
````c
1076 /*
1077 * The server may limit depth and change the size of the desktop (for
1078 * example when shadowing another session).
1079 */
1080 if (g_server_depth != depth)
1081 {
1082 logger(Core, Verbose,
1083 "Remote desktop does not support colour depth %d; falling back to %d",
1084 g_server_depth, depth);
1085 g_server_depth = depth;
1086 }
````
But I don't know whether this is intentional or not.
According to comments is rather common.
No, I don’t think that’s the culprit, as it works the same from there on.
As written in the other comment, `g_server_depth` is accessed before
this code, so there *must* be the difference judging how the code is
deterministic and the issue reproducible in my environment.
|
|
What I meant to say was "the culprit of downgrading color depth from 24 to 16" not the cause of observable color inversion. |
|
Ah, sorry for the misunderstanding. The user wanted to get rid of the downgrading message by explicitly passing |
|
It's ok. |
|
@paulmenzel, do you have the box (or VM) with other Windows version to test this issue on, by any chance? |
GoodBad |
|
So as can be seen from the GDB traces, totally different code paths are taken depending if |
|
Hi,
I don't think any library rdesktop is linked against has been upgraded here. |
|
Mesa should not be involved as rdesktop probably does not use OpenGL. Leave libdrm as a likely candidate. Can you downgrade back from 2.4.83 to 2.4.76? Something like |
|
@bogbert Do you use wayland or X11? Can you switch to X11 and see if the problem disappears? |
|
Installing Ubuntu 17.10 with libdrm2 2.4.83, I am able to reproduce the problem. Can the people in here, not able to reproduce this, check if they can set up such an environment? |
|
@paulmenzel when you are at it, could you test run a X11 session [1] and see if the problem persists ? |
|
I am running a X11 session as far as I can see.
|
|
With the commits from merge/pull request #229, I get the output below. |
|
Here is the difference in Good (without
|
|
By the way, here are all the visuals found by rdesktop with |
|
I could not reproduce this issue on 17.10 (libvirt) with the requested libdrm version. Wasted several hours to find the good image on vagrant hub which does not hang after mutating it to libvirt provider. It's strange but most images are for VirtualBox nowadays:( |
I think I tested by specifying |
|
Connecting to a Windows 10 machine (which in contrast supports 32 bit color depth – no idea why, I am not the administrator) and passing |
|
I tested with and without passing -a 16. But as I said earlier, once or twice I saw the same picture distortion (not while testing with Ubuntu 17.10 with libdrm2 2.4.83 though). I can't recall whether I saw the requested message (i.e. “color depth downgrade message” ). Still got Ubuntu VM lying around. |
|
Oh good, I'm not going mad... I have this bug with "rdesktop -a 16" when connecting to (a) Windows Server 2008, (b) xrdp running on Fedora. Both servers support 24 bits but I happen to have "-a 16" in a script for historical reasons. This started happening at some (indeterminate) time in the recent past, whereas the rdesktop binary hasn't changed for ages. What seems to matter is the X11 display it's being run on. If I ssh to an old Fedora 22 machine and run rdesktop -a 16 there on my display, the colours are wrong. If I start a VNC server on my own desktop, connect to it, and run rdesktop -a 16 inside the VNC session, the colours are correct. In fact if I reverse the pixel format of the VNC server, it's still correct. So for the default (RGB888) if I print *g_visual once the window is drawn: |
|
I too am experiencing this issue. One thing I have notices that I have not seen anyone else mention, though, is the behavior when I specify 32 color depth. I get the exact same color issue as others when using -a 16 and no color issue if I don't specify the color depth or specify 24. On 32, after the login screen, some elements have the correct color and some have the red and blue values swapped. Additionally, if you move a window around, the colors of the region that was under the window is correct as it redraws them. I'm guessing it uses different methods to display different portions of the screen when using 32bit color depth in order to save bandwidth. I'm not sure if this helps in identifying why it's different when specifying the color depth versus not. |
|
@Hithlum Interesting, thanks for the additional info. It would suggest that a certain drawing operation could be (partially) guilty for these error. I can't figure out an easy way to figure out which one though. We should have debug logs for most drawing operations, but looking for info in those logs is getting into needle-in-a-haystack territory. |
|
Hi, I'm also got this bug. |
|
Reinstalled OS, didn't install updates via GUI updater, only 'apt upgrade', and problem dissapears. Looks like this is not rdesktop problem, but some other package. Can try to install updates from GUI updater one-by-one, to look for bug, if needed |
|
@Fighter34RUS Thanks! Did I understand you correctly that upgrading via apt or via the GUI produces different results? Do you know if the GUI updater adds the LTS Enablement Stack to your Ubuntu install? I remember this upgraded both the kernel and the X11 infrastructure to more recent versions. This could explain any differences in your case. |
|
Hi. Yep, after apt upgrade there are about 80 packages, which GUI updater asks to install. |
Check for the presence of the linux-generic-hwe-16.04 and xserver-xorg-hwe-16.04 packages, or simply if you're running a 4.4.0 or a more recent kernel version. |
|
Hi, it's me again) Looks like LTS Enablement Stack is already installed: There are 3 packages, cross-referenced, as I think: Before installing these - rdesktop works fine, after - got color inversion |
|
Is this was useful? Maybe need some additional info? |
|
Same issue on Ubuntu 17.10 with Compiz using -a16 , -a32 works fine . |
|
I had this problem under LXDE (openbox, as long as I remember) |
|
I've just seen this issue selectively while using the -a16 after a CentOS 7.5 update from CentOS 7.4. I know wayland is a part of this upgate. However, I'm not seeing every type of system affected. Older Optiplex 980's (with Radeon HD 5000/6000/7350/8350 Series) and Precision T1700 were not affected. All of the Optiplex 7010's (with i5-3470S and on-chip GPU) and 9020's (with i5-4570S on on-chip GPU) are affected. All of the Optiplex's are base installed the same PXE way. |
|
More data: I had the same issue appear a few weeks ago after doing a standard update of Ubuntu 16.04.4 LTS (the machine had been nagging me for months to do one). No change in my rdesktop call or machine setup. This is running on an HP EliteDesk 800 G2, with a second HP of the same vintage right next to it that has windows. (I have to use Windows for the corporate trip and timecard systems). I'm happy to provide further information if you'll tell me what to provide. |
|
Further notes: I run xubuntu. Monitor is an older Dell MX. |
|
I can't reproduce this problem anymore. |
|
Hey, you're right. I haven't tried in such a long time. I can confirm
that I'm not seeing the same issue at this time, also.
Thanks
PJ
…On 2/27/19 11:16 AM, bogbert wrote:
I can't reproduce this problem anymore.
I suppose the library at fault has been fixed, and the fix deployed on
my machine during a package update.
Maybe it's time to close this issue ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#213 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHQGsJgR0YZ7kuq8n443eSBlcAe6QLu5ks5vRr2HgaJpZM4RDsIm>.
|
|
Thank you for your update. We'll close this and hopefully there will be no more occurrences. :) |
With rdesktop 1.8.3, on two systems, one with a monitor with a resolution of 2560x1440 (AMDGPU graphics driver) and the other HiDPI/4K (3840x2160) monitor Dell U2718Q with Intel graphics, explicitly setting the color depth to 16 bit to get rid of the message below, results in inverted colors.
The resolution doesn’t matter.
Strangely, when not passing
-a 16, the message quoted above suggests that 16 bit color depth is used.Good:
Bad (passing
-a 16):The text was updated successfully, but these errors were encountered: