Den 09.07.2020 18.32, skrev Lubomir Rintel:
Hello,
On 29 May 2020 Noralf Trønnes wrote: ...
This series adds a USB host driver and a device/gadget driver to achieve that.
The reason for calling it 'Generic' is so anyone can make a USB display/adapter against this driver, all that's needed is to add a USB vid:pid. I have done a microcontroller implementation hack just to see how that would work out[1] (which unconvered a couple of bugs in the host driver).
...
This is actually very cool; finally a good way to drive the cheapo SPI/I2C displays from computers whose only means of expansion is USB with a little help from a microcontroller. I've actually had some success doing just that [1].
Nice to see a monochrome implementation, I actually planned to remove the R1 format from v3 since the gadget driver doesn't implement it. Having unused (and poorly tested) code isn't that great, but I forgot. It turns out it was a good thing that I forgot that :-)
[1] https://assets.octodon.social/media_attachments/files/009/983/960/original/6...
I suppose you can add:
Tested-by: Lubomir Rintel lkundrak@v3.sk
I've had to jump through some hoops though.
My OLED display is a 128x64 SSD1306 [1] driven from the SPI bus. The frame buffer SRAM is normally scanned out in stripes of 8 vertical pixels called "pages". When the display is turned on its side, with "vertical addressing mode" and "segment remapping" enabled and bytes being sent LSB first, it appears linear -- it's easy to repaint the whole display from what is now the top left corner to the bottom right. This is very convenient for painting pixels as they come, without bufferring them or doing any conversions (assuming that memory and cpu cycles are at premium on MCUs).
[1] https://cdn-shop.adafruit.com/datasheets/SSD1306.pdf
There doesn't seem a comfortable way to do partial redraws though. Would you find it objectionable if the device could indicate that needs full frames instead of just the damaged areas? Perhaps then the driver wouldn't even need to bother issuing GUD_DRM_USB_REQ_SET_BUFFER to displays dumb enough to be incapable of partial redraws and decompression.
Yeah I figured always having full updates might benefit/simplify monochrome devices, but I'd wait for an actual device needing it before adding it. Now that you need it, I'll add a flag for it in the next version.
I would like to keep the SET_BUFFER request since it will serve as a syncing point between the host and the device. I'm no USB expert but I assume that a bulk transfer can fail halfway through and result in the next update starting where the previous one failed and thus writing beyond the end of the display buffer.
Noralf.
My work-in-progress code that works on STM32F103 (e.g. "Blue Pill" boards), or GD32VF103 (RISC-V "Polos Alef") is at [2]. The partial redraws that don't start from column zero or are not "page aligned" don't work correctly for the time being; X11 doesn't seem to care.
[2] https://github.com/hackerspace/libopencm3-gf32v-examples/tree/lr/gd32v/examp...
Thank you! Lubo