Den 12.03.2021 05.32, skrev Peter Stuge:
> Ilia Mirkin wrote:
>> XRGB means that the memory layout should match a 32-bit integer,
>> stored as LE, with the low bits being B, next bits being G, etc. This
>> translates to byte 0 = B, byte 1 = G, etc. If you're on a BE system,
>> and you're han
Ilia Mirkin wrote:
> XRGB means that the memory layout should match a 32-bit integer,
> stored as LE, with the low bits being B, next bits being G, etc. This
> translates to byte 0 = B, byte 1 = G, etc. If you're on a BE system,
> and you're handed a XRGB buffer, it still expects that byte
On Thu, Mar 11, 2021 at 5:58 PM Peter Stuge wrote:
>
> Ilia Mirkin wrote:
> > > > #define DRM_FORMAT_XRGB fourcc_code('X', 'R', '2', '4') /* [31:0]
> > > > x:R:G:B 8:8:8:8 little endian */
> > >
> > > Okay, "[31:0] x:R:G:B 8:8:8:8" can certainly mean
> > > [31:24]=x [23:16]=R [15:8]=G [7:0]=
Ilia Mirkin wrote:
> > > #define DRM_FORMAT_XRGB fourcc_code('X', 'R', '2', '4') /* [31:0]
> > > x:R:G:B 8:8:8:8 little endian */
> >
> > Okay, "[31:0] x:R:G:B 8:8:8:8" can certainly mean
> > [31:24]=x [23:16]=R [15:8]=G [7:0]=B, which when stored "little endian"
> > becomes B G R X in memory
On Thu, Mar 11, 2021 at 3:02 PM Peter Stuge wrote:
> > > Hence the question: What does DRM promise about the XRGB mode?
> >
> > That it's a 32-bit value. From include/uapi/drm/drm_fourcc.h:
> >
> > /* 32 bpp RGB */
> > #define DRM_FORMAT_XRGB fourcc_code('X', 'R', '2', '4') /* [31:0]
> >
Noralf Trønnes wrote:
> > Endianness matters because parts of pix32 are used.
>
> This code:
..
> prints:
>
> xrgb=aabbccdd
> 32-bit access:
> r=bb
> g=cc
> b=dd
> Byte access on LE:
> r=cc
> g=bb
> b=aa
As expected, and:
xrgb=aabbccdd
32-bit access:
r=bb
g=cc
b=dd
Byte access on BE:
r=
Den 11.03.2021 15.48, skrev Peter Stuge:
> Noralf Trønnes wrote:
>>> I didn't receive the expected bits/bytes for RGB111 on the bulk endpoint,
>>> I think because of how components were extracted in gud_xrgb_to_color().
>>>
>>> Changing to the following gets me the expected (X R1 G1 B1 X R2 G
Noralf Trønnes wrote:
> > I didn't receive the expected bits/bytes for RGB111 on the bulk endpoint,
> > I think because of how components were extracted in gud_xrgb_to_color().
> >
> > Changing to the following gets me the expected (X R1 G1 B1 X R2 G2 B2)
> > bytes:
> >
> >
Den 10.03.2021 05.55, skrev Peter Stuge:
> Noralf Trønnes wrote:
>>> Depending on how long it takes for the DMA mask dependency patch to show
>>> up in drm-misc-next, I will either publish a new version or apply the
>>> current and provide patches with the necessary fixes.
>>
>> In case I apply
Noralf Trønnes wrote:
> > The u16 index parameter to gud_usb_transfer() and at least also
> > gud_usb_{get,set,get_u8,set_u8}() is eventually passed in u16 value
> > in the call to gud_usb_control_msg(), which had me confused for a bit.
> >
> > What do you think about renaming all of those parame
Den 09.03.2021 19.07, skrev Noralf Trønnes:
>
>
> Den 09.03.2021 15.02, skrev Peter Stuge:
>> Hello Noralf,
>>
>> I've made some progress with my test device. I'm implementing R1
>> first and once that works I'll test RGB111 as well. Along the way
>> I've found a couple of things in the code:
>
Den 09.03.2021 15.02, skrev Peter Stuge:
> Hello Noralf,
>
> I've made some progress with my test device. I'm implementing R1
> first and once that works I'll test RGB111 as well. Along the way
> I've found a couple of things in the code:
>
> Noralf Trønnes wrote:
>> +++ b/drivers/gpu/drm/gud/g
Hello Noralf,
I've made some progress with my test device. I'm implementing R1
first and once that works I'll test RGB111 as well. Along the way
I've found a couple of things in the code:
Noralf Trønnes wrote:
> +++ b/drivers/gpu/drm/gud/gud_drv.c
..
> +static int gud_probe(struct usb_interface *
Den 05.03.2021 17.31, skrev Noralf Trønnes:
> 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.
>
> diff --git a/drivers/gpu/drm/gud/gu
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
15 matches
Mail list logo
