JorgeGzm opened a new pull request, #19911:
URL: https://github.com/apache/nuttx/pull/19911
## Summary
Serve the display a board already has, over VNC, without giving up the panel.
NuttX has a VNC server in `drivers/video/vnc`, and it allocates a framebuffer
of its own to register a second, virtual display. That is the right answer
for
a board with no display; it is not the one for a board whose panel is
already
showing something and which also needs to be reached from a desk. These
commits add what that case needs, and the userspace server that uses it is in
the companion nuttx-apps PR.
- `video/fb`: dirty areas reported to userspace. A ring per open file fed
by
the same `FBIO_UPDATE` funnel every framebuffer user already goes through,
drained with `FBIOC_GETDIRTY` and signalled by `POLLPRI`. Generic video
infrastructure -- a screen recorder or a test harness comparing renders
wants
the same thing -- and it costs nothing when nobody is watching.
- `video/vfb`: a framebuffer that is memory and nothing else, registered as
`/dev/fbN` with the geometry the configuration asks for. A board with no
display runs the same graphics stack as one with a panel, and the pixels
are
available to any consumer rather than to one server.
- `video/rfb`: declare `RFB_ENCODING_TRLE`. Hextile and ZRLE were declared;
the standard encoding between them was not.
- `stm32h7/ethernet`: a reply built in the RX path was transmitted without
checking that the head TX descriptor had been returned by the DMA, so a
busy
link could overwrite a frame in flight -- corruption, or a panic from the
RX
work queue with assertions on. The predicate is the one the driver already
applies before every other transmission; the RX reply path was the one
that
skipped it. A second commit adds an opt-in way to restrict autonegotiation
to 10BASE-T full duplex, for boards where another subsystem couples noise
into the PHY.
- `boards`: four configurations, two per board, the board changes they need,
and the documentation for all of it -- the board pages, and
`applications/system/fbvnc` for the command itself, alongside the existing
`vncviewer` page.
The linum also gets an MPU region so its external SDRAM is cacheable:
0xc0000000 is External Device in the Cortex-M7 default map, and nothing
said
otherwise, so a framebuffer there was read and written with no cache in
front of it.
## Impact
New features, all opt-in. `CONFIG_VIDEO_VFB` and the `FBIOC_*` ioctls are
new
and default off; `drivers/video/vnc` is untouched and keeps working as it
does today.
The Ethernet TX-ring commit changes behaviour for every STM32H7 board using
`stm32_ethernet.c`: a reply that cannot be sent because the ring is full is
now dropped rather than written over a frame the DMA still owns. The reply
to
received data is almost always an acknowledgement and the peer retransmits;
overwriting a frame in flight recovers from nothing.
`CONFIG_STM32_AUTONEG_10FD_ONLY` defaults off and changes nothing unless a
board asks for it.
The MPU region and the four configurations are board-local.
## Testing
Hardware, not simulation:
- **linum-stm32h753bi** (STM32H7, LTDC 1024x600, Ethernet): `vnc` mirrors
the
panel while it keeps working; `vncfb` serves 1024x600 with the LTDC left
out
of the build entirely.
- **esp32s3-m5-cardputer** (Xtensa, ST7789 240x135, Wi-Fi): `lvglvnc`
mirrors
the panel, `vncfb` serves 160x120 with the panel out of the build.
Both boards run the stock `lvgldemo` and `lvglterm`; pointer and keyboard
from
the viewer reach them through the uinput devices. A framebuffer application
that is not LVGL and never reports an update (nxdoom) was also served, which
is
what the companion PR's `--diff` mode exists for.
Measured on the linum, comparing one 800x480 frame against the last: 421 ms
with the SDRAM as Device memory, 45 ms as Normal cacheable.
All four configurations build. `tools/nxstyle` is clean on every file
touched.
**Known issue, not from this work:** `esp32s3-m5-cardputer` cannot associate
to Wi-Fi on current master. Bisected to `a1b9bedbe4` ("reconnect Wi-Fi STA
on
AP-side disconnect"): same binary and same procedure, reverting it
associates
and keeping it does not. The Cardputer configurations here were validated
with
that revert applied locally; they build either way. Reported separately.
Depends-On: https://github.com/apache/nuttx-apps/pull/3739
--
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]
