Den 01.03.2021 19.31, skrev Peter Stuge:
> Hi Noralf,
>
> Peter Stuge wrote:
>> I'll prepare a test setup for the RGB-TFT on the weekend.
>
> So implementing a GUD and looking at the protocol from yet another
> angle gives more new insights - surprise. :)
>
Yep, my Raspberry Pi Pico implemen
Hi Noralf,
Peter Stuge wrote:
> I'll prepare a test setup for the RGB-TFT on the weekend.
So implementing a GUD and looking at the protocol from yet another
angle gives more new insights - surprise. :)
Here are some thoughts so far:
* GUD_REQ_SET_VERSION does still rub me wrong; it seems potent
Den 28.02.2021 02.52, skrev Peter Stuge:
> Noralf Trønnes wrote:
>> Peter, please have a look at this diff and see if I'm on the right track
>> here: https://gist.github.com/notro/a43a93a3aa0cc75d930890b7b254fc0a
>
> Yes that's exactly what I meant; this way the possibility for contradicting
> s
Noralf Trønnes wrote:
> Peter, please have a look at this diff and see if I'm on the right track
> here: https://gist.github.com/notro/a43a93a3aa0cc75d930890b7b254fc0a
Yes that's exactly what I meant; this way the possibility for contradicting
sizes is eliminated by protocol and not just by implem
Den 25.02.2021 22.37, skrev Peter Stuge:
> Noralf Trønnes wrote:
>>> I forgot, but I have a two-tone (black/red) e-ink display here, and I
>>> also have a 3-bpp RGB TFT display.
>>
>> I've been anticipating the need for more formats, but I didn't want to
>> add them without having a user. Otherwi
Den 20.02.2021 18.27, skrev Noralf Trønnes:
>
>
> Den 19.02.2021 22.42, skrev Peter Stuge:
>>
>> More generally it's not very typical in USB to report the data size
>> separately from the data itself, if reporting size explicitly at all.
>>
>> Sizes can be part of the data structure itself (li
Noralf Trønnes wrote:
> > I forgot, but I have a two-tone (black/red) e-ink display here, and I
> > also have a 3-bpp RGB TFT display.
>
> I've been anticipating the need for more formats, but I didn't want to
> add them without having a user. Otherwise I could end up adding stuff
> that would nev
Den 25.02.2021 10.58, skrev Peter Stuge:
> Hi Noralf,
>
> Noralf Trønnes wrote:
>> The driver supports a one bit monochrome transfer format: R1. This is not
>> implemented in the gadget driver. It is added in preparation for future
>> monochrome e-ink displays.
>
> I forgot, but I have a two-to
Hi Noralf,
Noralf Trønnes wrote:
> The driver supports a one bit monochrome transfer format: R1. This is not
> implemented in the gadget driver. It is added in preparation for future
> monochrome e-ink displays.
I forgot, but I have a two-tone (black/red) e-ink display here, and I
also have a 3-b
Den 19.02.2021 22.42, skrev Peter Stuge:
> Hi Noralf,
>
> Noralf Trønnes wrote:
>> +++ b/drivers/gpu/drm/gud/gud_connector.c
> ..
>> +static int gud_connector_get_edid_block(void *data, u8 *buf, unsigned int
>> block, size_t len)
> ..
>> +struct gud_connector *gconn = ctx->gconn;
>> +si
Hi Noralf,
Noralf Trønnes wrote:
> +++ b/drivers/gpu/drm/gud/gud_connector.c
..
> +static int gud_connector_get_edid_block(void *data, u8 *buf, unsigned int
> block, size_t len)
..
> + struct gud_connector *gconn = ctx->gconn;
> + size_t start = block * EDID_LENGTH;
> +
> + if (start
This adds a USB display driver with the intention that it can be
used with future USB interfaced low end displays/adapters. The Linux
gadget device driver will serve as the canonical device implementation.
The following DRM properties are supported:
- Plane rotation
- Connector TV properties
Ther
12 matches
Mail list logo
