search

zackp30 / fastdroid-vnc

Automatically exported from code.google.com/p/fastdroid-vnc
0 stars 0 forks source link

Server shows distorted image on some devices #2

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Download & install the fastdroid-vnc binary on HTC Desire (Android 2.1) 
according to the official instructions on the project page
2. Start the server through adb
3. Connect to the HTC device using TightVNC viewer. The image is distorted 
(example screen shot attached).

What version of the product are you using? On what operating system?
fastdroid-vnc binary which was released (uploaded) on 1 August 2010, target 
devices HTC Desire and Wildfire are running Android 2.1

Please provide any additional information below.

I have tested the binary on HTC Desire and experienced this issue. I reproduced 
it both with TightVNC viewer as well as T-Plan Robot. The server log is:

Found input device /dev/input/event3 by keyword touch
Initializing framebuffer device /dev/graphics/fb0...
xres=480, yres=800, xresv=480, yresv=1600, xoffs=0, yoffs=0, bpp=32
Initializing keyboard device /dev/input/event2 ...
Initializing touch device /dev/input/event3 ...
Initializing Framebuffer VNC server:
        width:  480
        height: 800
        bpp:    32
        port:   5901
Initializing server...
17/11/2010 13:52:48 Listening for VNC connections on TCP port 5901
17/11/2010 13:53:56 Got connection from client 127.0.0.1
17/11/2010 13:53:56   other clients:
17/11/2010 13:53:56 Client Protocol Version 3.3
17/11/2010 13:53:56 Protocol version sent 3.3, using 3.3
17/11/2010 13:53:56 Using raw encoding for client 127.0.0.1
17/11/2010 13:53:56 Pixel format for client 127.0.0.1:
17/11/2010 13:53:56   32 bpp, depth 24, little endian
17/11/2010 13:53:56   true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0

I also tried the server on HTC Wildfire. To my surprise it worked correctly but 
the log was a bit different:

Found input device /dev/input/event4 by keyword key
Found input device /dev/input/event3 by keyword touch
Initializing framebuffer device /dev/graphics/fb0...
xres=240, yres=320, xresv=240, yresv=640, xoffs=0, yoffs=320, bpp=16
Initializing keyboard device /dev/input/event4 ...
Initializing touch device /dev/input/event3 ...
Initializing Framebuffer VNC server:
    width:  240
    height: 320
    bpp:    16
    port:   5901
Initializing server...
17/11/2010 19:53:16 Listening for VNC connections on TCP port 5901
17/11/2010 19:53:20 Got connection from client 192.168.100.4
17/11/2010 19:53:20   other clients:
17/11/2010 19:53:20 Client Protocol Version 3.3
17/11/2010 19:53:20 Protocol version sent 3.3, using 3.3
17/11/2010 19:53:20 Using raw encoding for client 192.168.100.4
17/11/2010 19:53:20 Pixel format for client 192.168.100.4:
17/11/2010 19:53:20   32 bpp, depth 24, little endian
17/11/2010 19:53:20   true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0

The difference between these two logs (devices) is that the server starts in 
32bpp mode on HTC Desire (and fails to provide the correct desktop image) while 
it starts in 16-bit color depth on HTC Wildfire (and works properly even if the 
client forces the 32-bit mode through the SetPixelFormat message). Setting of 
the client-sent pixel format to 8-bit or 16-bit depth doesn't help - both modes 
work fine on HTC Wildfire and produce the same distorted image on HTC Desire.

The state of the screen image indicates that the 32-bit image data is 
interpreted as 16-bit one or vice versa. This would explain why the image shows 
objects from the screen but the dimensions, colors and update locations are 
incorrect. Please check whether the data transferred through the 
FrameBufferUpdate message is coded correctly. Another option would be to 
provide a CLI option allowing to force the server to a particular initial color 
depth just like other VNC servers.

Original issue reported on code.google.com by robert.p...@gmail.com on 17 Nov 2010 at 7:15

Attachments:

GoogleCodeExporter commented 9 years ago 
I'm showing the same issue here

Original comment by AdamOutl...@gmail.com on 23 Jan 2011 at 11:07

GoogleCodeExporter commented 9 years ago 
 my Nexus 1 has same issue

Original comment by jeaco...@gmail.com on 3 Jun 2011 at 5:03

GoogleCodeExporter commented 9 years ago 
Same issue HTC Evo

Original comment by michael....@gmail.com on 5 Jun 2011 at 10:50

GoogleCodeExporter commented 9 years ago 
Is there any work around? My phone's screen is dead and I wanted to use this to 
get to it while I save up for a new phone.  ddms screen shots work but its a 
pain to use it that way

Original comment by michael....@gmail.com on 5 Jun 2011 at 10:51

GoogleCodeExporter commented 9 years ago 
same issue here on an EMATIC EGL26BL

Original comment by fmunt...@gmail.com on 4 Aug 2013 at 10:32

GoogleCodeExporter commented 9 years ago 
Same issue on Android Car Stereo AN6B01. Tried on all compression types on 
UltraVNC and RealVNC.

Original comment by havra...@gmail.com on 12 Aug 2013 at 2:11

Attachments:

GoogleCodeExporter commented 9 years ago 
Chalk one up for me... Same issue.

Original comment by kowalews...@gmail.com on 8 Feb 2014 at 6:31

GoogleCodeExporter commented 9 years ago 
change follow

/* FIXME: This assumes scrinfo.bits_per_pixel is 32 org:16. */
    vncscr = rfbGetScreen(&argc, argv, scrinfo.xres, scrinfo.yres,
            8, /*5 bits per sample */
            3, /*2 samples per pixel */
            4  /*2 bytes/sample */ );

scrinfo.red.length - 8/*5*/;
...

#define PIXEL_FB_TO_RFB(p,r,g,b) \
    ((p >> r) & 0xff) | \
    (((p >> g) & 0xff) << 8) | \
    (((p >> b) & 0xff) << 16)

Original comment by yyc...@gmail.com on 14 Jun 2014 at 12:17

Attachments: