Re: YUV Display

[Neil Armstrong <narmstrong@baylibre.com>]

Hi,

On 01/12/2021 06:51, E Honsch wrote:
> On 2021-11-30 01:59, Neil Armstrong wrote:
>> Hi,
>>
>> On 30/11/2021 01:05, E Honsch wrote:
>>> 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@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.
>> By default the kernel rejects:
>>
>>   869         if (mode->hdisplay < 640 || mode->hdisplay > 1920)
>>   870                 return MODE_BAD_HVALUE;
>>   871
>>   872         if (mode->vdisplay < 480 || mode->vdisplay > 1200)
>>   873                 return MODE_BAD_VVALUE;
>>
>> So yes it's expected, but these values are arbitrary, and it should probably work
>> with hdisplay == 320.
>>
>> You can try this:
>> diff --git a/drivers/gpu/drm/meson/meson_venc.c b/drivers/gpu/drm/meson/meson_venc.c
>> index 3c55ed003359..699eb08a2350 100644
>> --- a/drivers/gpu/drm/meson/meson_venc.c
>> +++ b/drivers/gpu/drm/meson/meson_venc.c
>> @@ -866,7 +866,7 @@ meson_venc_hdmi_supported_mode(const struct drm_display_mode *mode)
>>                              DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_NVSYNC))
>>                  return MODE_BAD;
>>
>> -       if (mode->hdisplay < 640 || mode->hdisplay > 1920)
>> +       if (mode->hdisplay < 320 || mode->hdisplay > 1920)
>>                  return MODE_BAD_HVALUE;
>>
>>          if (mode->vdisplay < 480 || mode->vdisplay > 1200)
>>
>> Neil
>>
>>> 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
>>>
> OK, that got me video but it's not without issues.
> 
> Anything that is supposed to be black is full magenta, and anything that is supposed to be white is a pale green, probably 1-magenta.

OK, seems to be a RGB/YUV issue

> 
> I setup the DRM_PRINT to dump everything but it's a little large to put here.  Is there anything you would like to see from it?

You can use pastebin.

You would also need to enable debug prints in drivers/gpu/drm/bridge/synopsys/dw-hdmi.c and locate the message:
"input format 0xXXXX, output format 0xXXXX"

> 
> On a related note, is there an easy way to rotate the display 90 degrees?  I can do it in software by drawing everything rotated but it would be cleaner if I got a 1480x320 display buffer.

No sorry, the HW doesn't have a display rotation engine in the video output pipeline.

> 
> Thanks,
> Eric
> 


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic