This is most likely linked with the recent refactoring of the color conversion code. I will get more time to work on fixing it in about a week or two, sorry about that. It has to do with the individual color conversion code, and not the image conversion code.

from freerdp-old.

I have just pushed a fix, the failure case shown should now work, and a lot of other corner cases have been fixed as well.

from freerdp-old.

I'm afraid this issue is not solved yet.

This is a connection to win 7: http://i54.tinypic.com/2aifo7b.png
and this is a connection to win 2003: http://i51.tinypic.com/wl3ekw.png

This is a small part of my xorg.conf:
Section "Screen"
Identifier "Screen"
Device "Video"
Monitor "Monitor"
DefaultDepth 16
SubSection "Display"
Depth 16
Modes "1680x1050"
Virtual 1680 1050
EndSubSection
EndSection

from freerdp-old.

Did you do a make clean and rebuilt? The previous code was dependent on compile-time options that could screw things up, while the newer code uses run-time options.

The problems shown are most likely related to the FillRect() implementation in 16bpp. Is your system 32 or 64bit, and is it a little-endian architecture?

I also noticed that your xorg.conf specifies a 16bpp color depth. I'm curious, what happens if you try 32bpp on an X11 server running at 16bpp?

from freerdp-old.

I forgot to specify: I do not have the problem when connecting to Windows 7 or any of my virtual machines.

I'm running openSUSE 11.4 64-bit. My xorg.conf uses the following:

Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor "Monitor0"
DefaultDepth 24
Option "TwinView" "1"
Option "TwinViewXineramaInfoOrder" "DFP-0"
Option "metamodes" "DFP-0: nvidia-auto-select +0+0, DFP-1: 1680x1050 +1680+0"
SubSection "Display"
Depth 24
EndSubSection
EndSection

from freerdp-old.

I confirm that the problem is actually triggered by the X11 server running in 16bpp mode. I have modified my xorg.conf to use 16bpp, and now I can reproduce the problem which you have. I'll need to look into why this is happening.

from freerdp-old.

Ok, I just pushed another fix that should correct the issues encountered when the X11 server is running in 16bpp mode. I have fixed the various problems that would happen with 16bpp<->32bpp color conversion paths. I also fixed the case where the server sends the bitmaps in 32bpp to a client running in 16bpp (inefficient, of course) so that it properly converts from 32bpp to 16bpp.

I have tried xfreerdp and dfbfreerdp in 16 and 32bpp modes for my X11 server in 16 and 24bpp modes, and all of them worked fine. Please confirm that it fixes the problem, otherwise report what went wrong :P

from freerdp-old.

Well, unfortunately for me still the same when X server is running in 16bpp: http://i54.tinypic.com/2924niq.png

Can I help you with any debugging?

from freerdp-old.

Ok, now I am truly mystified

I need to find at least a hint of what could be the reason for this.

Distro?
CPU Endianness?
X11 server?

Can you also give me the command-line options which you are using when connecting?

Also, how are you launching xfreerdp? Are your using the libtool-generated launch script, or invoking the real executable directly in .libs? If you're invoking the real executable directly it might be loading an older version of libgdi installed globally on the system. This would be especially true if you are using eclipse, followed my instructions on the wiki, and did not update launch configuration after libgdi was introduced.

from freerdp-old.

I launch the xfreerdp binary from /usr/bin. The command line is quite simple:

$ xfreerdp -u colorado -p ****** win7

And here is the information you required:

$ X -version

X.Org X Server 1.7.7
Release Date: 2010-05-04
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.32-5-686 i686 Debian
Current Operating System: Linux mentalist 2.6.32-3-686 #1 SMP Thu Feb 25 06:14:20 UTC 2010 i686
Kernel command line: root=UUID=7f217c56-ef89-4ec4-9522-12a3ab40e8ba ro nopat quiet
Build Date: 02 December 2010 01:08:37AM
xorg-server 2:1.7.7-10 (Julien Cristau [email protected])
Current version of pixman: 0.21.4
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.

$ cat /proc/cpuinfo

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz
stepping : 11
cpu MHz : 2000.000
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow vnmi flexpriority
bogomips : 5333.70
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz
stepping : 11
cpu MHz : 2000.000
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow vnmi flexpriority
bogomips : 5333.17
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

$ cat /etc/X11/xorg.conf

Section "Device"
Identifier "Video"
Driver "intel"
EndSection

Section "Monitor"
Identifier "Monitor"

HorizSync 20-200

VertRefresh 50-65

EndSection

Section "Screen"
Identifier "Screen"
Device "Video"
Monitor "Monitor"
DefaultDepth 16
SubSection "Display"
Depth 16
Modes "1680x1050"
Virtual 1680 1050
EndSubSection
EndSection

Section "ServerLayout"
Identifier "Layout"
Screen "Screen"
EndSection

Section "InputDevice"
Identifier "Generic Keyboard"
Driver "kbd"
Option "XkbRules" "xorg"
Option "XkbModel" "abnt2"
Option "XkbLayout" "br"
Option "XkbVariant" "abnt2"
EndSection

Section "InputDevice"
Identifier "Configured Mouse"
Driver "mouse"
EndSection

Section "Device"
Identifier "Configured Video Device"
Driver "intel"
EndSection

from freerdp-old.

Ok, the fact that you're launching it straight from /usr/bin might have to do with it. Can you please compile from scratch and launch xfreerdp using the launch script (./X11/xfreerdp) found in the source tree? If compiling from scratch + using the launch script fails, then it is not related to improper libraries being loaded at run-time.

from freerdp-old.

Launching ./X11/xfreerdp works.
Issues solved. Sorry for the inconvenience.

from freerdp-old.

That's ok :P watch out for which library gets loaded on your system, sometimes you're trying to fix something but keep loading the wrong library installed elsewhere. I'll close the issue then

from freerdp-old.

We got another colour issue: http://i55.tinypic.com/2njypzr.jpg

These are parts of the Xorg.0.log of the hardware. If there is more information we can provide you, just tell us:

(II) Loading /usr/lib/xorg/modules//libvgahw.so
(II) Module vgahw: vendor="X.Org Foundation"
compiled for 1.5.3, module version = 0.1.0
ABI class: X.Org Video Driver, version 4.1
(II) GEODE(0): Creating default Display subsection in Screen section
"Default Screen Section" for depth/fbbpp 24/32
(==) GEODE(0): Depth 24, (==) framebuffer bpp 32
(==) GEODE(0): RGB weight 888
(==) GEODE(0): Default visual is TrueColor
(==) GEODE(0): Using gamma correction (1.0, 1.0, 1.0)
(==) GEODE(0): No DCON is present
(II) GEODE(0): LX output options:
(II) GEODE(0): CRT: YES
(II) GEODE(0): PANEL: NO
(II) GEODE(0): DCON: NO
(II) GEODE(0): VGA: YES
(II) Loading sub module "int10"
(II) LoadModule: "int10"

.....................................

(II) Loading /usr/lib/xorg/modules//libexa.so
(II) Module exa: vendor="X.Org Foundation"
compiled for 1.5.3, module version = 2.4.0
ABI class: X.Org Video Driver, version 4.1
(--) Depth 24 pixmap format is 32 bpp
(II) do I need RAC? No, I don't.
(II) resource ranges after preInit:
[0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B]
[1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[4] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B]
[5] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B]
[6] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B]
[7] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[8] -1 0 0x00000000 - 0x00000000 (0x1) IX[B]
[9] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B]
[10] 0 0 0x000003c0 - 0x000003df (0x20) ISB GEODE(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
(II) GEODE(0): Geode LX video memory 1e00000 bytes at 0xb5219000
(II) GEODE(0): LX video memory:
(II) GEODE(0): Display: 0xa00000 bytes
(II) GEODE(0): Compression: 0xaa000 bytes
(II) GEODE(0): Cursor: 0x3000 bytes
(II) GEODE(0): ExaBfrSz: 0x40000 bytes
(II) GEODE(0): FREE: 0x1253000 bytes
(==) GEODE(0): Backing store disabled
(II) GEODE(0): DPMS enabled
Cannot run Xv without accelerations!

from freerdp-old.

Hi beloni,

Is this is a big endian system? I see Geode listed in what you pasted, which suggests an x86 architecture, but we never know. Is this a different system from the one which you were previously experiencing issues with?

Please describe as much as possible, this is very likely linked to an endianness issue. I suspect there are problems with xfreerdp on big endian systems, I just didn't have enough time to get my hand on a big endian system to try it out.

from freerdp-old.

Hello,

Yes, it is a x86 based machine. An AMD Geode LX800.

The color issue @Beloni was having was on his desktop. Now this happens on the thin client.

from freerdp-old.

Hi Otavio,

Did the issue appear recently, and was working after I got it fixed for @Beloni? Or is it the first time in a while you try it out on the thin client?

Which color depth are you using, 16 or 32bpp?

Also, how are you launching xfreerdp? Last time Eduardo was launching it directly with the executable and not the wrapper script, and an older version of libgdi.so installed elsewhere was loaded instead of the good one. Please try compiling from scratch and launching with the libtool-generated script, and see if it is still not working.

from freerdp-old.

We used to use an old version (before the GDI work) and RDesktop on this. Both worked fine. The version we tested is a today's snapshot so this is an issue found on tip of git.

from freerdp-old.

It has been compiled into the embedded OS and a fresh system. Not from the git repository. So all libraries of freerdp are up to date and installed properly.

from freerdp-old.

Ok, here's why trying a compilation from scratch + the launch script is very important here:

in between the older version and the latest one, libgdi was introduced. If you're not using the launch script, the wrong libgdi.so may be loaded, so be careful with that. Have you tried launching with the launch script (X11/xfreerdp, not X11/.libs/xfreerdp)?

from freerdp-old.

About color depth you can see, from the log @Beloni has pasted, it is running at 24bit with 32bit framebuffer.

from freerdp-old.

For color depth I meant the one used for the RDP session, with the -a <color_depth> parameter. This is important, because this influences the color conversion path used.

from freerdp-old.

It is packaged into the OS so it is being run from installed system, not source dir. The libraries has been all built and fresh installed, even libgdi.

from freerdp-old.

Ahh; IIRC he didn't pass any option but since it is Windows7 it ought to be 32bit, no?

from freerdp-old.

No, you can't assume 32-bit color depth, especially since certain servers disallow it. By default, xfreerdp tries to negotiate 16bpp color depth, not 32bpp, since 32bpp means bitmaps twice as large are used and are usually not the best choice performance-wise.

from freerdp-old.

This information I don't have offhand. AFAIK he didn't pass any option to specify the color depth of the connection so from the information you gave me it seems it ought to have used 16bit.

from freerdp-old.

I did a simple test using a color picker to compare the brown color with the blue color it should have been:

brown: #7B601D, RGB(0x7B, 0x60, 0x1D)
blue: #1D607B, RGB(0x1D, 0x60, 0x7B)

We can see that the error is that the blue and red colors have been swapped, as it is the case in errors related to BGR <-> RGB surfaces.

The brown color is drawn as part of an OpaqueRect message (see l_ui_rect in xf_win.c). The error should be related to the call to gdi_color_convert that happens there.

In order to figure out what the problem is, I'd need to know which parameters are used in the call to gdi_color_convert in xf_win.c's l_ui_rect: color = gdi_color_convert(color, inst->settings->server_depth, xfi->bpp, xfi->clrconv);

I need to know inst->settings->server_depth and xfi->bpp in particular for the calls to l_ui_rect.

from freerdp-old.

Right; it seems you traced it, cool :-) @Beloni can give this information to you on Monday morning.

