From: "Noralf Trønnes" <noralf@tronnes.org> To: Lubomir Rintel <lkundrak@v3.sk> Cc: hudson@trmm.net, markus@raatikainen.cc, sam@ravnborg.org, linux-usb@vger.kernel.org, dri-devel@lists.freedesktop.org, th020394@gmail.com, pontus.fuchs@gmail.com, peter@stuge.se Subject: Re: [PATCH v4 0/3] Generic USB Display driver Date: Sun, 21 Feb 2021 12:14:53 +0100 [thread overview] Message-ID: <1c182bf1-41d7-49e7-f15e-e8d9ad6386a2@tronnes.org> (raw) In-Reply-To: <70a91ae8-15eb-e8d8-1ed9-923b09106bfa@tronnes.org> 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@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 >>
WARNING: multiple messages have this Message-ID (diff)
From: "Noralf Trønnes" <noralf@tronnes.org> To: Lubomir Rintel <lkundrak@v3.sk> Cc: hudson@trmm.net, markus@raatikainen.cc, peter@stuge.se, linux-usb@vger.kernel.org, dri-devel@lists.freedesktop.org, th020394@gmail.com, pontus.fuchs@gmail.com, sam@ravnborg.org Subject: Re: [PATCH v4 0/3] Generic USB Display driver Date: Sun, 21 Feb 2021 12:14:53 +0100 [thread overview] Message-ID: <1c182bf1-41d7-49e7-f15e-e8d9ad6386a2@tronnes.org> (raw) In-Reply-To: <70a91ae8-15eb-e8d8-1ed9-923b09106bfa@tronnes.org> 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@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 >> _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2021-02-21 11:16 UTC|newest] Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-20 17:00 [PATCH v4 0/3] Generic USB Display driver Noralf Trønnes 2021-01-20 17:00 ` Noralf Trønnes 2021-01-20 17:00 ` [PATCH v4 1/3] drm/uapi: Add USB connector type Noralf Trønnes 2021-01-20 17:00 ` Noralf Trønnes 2021-01-20 17:42 ` Daniel Vetter 2021-01-20 17:42 ` Daniel Vetter 2021-01-21 7:45 ` Thomas Zimmermann 2021-01-21 7:45 ` Thomas Zimmermann 2021-01-21 8:27 ` Daniel Vetter 2021-01-21 8:27 ` Daniel Vetter 2021-01-21 8:40 ` Simon Ser 2021-01-21 8:40 ` Simon Ser 2021-01-21 10:01 ` Thomas Zimmermann 2021-01-21 10:01 ` Thomas Zimmermann 2021-01-21 18:07 ` Noralf Trønnes 2021-01-21 18:07 ` Noralf Trønnes 2021-01-22 7:54 ` Thomas Zimmermann 2021-01-22 7:54 ` Thomas Zimmermann 2021-01-22 7:59 ` Thomas Zimmermann 2021-01-22 7:59 ` Thomas Zimmermann 2021-01-22 11:44 ` Noralf Trønnes 2021-01-22 11:44 ` Noralf Trønnes 2021-01-22 12:47 ` Thomas Zimmermann 2021-01-22 12:47 ` Thomas Zimmermann 2021-01-22 14:35 ` Noralf Trønnes 2021-01-22 14:35 ` Noralf Trønnes 2021-01-22 14:55 ` Thomas Zimmermann 2021-01-22 14:55 ` Thomas Zimmermann 2021-01-22 18:39 ` Noralf Trønnes 2021-01-22 18:39 ` Noralf Trønnes 2021-01-20 17:00 ` [PATCH v4 2/3] drm/probe-helper: Check epoch counter in output_poll_execute() Noralf Trønnes 2021-01-20 17:00 ` Noralf Trønnes 2021-01-20 17:41 ` Daniel Vetter 2021-01-20 17:41 ` Daniel Vetter 2021-01-20 17:00 ` [PATCH v4 3/3] drm: Add Generic USB Display driver Noralf Trønnes 2021-01-20 17:00 ` Noralf Trønnes 2021-01-20 18:02 ` Daniel Vetter 2021-01-24 16:17 ` Noralf Trønnes 2021-01-24 16:17 ` Noralf Trønnes 2021-01-21 9:59 ` [PATCH v4 0/3] " Thomas Zimmermann 2021-01-21 9:59 ` Thomas Zimmermann 2021-01-21 10:20 ` Simon Ser 2021-01-21 10:20 ` Simon Ser 2021-01-23 11:46 ` Noralf Trønnes 2021-01-23 11:46 ` Noralf Trønnes 2021-01-23 18:47 ` Lubomir Rintel 2021-01-23 18:47 ` Lubomir Rintel 2021-01-24 18:38 ` Lubomir Rintel 2021-01-24 18:38 ` Lubomir Rintel 2021-01-24 20:51 ` Noralf Trønnes 2021-01-24 20:51 ` Noralf Trønnes 2021-02-21 11:14 ` Noralf Trønnes [this message] 2021-02-21 11:14 ` Noralf Trønnes
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=1c182bf1-41d7-49e7-f15e-e8d9ad6386a2@tronnes.org \ --to=noralf@tronnes.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=hudson@trmm.net \ --cc=linux-usb@vger.kernel.org \ --cc=lkundrak@v3.sk \ --cc=markus@raatikainen.cc \ --cc=peter@stuge.se \ --cc=pontus.fuchs@gmail.com \ --cc=sam@ravnborg.org \ --cc=th020394@gmail.com \ /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: linkBe 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.