Re: [PATCH v3 0/6] Generic USB Display driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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].

[1] https://assets.octodon.social/media_attachments/files/009/983/960/original/64ad8ea46c1b06c5.jpg

I suppose you can add:

Tested-by: Lubomir Rintel <lkundrak@xxxxx>

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.

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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux