Hey Ondrej, On 05/23/2016 11:51 AM, Ondrej Holy wrote: > Hi Armin, > > 2016-05-19 9:18 GMT+02:00 Armin Novak <armin.no...@thincast.com > <mailto:armin.no...@thincast.com>>: > > Hey Ondrej, > > sorry for the late reply, did indeed missed to reply. > > > neverminds, thanks for the replay. > > > Most of the code works on a big endian, because > > Stream_Read_/Stream_Write_ macros are used to read/write data > from/to > > server. There is a problem if Stream_Pointer is used to read raw > data, > > because the data are always stored as little endian. It is problem > > especially with wide strings and colors. It seems to me that > usage of > > something like Stream_Read_Bitmap/Stream_Read_String would be > > suboptimal, because it requires additional data processing, but > maybe > > this is the only right way to do it. > Wide String read / write is using internal conversion to UTF-8, so the > use of raw data should not be to big an issue there. For color > conversion stuff the data layout for data from RDP is fixed in the > spec, > so the layout will not change there. Converting bitmaps from local to > RDP is a different beast though, one I still try to fix properly. > > > Did not know that this is fixed in the documentation, thanks for > notice, have to take a look... It is a bit spread through the different documents but so far I could not find anything that did not have a fixed byte order. The only real variable here are bitmaps directly send in GDI mode, everything else is already compressed and needs to be decoded anyway.
> > > > Some of the color conversions access the data byte per byte, some of > > them access them as UINT16, or UINT32 currently. This is obviously a > > problem for a big endian. It seems that your patches fixes this > > > Ok, then the following code from xf_client.c is totally wrong... > xfc->invert = (ImageByteOrder(xfc->display) == MSBFirst) ? TRUE : FALSE; > ... > xfc->format = (xfc->invert) ? PIXEL_FORMAT_RGBA32 : PIXEL_FORMAT_BGRA32; > > and something like FREERDP_PIXEL_FORMAT_ENDIANNESS should be added > instead, what do you think about it? > This looks more like a client issue to determine the actual framebuffer layout of the backend and not something libfreerdp can handle. I'd like to keep X11/Wayland/Win/Mac/Android/... stuff out of the core library. The man page of ImageByteOrder is hard to understand without context though :/ As for using fixed byte order, remember X11 has network transparency, so the stuff actually displaying might have a different endianess than the one running xfreerdp. > -- > Regards > > Ondrej Regards Armin ------------------------------------------------------------------------------ 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
