[PATCH v4 0/3] Generic USB Display driver

[Noralf Trønnes]

Den 24.01.2021 21.51, skrev Noralf Trønnes:
> 
> 
> Den 24.01.2021 19.38, skrev Lubomir Rintel:
>> On Wed, Jan 20, 2021 at 06:00:30PM +0100, Noralf Trønnes wrote:
>>> Hi,
>>>
>>> A while back I had the idea to turn a Raspberry Pi Zero into a $5
>>> USB to HDMI/SDTV/DSI/DPI display adapter.
>>>
>>> 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.
>>>
>>> Unfortunately I've had some compounding health problems that have
>>> severally limited the time I can spend in front of a computer. For this
>>> reason I've decided to keep the gadget driver out-of-tree and focus on
>>> getting the host driver merged first.
>>>
>>> See the wiki[1] for more information and images for the Raspberry Pi
>>> Zero/4.
>>>
>>> One big change this time is that I've followed Peter Stuge's advice to
>>> not let DRM stuff leak into the USB protocol. This has made the protocol
>>> easier to understand just from reading the header file.
>>>
>>> Noralf.
>>>
>>> [1] https://github.com/notro/gud/wiki
>>
>> The patch set:
>>
>> Tested-by: Lubomir Rintel <lkundrak at v3.sk>
>>
>> Works like a charm with this board [1], though it didn't impress the girls
>> as much as I hoped. Code here [2], picture here [3].
>>
> 
> I have wondered what color display resolution it is possible to drive
> over USB full speed. I can understand that your PoC wasn't that
> impressive since it doesn't use DMA to drive the SPI bus.
> 

I have now done a Raspberry Pi Pico implementation and driving SPI using
DMA was just marginally faster than letting the CPU fill the FIFO. Maybe
I shouldn't be so suprised since the CPU has nothing else to do, but
even so I didn't expect this. But then again I have very little
experience with microcontrollers.

I have the same size display[1] as you 240x135 and my display was quite
snappy (using X windows!), I even added lz4 decompression support. I
haven't done much testing so I can't say how much the actual improvement
is with the compression. The USB double buffering I was hoping for
didn't pan out, the bulk endpoint can only do 64 byte packest (ISO is
512), so I ended up storing the packets and then push the frame in its
entirety to the display. The Pico has 264kB of ram so I can afford to
have a framebuffer and a decompression buffer for this tiny display. My
target display is 320x240 and that means I can't use 2 buffers, so not
sure how that goes.

[1] https://shop.pimoroni.com/products/pico-display-pack

Noralf.

> The new $4 Raspberry Pi Pico that came out this week looks interesting
> as a USB interface board for tiny panels. It can drive DPI panels
> directly, has 2 cores @133MHz, 264K SRAM and USB full speed. Maybe lz4
> decompression is even possible. Another good thing is that the board
> will be around for a long time.
> 
> Thanks for testing, I have limited bandwith these days so I couldn't do
> a test on an MCU myself.
> 
> Noralf.
> 
>> [1] https://www.banggood.com/LILYGO-TTGO-T-Display-GD32-RISC-V-32-bit-Core-Minimal-Development-Board-1_14-IPS-p-1652870.html?rmmds=search&cur_warehouse=CN
>> [2] https://github.com/hackerspace/libopencm3-gf32v-examples/commit/7ef51b31b9
>> [3] https://people.freedesktop.org/~lkundrak/lilygo.jpeg
>>
>> Had to apply a fix for the drm_connector_enum_list[] ommission I mentioned
>> elsewhere, and that I've now noticed you've noted previously.
>>
>> Take care
>> Lubo
>>