JorgeGzm opened a new pull request, #3739:
URL: https://github.com/apache/nuttx-apps/pull/3739
## Summary
A VNC server for a framebuffer someone else owns, and the service that runs
it.
`drivers/video/vnc` in nuttx allocates a framebuffer and registers a second,
virtual display. This one does the opposite: the caller hands it geometry
and
a snapshot callback, and it serves whatever that callback points at -- so the
panel a board is already driving can be mirrored without a duplicate copy,
and
the application drawing on it needs to know nothing about VNC.
- `netutils/fbvnc`: the RFB 3.7 protocol library. TRLE, Hextile and Raw,
all
of the codec here -- no zlib, no jpeg. Pointer, key and disconnect events
come back through callbacks.
- `system/fbvnc`: the service. `fbvnc start [/dev/fbN] [--diff|--full]`,
`stop`, `status`. It mirrors `/dev/fbN` with no cooperation from the
application: what changed comes from the kernel's dirty-area reporting,
and
for an application that draws without reporting anything, `--diff` compares
against a shadow frame. Remote input is delivered through the uinput touch
and keyboard devices, so it enters the system the way a finger or a key
would.
- `examples/lvgldemo`: an optional second pointer device, so a demo can take
the panel's touchscreen and a remote pointer at the same time.
**Depends on the companion nuttx PR** for `RFB_ENCODING_TRLE`,
`FBIOC_GETDIRTY`
and `FBIOC_WATCHAREA`.
## Why not extend drivers/video/vnc
We tried. An earlier version of this work added a mirror mode *inside* that
driver; it worked, and we abandoned it because it was ~70% slower sending
exactly the same rectangles. Three reasons, all measured on the same board:
1. **It owns the framebuffer.** `vnc_fbinitialize()` allocates a buffer and
registers `/dev/fbN`. There is no interface for serving a framebuffer
that
already exists, which is what a board with a panel has.
2. **It runs in the kernel, where the network path is limited.**
`TCP_WRITE_BUFFERS` cannot be used with a socket in a kernel thread -- it
asserts in `iob_clone_partial`. Without write buffering the send is
stop-and-wait: **~150 KB/s against ~2300 KB/s** on the same hardware.
That
is a property of where it runs, not something to fix in that file.
3. **It serves 16 bpp only** (`vnc_hextile.c:273`). RealVNC in its default
automatic-colour mode asks for 8 bpp, is answered in 16, and decodes
noise.
The two complement each other: that one *creates* a screen for a board
without
a display; this one *serves* the screen a board already has, for any
application.
**On the name:** `fbvnc` avoids colliding with `CONFIG_VNCSERVER` and with
the
`system/vncviewer` client, and says what distinguishes it -- VNC for a
framebuffer that already exists. We are happy to change it if the community
prefers something else; the change is mechanical.
## Impact
New code, opt-in, nothing existing is touched. `drivers/video/vnc` and
`system/vncviewer` are untouched. `examples/lvgldemo` gains one option that
defaults to empty, which leaves its behaviour as it is.
## Testing
Hardware, two architectures:
- **linum-stm32h753bi** (STM32H7, LTDC 1024x600, Ethernet): mirror and
virtual-display configurations, running the stock `lvgldemo` and
`lvglterm`.
- **esp32s3-m5-cardputer** (Xtensa, ST7789 240x135, Wi-Fi): the same two
arrangements.
Verified against RealVNC Viewer and against a test client that decodes the
protocol and compares pixels.
- **TRLE is bit-exact.** Decoded output compared against Raw for the same
screen: 0 differing bytes of 1843200 on ARM, 0 of 57600 on Xtensa,
including
rectangles whose width is not a multiple of the tile, which exercise the
bit
padding.
- **Size**, one 1024x600 LVGL screen: 1200 KB raw, 402 KB Hextile, **131 KB
TRLE**; full frame 0.362 s with Hextile, 0.193 s with TRLE.
- **`--diff` refinement**, on an animating chart: 410k pixels and 87 KB per
update without it, 213k and 43 KB with it, and 0 stale pixels after a long
run of incremental updates only.
- 8, 16 and 32 bit true-colour formats negotiated; a colour-map client is
refused with a message rather than answered in the wrong format.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
