Re: [gtk-vnc-devel] [PATCH] Fix little to big endian conversion



Em Qua, 2008-02-06 às 19:41 -0600, Anthony Liguori escreveu:
> Jonh Wendell wrote:
> > Em Qua, 2008-02-06 às 18:37 -0600, Anthony Liguori escreveu:
> >   
> >> Hiroyuki Kaguchi wrote:
> >>     
> >>> When the endian between VNC server and X server is different, the displayed color is abnormal.
> >>> This is because the endian conversion of the pixel data is not done .
> >>>
> >>> X server that uses big endian cannot be used.
> >>> The reason is that most Linux vncserver sends data by little endian.
> >>>
> >>> Of course, Fedora8(Linux) and Windows(Xming) works fine, since it uses
> >>> little endian for X protocol.
> >>>
> >>> This patch applies follows:
> >>> (a)The endian conversion function is called by the SET_PIXEL function.
> >>> (b)It is checked whether there is difference in endian between X server and VNC Server.
> >>> (c)The byte_order variable is added to the gvnc_framebuffer structure.
> >>>
> >>> Sign-off-by: Hiroyuki Kaguchi <fj7025cf aa jp fujitsu com>
> >>>
> >>>   
> >>>       
> >> Thanks. Applied.
> >>
> >> Regards,
> >>
> >> Anthony Liguori
> >>
> >>     
> >
> > I think this patch broke thinks here. See the screenshot attached,
> > please.
> >   
> 
> What's the server?  Can you provide the debug output from gvncviewer 
> (I'm specifically interested in what encodings are being used and what 
> the pixel format is).
> 
> I tested the patch before applying and it seemed to work with TightVNC 
> using the Tight encoding.
> 
> Regards,
> 
> Anthony Liguori

The server is UltraVNC, windows.
The debug output is attached.

Thanks,
-- 
Jonh Wendell
www.bani.com.br

> 
wendell wendell-laptop:~/sistemas/gnome/gtk-vnc$ vinagre
Expose 0x0 @ 1,1
Started background coroutine
Resolving host 200.164.86.227 20191
Trying socket 14
Protocol initialization
Negotiated protocol 3 3
Possible auth 2
Requested auth type 2
Waiting for auth type
Choose auth 2
Requesting missing credentials
Set password credential
Waiting for missing credentials
Got all credentials
Do Challenge
Checking auth result
Success
Pixel format BPP: 16,  Depth: 16, Byte order: 1234, True color: 1
             Mask  red:  31, green:  63, blue:  31
             Shift red:  11, green:   5, blue:   0
Display name 'mac_cpd_wendell ( 200.100.100.191 )'
Mask local: 255 255 255
    remote:  31  63  31
    merged:  31  63  31
Pixel shifts
   right:  11   5   0
    left:  16   8   0
Running main loop
Expose 0x0 @ 800,591
FramebufferUpdate(7, 0, 0, 800, 81)
FramebufferUpdate(7, 0, 81, 800, 81)
FramebufferUpdate(7, 0, 162, 800, 81)
FramebufferUpdate(7, 0, 243, 800, 81)
FramebufferUpdate(7, 0, 324, 800, 81)
FramebufferUpdate(7, 0, 405, 800, 81)
FramebufferUpdate(7, 0, 486, 800, 81)
FramebufferUpdate(7, 0, 567, 800, 33)
Expose 0x0 @ 800,591
FramebufferUpdate(-240, 10, 10, 32, 32)
FramebufferUpdate(7, 0, 0, 800, 81)
Expose 10x10 @ 32,32
FramebufferUpdate(7, 0, 81, 800, 81)
FramebufferUpdate(7, 0, 162, 800, 81)
FramebufferUpdate(7, 0, 243, 800, 81)
Expose 0x0 @ 800,243
FramebufferUpdate(7, 0, 324, 800, 81)
Expose 0x243 @ 800,81
FramebufferUpdate(7, 0, 405, 800, 81)
Expose 0x324 @ 800,81
FramebufferUpdate(7, 0, 486, 800, 81)
FramebufferUpdate(7, 0, 567, 800, 33)
Expose 0x405 @ 800,186
FramebufferUpdate(-240, 10, 10, 32, 32)
FramebufferUpdate(-240, 10, 10, 32, 32)
Expose 10x10 @ 32,32
FramebufferUpdate(7, 796, 20, 4, 6)
FramebufferUpdate(7, 796, 27, 4, 7)
FramebufferUpdate(7, 796, 35, 4, 7)
Expose 796x20 @ 4,22
FramebufferUpdate(7, 796, 26, 4, 8)
Expose 796x26 @ 4,8
Expose 0x0 @ 800,591
Expose 0x188 @ 647,403
Expose 0x230 @ 609,361
Expose 0x294 @ 549,297
Expose 0x392 @ 459,199
Expose 0x434 @ 421,157
Expose 16x527 @ 319,64
FramebufferUpdate(7, 0, 256, 128, 64)
Expose 0x256 @ 128,64
FramebufferUpdate(7, 0, 256, 128, 64)
Expose 0x256 @ 128,64
FramebufferUpdate(7, 192, 320, 128, 64)
Expose 192x320 @ 128,64
FramebufferUpdate(7, 192, 320, 128, 64)
Expose 192x320 @ 128,64
FramebufferUpdate(7, 192, 320, 128, 64)
Expose 192x320 @ 128,64
Expose 0x0 @ 800,591
FramebufferUpdate(7, 192, 320, 128, 64)
Expose 192x320 @ 128,64
FramebufferUpdate(7, 192, 320, 128, 64)
Expose 192x320 @ 128,64
FramebufferUpdate(7, 756, 578, 40, 18)
Expose 756x578 @ 40,13
FramebufferUpdate(7, 192, 320, 128, 64)
Expose 192x320 @ 128,64
FramebufferUpdate(7, 2, 78, 380, 3)
FramebufferUpdate(7, 2, 81, 383, 40)
FramebufferUpdate(7, 2, 121, 3, 1)
FramebufferUpdate(7, 2, 122, 3, 3)
FramebufferUpdate(7, 378, 122, 4, 3)
FramebufferUpdate(7, 2, 125, 3, 384)
FramebufferUpdate(7, 8, 125, 183, 358)
Expose 2x78 @ 383,431
FramebufferUpdate(7, 8, 483, 183, 26)
FramebufferUpdate(7, 378, 125, 4, 384)
FramebufferUpdate(7, 2, 509, 3, 63)
FramebufferUpdate(7, 378, 509, 4, 63)
FramebufferUpdate(7, 0, 572, 384, 28)
Expose 0x125 @ 384,466
FramebufferUpdate(7, 2, 81, 383, 64)
FramebufferUpdate(7, 2, 145, 64, 320)
Expose 2x81 @ 383,64
FramebufferUpdate(7, 130, 145, 255, 257)
Expose 2x145 @ 64,320
FramebufferUpdate(7, 130, 402, 255, 63)
FramebufferUpdate(7, 2, 465, 383, 107)
FramebufferUpdate(7, 0, 572, 64, 28)
Expose 0x145 @ 385,446
FramebufferUpdate(7, 194, 398, 64, 64)
FramebufferUpdate(7, 258, 526, 64, 49)
Expose 194x398 @ 128,177
FramebufferUpdate(7, 194, 526, 64, 50)
Expose 194x526 @ 64,50
Expose 0x0 @ 800,591
The program 'vinagre' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
  (Details: serial 12619 error_code 9 request_code 145 minor_code 9)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]