@Beloni, please do the test @awakecoding has asked and provide the required information to him.

from freerdp-old.

Sounds good, I'll check it out when @Beloni sends the info

from freerdp-old.

Hi, I've posted the logs in the freerdp discussion list: http://sourceforge.net/mailarchive/forum.php?thread_name=149034.92771.qm%40web39405.mail.mud.yahoo.com&forum_name=freerdp-devel

I hope it is what you expect. The names of the log files refer to the -a parameter, so freerdp16 stands for an instance of freerdp with -a 16

from freerdp-old.

@Beloni yes I've seen the logs, I'd like to know in which one of those cases is the color conversion bug occurring?

from freerdp-old.

@awakecoding Every single one :)

from freerdp-old.

ok, try the following:

in xfreerdp.c's main(), add the following line after xfi->clrconv->palette = NULL:
xfi->clrconv->invert = 1;

Try it out in 16bpp mode and see if the result is different. If it's still not working as expected, but does something different, please describe how it is different

from freerdp-old.

Also, add the following debug output in xf_win.c's xf_pre_connect:

printf("depth:%d be:%d\n", xfi->depth, xfi->xserver_be);

right after the following line:

xfi->xserver_be = (ImageByteOrder(xfi->display) == MSBFirst);

from freerdp-old.

Well, if I'm not mistaken, this print already exists. You can find it in the first line of the logs.

from freerdp-old.

@Beloni: you're right about the debug output, I thought I had added it myself only locally

did you try xfi->clrconv->invert = 1?

from freerdp-old.

Yes I did. But the results are the same. See the logs: http://sourceforge.net/mailarchive/forum.php?thread_name=378717.75098.qm%40web39404.mail.mud.yahoo.com&forum_name=freerdp-devel

from freerdp-old.

I've found something quite interesting: the first line of the log tells us that the server depth is 24, but all the colour conversions occur with the source 16 bpp and destination 32 bpp. Could it be the problem?

http://sourceforge.net/mailarchive/forum.php?forum_name=freerdp-devel&max_rows=25&style=nested&viewmonth=201105&viewday=16

from freerdp-old.

Fixed in f5aef3b.

from freerdp-old.

Eh, uninitialized memory... I should have known

from freerdp-old.

heh; since we use in a very memory constraint environment those bugs are more noticiable. Nice that we have got it :-)

from freerdp-old.