Hi Armin, 2016-05-23 14:38 GMT+02:00 Armin Novak <armin.no...@thincast.com>:
> Hey Ondrej, > > On 05/23/2016 02:00 PM, Ondrej Holy wrote: > > > > The problem is that freerdp_image_copy can't return bitmap in such > > format, which is needed by X11 under big endian. Bitmaps are received > > in little endian order, but needs to be written in the big endian > > order in certain cases. It seems that color overhaul fixes lot of > > problems for big endian, but the final bitmap is still with little > > endian order. Yea, ImageByteOrder and all X11 documentation is a bit > > mess, but according to my testing it depends on where the X11 server > > is running. ImageByteOrder is LSBFirst in case of SSH X11 forwarding > > from big endian machine to little endian machine (because it uses > > server from the little endian machine), and MSBFirst in case of VNC > > from big endian machine (because VNC is transfering just image from > > big endian X11 server). The X11 requires bitmaps in RGBA regardless of > > LSBFirst/MSBFirst, however it expects little endian order for LSBFirst > > and big endian order for MSBFirst. So the color needs to be written by > > Data_Write_UINT32 for LSBFirst and Data_Write_UINT32_BE for MSBFirst. > > I expect that your color overhaul fixes color for the SSH X11 > > forwarding case, because you manipulate with bitmaps byte per byte, > > which is equal to Data_Write_UINT32... but it segfaulted for me (even > > on little endian) as per the another thread, so I can't prove it. > > > > As far as I know also MacOS runs on big endian by default. It seems > > mfreerdp solves this problem by kCGBitmapByteOrder32Little, so it uses > > bitmaps in little endian order, but I can't find any alternative for > > X11. Bytes in the whole bitmap needs to be swapped directly in the X11 > > client if you think that this should not be in the core library, so > > something like the following code from cairo: > > https://cgit.freedesktop.org/cairo/tree/src/cairo-xlib-surface.c#n531 > > > Ah, ok that is your issue. > Looks like this should be no issue at all if my changes are complete. > The new color conversion pipe would be like this: > RDP color format -> intermediate buffer (in destination format) -> > output buffer (in destination format) > So the only thing the client must take care of is determining the > correct destination format (that is RGBA, BGRA, ARGB, ...) and hacks > like kCGBitmapByteOrder32Little can be eliminated. > I am still not sure we understand each other. The problem is that the destination format does not exists in color.h for xfreerdp on big endian for some bpp. Please see the following image: http://www.qnx.com/developers/docs/6.4.0/ddk_en/graphics/images/byte_order.gif The "reversed" color formats on the mentioned image are what is needed on big endian. So for 32bpp it works nicely, because RGBA on big endian is the same as ARGB on little endian: ARGB888 = PIXEL_FORMAT_A8R8G8B8 reversed ARGB888 = PIXEL_FORMAT_B8G8R8A The problem is e.g. with 16bpp, because BGR on big endian is not the same as RGB on little endian: RGB565 = PIXEL_FORMAT_R5G6B5 reversed RGB565 = ??? The reversed RGB565 is something like PIXEL_FORMAT_G3B5R5G3. Do you intend to introduce also such formats? I doubt about a bit... -- Regards Ondrej ------------------------------------------------------------------------------ Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j _______________________________________________ FreeRDP-devel mailing list FreeRDP-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel
