VNC: Verify RGB8 operation; samv71-xult: VNC configuration now uses RGB8 by defualt

This commit is contained in:
Gregory Nutt 2016-04-22 08:57:42 -06:00
parent e2f17ce7e7
commit 2a928cbdbe
3 changed files with 52 additions and 26 deletions

View File

@ -2320,7 +2320,7 @@ Configuration sub-directories
1. Network configuration: IP address 10.0.0.2. The is easily changed
via 'make menuconfig'. The VNC server address is 10.0.0.2:5900.
2. The default (local) framebuffer configuration is 320x240 with 16-bit
2. The default (local) framebuffer configuration is 320x240 with 8-bit
RGB color.
3. There are complicated interactions between VNC and the network
@ -2339,13 +2339,44 @@ Configuration sub-directories
mouse/keyboard inputs in the options/input menu. That will make
things a little clearer.
5. To select 16-bits per pixel RGB15 5:6:5
CONFIG_NX_DISABLE_8BPP=y
# CONFIG_NX_DISABLE_16BPP is not set
# CONFIG_VNCSERVER_COLORFMT_RGB8 is not set
CONFIG_VNCSERVER_COLORFMT_RGB16=y
CONFIG_EXAMPLES_NXIMAGE_BPP=16
To re-select 8-bits per pixel RGB8 3:3:3
# CONFIG_NX_DISABLE_8BPP is not set
CONFIG_NX_DISABLE_16BPP=y
CONFIG_VNCSERVER_COLORFMT_RGB8=y
# CONFIG_VNCSERVER_COLORFMT_RGB16 is not set
# CONFIG_EXAMPLES_NXIMAGE_GREYSCALE is not set
CONFIG_EXAMPLES_NXIMAGE_BPP=8
STATUS:
2016-04-21: I have gottent he apps/examples/nximage to work
with lots issues with GRAPHICS and UPDATER debug ON. There
are reliability problems and it hangs at the end of the test.
If I turn UPDATE debug off (only), then the display output is
corrupted and I get a hardfault.
2016-04-21: I have gotten the apps/examples/nximage to work with
lots issues with verbose GRAPHICS and UPDATER debug ON. There are
reliability problems and it hangs at the end of the test. But if
I turn UPDATE debug off (only), then the display output is
corrupted. I have also see hardfaults.
Mostly likely, the UPDATER debug output slows the updates and
avoids some kind of race condition with the networking. Oddly,
it does not work at all if I turn off TCP write buffering.
2016-04-22: I added a 100 MS delay at the beginning of the
updater loop and it made no difference. This seems to eliminate
the suspected networking race condition.
The default configuration now uses RGB8 which needs a lot less
SRAM for the local frame buffer and does not the color quality
in the remote display (since it is also 8 BPP). At 8 BPP, the
remote display is correct (although I still do see problems with
hangs).

View File

@ -901,7 +901,6 @@ CONFIG_FS_PROCFS=y
CONFIG_NX=y
CONFIG_NX_NPLANES=1
CONFIG_NX_BGCOLOR=0x0
# CONFIG_NX_ANTIALIASING is not set
# CONFIG_NX_WRITEONLY is not set
CONFIG_NX_UPDATE=y
@ -911,8 +910,8 @@ CONFIG_NX_UPDATE=y
CONFIG_NX_DISABLE_1BPP=y
CONFIG_NX_DISABLE_2BPP=y
CONFIG_NX_DISABLE_4BPP=y
CONFIG_NX_DISABLE_8BPP=y
# CONFIG_NX_DISABLE_16BPP is not set
# CONFIG_NX_DISABLE_8BPP is not set
CONFIG_NX_DISABLE_16BPP=y
CONFIG_NX_DISABLE_24BPP=y
CONFIG_NX_DISABLE_32BPP=y
CONFIG_NX_PACKEDMSFIRST=y
@ -994,8 +993,8 @@ CONFIG_VNCSERVER_PRIO=100
CONFIG_VNCSERVER_STACKSIZE=2048
CONFIG_VNCSERVER_UPDATER_PRIO=100
CONFIG_VNCSERVER_UPDATER_STACKSIZE=2048
# CONFIG_VNCSERVER_COLORFMT_RGB8 is not set
CONFIG_VNCSERVER_COLORFMT_RGB16=y
CONFIG_VNCSERVER_COLORFMT_RGB8=y
# CONFIG_VNCSERVER_COLORFMT_RGB16 is not set
# CONFIG_VNCSERVER_COLORFMT_RGB32 is not set
CONFIG_VNCSERVER_SCREENWIDTH=320
CONFIG_VNCSERVER_SCREENHEIGHT=240
@ -1129,7 +1128,8 @@ CONFIG_EXAMPLES_NSH=y
CONFIG_EXAMPLES_NXIMAGE=y
CONFIG_EXAMPLES_NXIMAGE_VPLANE=0
CONFIG_EXAMPLES_NXIMAGE_DEVNO=0
CONFIG_EXAMPLES_NXIMAGE_BPP=16
CONFIG_EXAMPLES_NXIMAGE_BPP=8
# CONFIG_EXAMPLES_NXIMAGE_GREYSCALE is not set
# CONFIG_EXAMPLES_NXIMAGE_XSCALEp5 is not set
CONFIG_EXAMPLES_NXIMAGE_XSCALE1p0=y
# CONFIG_EXAMPLES_NXIMAGE_XSCALE1p5 is not set

View File

@ -265,9 +265,14 @@ uint32_t vnc_convert_rgb32_888(lfb_color_t rgb)
* Name: vnc_colors
*
* Description:
* Test the update rectangle to see if it contains complex colors. If it
* contains only a few colors, then it may be a candidate for some type
* run-length encoding.
* Test the update rectangle to see if it contains complex colors. If it
* contains only a few colors, then it may be a candidate for some type
* run-length encoding.
*
* REVISIT: This function is imperfect: It will fail if there are more
* than 8 colors in the region. For small colors, we can keep a local
* array for all color formats and always return the exact result, no
* matter now many colors.
*
* Input Parameters:
* session - An instance of the session structure.
@ -280,15 +285,13 @@ uint32_t vnc_convert_rgb32_888(lfb_color_t rgb)
* The number of valid colors in the colors[] array are returned, the
* first entry being the most frequent. A negated errno value is returned
* if the colors cannot be determined. This would be the case if the color
* depth is > 8 and there are more than 'maxcolors' colors in the update
* rectangle.
* there are more than 'maxcolors' colors in the update rectangle.
*
****************************************************************************/
int vnc_colors(FAR struct vnc_session_s *session, FAR struct nxgl_rect_s *rect,
unsigned int maxcolors, FAR lfb_color_t *colors)
{
#if RFB_PIXELDEPTH > 8
FAR const lfb_color_t *rowstart;
FAR const lfb_color_t *pixptr;
lfb_color_t pixel;
@ -412,12 +415,4 @@ int vnc_colors(FAR struct vnc_session_s *session, FAR struct nxgl_rect_s *rect,
/* And return the number of colors that we found */
return ncolors;
#else
/* For small colors, we can keep a local array for all color formats and
* always return the exact result, no matter now many colors. OR we could
* just remove this conditional compilation and live with 8 colors max.
*/
# error No support for small colors
#endif
}