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