YUV Display

[E Honsch]

Hi, Neil
> On 27/11/2021 08:06, E Honsch wrote:
>> I've been using an ODroid C2 for our race car dashboard and we decided to upgrade the screen to a more dashboard friendly size. We ended up going with this one: https://www.waveshare.com/wiki/11.9inch_HDMI_LCD
>>
>> What they didn't mention is that is only takes YUV data.
> this is weird, DVI mandates RGB support by default, YUV is only for HDMI display with the DRM_EDID_HDMI_DC_Y444 is EDID.
>
>> After digging around I figured out that YUV scanout isn't yet supported in the meson drm.
> It is, when display is an HDMI display that support DRM_EDID_HDMI_DC_Y444 it will scanout in YUV instead of RGB by default,
>
>> How far away from being able to support YUV is the code currently?  Does the documentation exist to implement the feature?  If the information is around I'd take a stab at getting it going if someone points me in the right direction.
> Could you give more details about which kernel you run and what makes you think YUV isn't supported.
>
> Neil
>
>> Thanks.
>>
>>
>> _______________________________________________
>> linux-amlogic mailing list
>> linux-amlogic at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-amlogic
>
I've tried a few kernels. The stock Hardkernel image (really old 3.x 
kernel, which sort-of worked, I got display but the background was full 
magenta), also the 5.8 and 5.15.5 kernels which would not even get the 
display to turn on the backlight.  I need to use a newer kernel for my 
application.

When I was digging trying to find out how to set a custom modeline I 
found a post somewhere that mentioned that YUV output was not yet 
implemented.  It seemed legit and recent so I didn't question it too 
much.  I can't find the post now.  Trying on two intel laptops, it won't 
even turn on the backlight on my XPS running Ubuntu 20.04, and with my 
work win10 laptop it works fine.

If you look at the link, it's a strange display.  320x1480, perfect for 
a small car dashboard if you rotate it 90 degrees.

The program I wrote uses OpenGLES2.0 directly without X or Wayland.
When I run it I get no modes on the connector.

I puled the EDID data and the problems might be there:

edid-decode (hex):

00 ff ff ff ff ff ff 00 21 94 24 1f 0a 00 00 00
1c 1e 01 03 80 94 30 78 0a 0d c9 a0 57 47 98 27
12 48 4c 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 68 10 40 8d 10 c8 20 50 3c 17
04 04 80 38 74 00 00 18 c8 19 40 97 11 c8 20 50
59 04 04 44 80 38 74 00 00 18 00 00 00 fc 00 57
61 76 65 53 68 61 72 65 20 20 20 20 00 00 00 fd
00 14 78 01 ff 1d 00 0a 20 20 20 20 20 20 01 ee

02 03 1a 71 47 00 00 00 00 00 00 00 23 09 07 01
83 01 00 00 65 03 0c 00 10 00 c8 19 40 97 11 c8
20 50 59 04 04 44 80 38 74 00 00 18 c8 19 40 97
11 c8 20 50 59 04 04 44 80 38 74 00 00 18 c8 19
40 97 11 c8 20 50 59 04 04 44 80 38 74 00 00 18
c8 19 40 97 11 c8 20 50 59 04 04 44 80 38 74 00
00 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 45

----------------

EDID version: 1.3
Manufacturer: HLT Model 7972 Serial Number 10
Made in week 28 of 2020
Digital display
Maximum image size: 148 cm x 48 cm
Gamma: 2.20
RGB color display
First detailed timing is preferred timing
Color Characteristics
   Red:   0.6250, 0.3398
   Green: 0.2802, 0.5947
   Blue:  0.1552, 0.0703
   White: 0.2832, 0.2978
Established Timings I & II: none
Standard Timings: none
Detailed mode: Clock 42.000 MHz, 1920 mm x 1080 mm
                 320  380  403  461 ( 60  23  58)
                1480 1496 1500 1512 ( 16   4  12)
                -hsync -vsync
                VertFreq: 60.255 Hz, HorFreq: 91.106 kHz
Detailed mode: Clock 66.000 MHz, 1920 mm x 1080 mm
                 320  665  669  727 (345   4  58)
                1480 1496 1500 1512 ( 16   4  12)
                -hsync -vsync
                VertFreq: 60.042 Hz, HorFreq: 90.784 kHz
Display Product Name: WaveShare
Display Range Limits
   Monitor ranges (GTF): 20-120 Hz V, 1-255 kHz H, max dotclock 290 MHz
Has 1 extension block
Checksum: 0xee

----------------

CTA-861 Extension Block Revision 3
Basic audio support
Supports YCbCr 4:4:4
Supports YCbCr 4:2:2
1 native detailed modes
22 bytes of CTA data blocks
   Video Data Block
   Audio Data Block
     Linear PCM, max channels 2
       Supported sample rates (kHz): 48 44.1 32
       Supported sample sizes (bits): 16
   Speaker Allocation Data Block
     Speaker map:
       FL/FR - Front Left/Right
   Vendor-Specific Data Block, OUI 0x000c03 (HDMI)
     Source physical address 1.0.0.0
Detailed mode: Clock 66.000 MHz, 1920 mm x 1080 mm
                 320  665  669  727 (345   4  58)
                1480 1496 1500 1512 ( 16   4  12)
                -hsync -vsync
                VertFreq: 60.042 Hz, HorFreq: 90.784 kHz
Detailed mode: Clock 66.000 MHz, 1920 mm x 1080 mm
                 320  665  669  727 (345   4  58)
                1480 1496 1500 1512 ( 16   4  12)
                -hsync -vsync
                VertFreq: 60.042 Hz, HorFreq: 90.784 kHz
Detailed mode: Clock 66.000 MHz, 1920 mm x 1080 mm
                 320  665  669  727 (345   4  58)
                1480 1496 1500 1512 ( 16   4  12)
                -hsync -vsync
                VertFreq: 60.042 Hz, HorFreq: 90.784 kHz
Detailed mode: Clock 66.000 MHz, 1920 mm x 1080 mm
                 320  665  669  727 (345   4  58)
                1480 1496 1500 1512 ( 16   4  12)
                -hsync -vsync
                VertFreq: 60.042 Hz, HorFreq: 90.784 kHz
Checksum: 0x45

The manufacturer's page says to use a specific HDMI setting with an rPi 
(which mostly works) which is the first mode with the 42MHz pixel clock.
In the extension block at the end that mode isn't listed.  I wonder if 
there's an easy way to force a choice.  I tried the modeline in the 
odroid boot.cfg file but it didn't seem to have any effect on the 
mainine kernels.

I do build my own kernels as I use a bunch of the IIO stuff that's 
turned off by default and I had to fix some interrupt related things so 
hacking at the kernel isn't a problem.

Thanks,
Eric