General feedback

[benthor]

Hi,

first of all, very nice little tool! I've been playing around with it and it seems to do one thing and do it reasonably well. I still have a few remarks:

• It works very well in firefox, feel free to update the readme accordingly :)
• there seems to be some kind of go-routine leak. When I first start srvfb, the CPU utilization is 0. This jumps to around 50% once an http client connects. When the screen isn't updating, the utilization drops down to around 20% and stays there, even if the client closes the connection. Opening a new connection has the CPU utilization spike to 60% and then drop down to between 30 and 40% after the client closes etc. Only after a certain timeout, the cpu utilization drops back down to 0. (After the log reports writes to broken pipes.)
• some frames are still sent redundant. Here is how I know: In firefox, when accessing /video directly, I can watch individual frames being rendered. The last frame following some screen change is always rendered and transmitted twice.

[Merovius]

Thanks for the feedback :)

It is to be expected that there is some background CPU usage even if the screen doesn't update. The reason is that as of now, we poll the screen content ever 500ms to see if it has changed. There are some ideas how to change that, but I'm not sure it's possible to do it reliably without polling. For example, we could listen for input-events - but then, if the screen ever updates without input (there are some obvious cases, like going to sleep, or the wifi-settings screen), it wouldn't be detected. I haven't yet found an API to get notified by actual changes to the framebuffer itself.

Similarly, we only know that a client became unavailable, by trying to send a frame to it - I think. I will have to check this, it's possible that the http server cancels the context in that case?

The duplicate frame, again, is to be expected, unfortunately. See this comment. If you have any idea why this is happening on chrome or how to fix it, I'd be happy to consider changing that :)

I will have a closer look at all of this when I have some time - probably this weekend (I'm travelling right now and am a bit busy with moving). But it might just be infeasible to fix any of this right now.

[pl-semiotics]

Since you mentioned looking for an API to be notified of changes to the framebuffer, you may be interested in the result of some investigation I did recently on that topic. This isn't possible in general, since the linux framebuffer interface doesn't have any damage-tracking capability, but the fact that the reMarkable uses an e-ink screen, where the controller needs to be explicitly notified when to update the screen, means that the information is actually available---in the ioctls on the framebuffer device that notify it to update. There isn't a standard way of getting that information in userspace, but I wrote https://github.com/peter-sa/mxc_epdc_fb_damage to allow access to it. (as a reference application, https://github.com/peter-sa/rM-vnc-server uses this information for efficient screen streaming over RFB/VNC).