JorgeGzm commented on PR #19911:
URL: https://github.com/apache/nuttx/pull/19911#issuecomment-5378111297
> > > @JorgeGzm why not chain Vinc (user space->upperhalf->vnc
lowerhalf->stm lowerfhalf?
> >
> >
> > That is what this does, one level up: fb_updatearea already sees
everything the stm lower half is given.
> > A vnc lower half would put the socket back in a kernel thread: 150 KB/s
against 2300 KB/s, measured. linum:vnc here is your case already, real LTDC
panel mirrored over VNC with the panel driver untouched.
>
> but why not fix the kernel implementation to improve the performance
directly? I don't see any technology reason make the kernel performance lower
than userspace implementation.
That was @acassis initial request too, so we tried it first: mirror mode was
implemented inside drivers/video/vnc and worked, but was abandoned for being
about 70% slower sending the same rectangles.
The cause we hit was in the send path. With the server's socket in a kernel
thread, enabling CONFIG_NET_TCP_WRITE_BUFFERS asserted in iob_clone_partial, so
we ran it without write buffering and sending became stop-and-wait: 123-187
KB/s measured, against 1017 KB/s from user space on the same board and link.
We never root-caused that assert, and I am not claiming it is a design
limit. If it is a bug worth fixing, that is a change in net/.
Two structural points on top of that:
- The server allocates its own framebuffer and registers it as /dev/fbN.
There is no interface for serving a framebuffer that already exists, which is
what this PR is for.
- The pixel format is chosen at compile time (CONFIG_VNCSERVER_COLORFMT_*),
so the server cannot honour the
SetPixelFormat a client sends at run time.
The driver is used by four configurations, all SAMv7 or sim. We have none of
that hardware, so reworking its threading model without being able to validate
it on a board would be risky.
--
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]
