[PATCH v3 0/6] Generic USB Display driver

[Noralf Trønnes]

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/64ad8ea46c1b06c5.jpg
> 
> I suppose you can add:
> 
> Tested-by: Lubomir Rintel <lkundrak at 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/examples/gd32v/f103/polos-alef/usb-display
> 
> Thank you!
> Lubo
>