All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lubomir Rintel <lkundrak@v3.sk>
To: "Noralf Trønnes" <noralf@tronnes.org>
Cc: linux-usb@vger.kernel.org, sam@ravnborg.org,
	dri-devel@lists.freedesktop.org, balbi@kernel.org,
	Lubomir Rintel <lkundrak@v3.sk>
Subject: Re: [PATCH v3 0/6] Generic USB Display driver
Date: Thu,  9 Jul 2020 18:32:35 +0200	[thread overview]
Message-ID: <20200709163235.360054-1-lkundrak@v3.sk> (raw)
In-Reply-To: <20200529175643.46094-1-noralf@tronnes.org>

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

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

WARNING: multiple messages have this Message-ID (diff)
From: Lubomir Rintel <lkundrak@v3.sk>
To: "Noralf Trønnes" <noralf@tronnes.org>
Cc: balbi@kernel.org, linux-usb@vger.kernel.org, sam@ravnborg.org,
	dri-devel@lists.freedesktop.org, Lubomir Rintel <lkundrak@v3.sk>
Subject: Re: [PATCH v3 0/6] Generic USB Display driver
Date: Thu,  9 Jul 2020 18:32:35 +0200	[thread overview]
Message-ID: <20200709163235.360054-1-lkundrak@v3.sk> (raw)
In-Reply-To: <20200529175643.46094-1-noralf@tronnes.org>

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

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

  parent reply	other threads:[~2020-07-09 16:33 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-29 17:56 [PATCH v3 0/6] Generic USB Display driver Noralf Trønnes
2020-05-29 17:56 ` Noralf Trønnes
2020-05-29 17:56 ` [PATCH v3 1/6] drm/client: Add drm_client_init_from_id() Noralf Trønnes
2020-05-29 17:56   ` Noralf Trønnes
2020-05-29 17:56 ` [PATCH v3 2/6] drm/client: Add drm_client_modeset_disable() Noralf Trønnes
2020-05-29 17:56   ` Noralf Trønnes
2020-05-29 17:56 ` [PATCH v3 3/6] drm/client: Add a way to set modeset, properties and rotation Noralf Trønnes
2020-05-29 17:56   ` Noralf Trønnes
2020-05-29 17:56 ` [PATCH v3 4/6] drm: Add Generic USB Display driver Noralf Trønnes
2020-05-29 17:56   ` Noralf Trønnes
2020-05-29 22:45   ` Peter Stuge
2020-05-29 22:45     ` Peter Stuge
2020-06-01 16:57     ` Noralf Trønnes
2020-06-01 16:57       ` Noralf Trønnes
2020-06-02  0:12       ` Peter Stuge
2020-06-02  0:12         ` Peter Stuge
2020-06-02  2:32         ` Alan Stern
2020-06-02  2:32           ` Alan Stern
2020-06-02  5:21           ` Peter Stuge
2020-06-02  5:21             ` Peter Stuge
2020-06-02 15:27             ` Alan Stern
2020-06-02 15:27               ` Alan Stern
2020-06-02 18:38               ` Peter Stuge
2020-06-02 18:38                 ` Peter Stuge
2020-06-05 12:03                 ` Noralf Trønnes
2020-06-05 12:03                   ` Noralf Trønnes
2020-06-02 11:46           ` Noralf Trønnes
2020-06-02 11:46             ` Noralf Trønnes
2020-07-14 15:30             ` Noralf Trønnes
2020-07-14 15:30               ` Noralf Trønnes
2020-06-03 19:17         ` Noralf Trønnes
2020-06-03 19:17           ` Noralf Trønnes
2020-05-29 17:56 ` [PATCH v3 5/6] drm/gud: Add functionality for the USB gadget side Noralf Trønnes
2020-05-29 17:56   ` Noralf Trønnes
2020-05-29 17:56 ` [PATCH v3 6/6] usb: gadget: function: Add Generic USB Display support Noralf Trønnes
2020-05-29 17:56   ` Noralf Trønnes
2020-06-02 17:05   ` Felipe Balbi
2020-06-02 17:05     ` Felipe Balbi
2020-06-02 19:14     ` Noralf Trønnes
2020-06-02 19:14       ` Noralf Trønnes
2020-06-03  7:10       ` Felipe Balbi
2020-06-03  7:10         ` Felipe Balbi
2020-07-09 16:32 ` Lubomir Rintel [this message]
2020-07-09 16:32   ` [PATCH v3 0/6] Generic USB Display driver Lubomir Rintel
2020-07-14 13:33   ` Noralf Trønnes
2020-07-14 13:33     ` Noralf Trønnes
2020-07-14 17:40     ` Peter Stuge
2020-07-14 17:40       ` Peter Stuge
2020-07-14 19:03       ` Noralf Trønnes
2020-07-14 19:03         ` Noralf Trønnes
2020-07-14 19:38         ` Peter Stuge
2020-07-14 19:38           ` Peter Stuge
2020-07-16 17:43           ` Noralf Trønnes
2020-07-16 17:43             ` Noralf Trønnes
2020-07-15  7:30         ` Lubomir Rintel
2020-07-15  7:30           ` Lubomir Rintel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200709163235.360054-1-lkundrak@v3.sk \
    --to=lkundrak@v3.sk \
    --cc=balbi@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=noralf@tronnes.org \
    --cc=sam@ravnborg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.