Display driver viewable via HTTP
hansmi opened this issue · 1 comments
What kind of new feature are you looking for?
In the interest of simplifying development on a host machine I implemented a display.Drawer
which is also an HTTP request handler. All client requests get an initial snapshot of the graphics buffer and are updated further on every change.
The protocol used is "MJPEG" (multipart/x-mixed-replace
with images) which is often also used by IP cameras. Because of its better suitability for computer-drawn graphics the PNG image format is used by default, but JPEG can be selected as a default or using a URL parameter.
The only dependencies are the standard library and periph.io/display.
A snapshot of the source code is available at https://github.com/hansmi/periph-webdisplay with an example clock implementation at https://github.com/hansmi/periph-webdisplay/tree/main/example/clock. Go documentation is at https://pkg.go.dev/github.com/hansmi/periph-webdisplay (still a bit underpolished). Unit tests ensure that everything works.
I think such a driver would be useful to have in periph.io itself. I'm filing this feature request to see whether there's interest for opening a pull request and to discuss a few things before I finalize the documentation and API.
If a target device has a network interface (e.g. a Raspberry Pi), the proposed driver can also be used to access the display content remotely. I intend to write another driver combining multiple displays into one interface, distributing updates to all.
Questions:
I'm currently naming the driver webdisplay
. Does anyone have a better name in mind?
Is github.com/periph/devices
the most suitable repository?
Do you plan to:
- Contribute an initial driver: Yes
- Write unit tests: Yes
- Update https://github.com/periph/cmd to use the new functionality: The driver is not very useful on its own, but I could be convinced otherwise.
Yes github.com/periph/devices for the generic implementation and github.com/periph/cmd for an executable sounds good. Thanks!
If I were to implement it personally, I would probably name it something like "VideoSink" or the "VideoServing" but I don't have a strong opinion.