* YUV Display @ 2021-11-27 7:06 E Honsch 2021-11-29 10:27 ` Neil Armstrong 0 siblings, 1 reply; 9+ messages in thread From: E Honsch @ 2021-11-27 7:06 UTC (permalink / raw) To: linux-amlogic 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. After digging around I figured out that YUV scanout isn't yet supported in the meson drm. 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. Thanks. _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: YUV Display 2021-11-27 7:06 YUV Display E Honsch @ 2021-11-29 10:27 ` Neil Armstrong 2021-11-30 0:05 ` E Honsch 0 siblings, 1 reply; 9+ messages in thread From: Neil Armstrong @ 2021-11-29 10:27 UTC (permalink / raw) To: E Honsch, linux-amlogic Hi, 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 _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: YUV Display 2021-11-29 10:27 ` Neil Armstrong @ 2021-11-30 0:05 ` E Honsch 2021-11-30 9:59 ` Neil Armstrong 0 siblings, 1 reply; 9+ messages in thread From: E Honsch @ 2021-11-30 0:05 UTC (permalink / raw) To: Neil Armstrong, linux-amlogic 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. 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 _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: YUV Display 2021-11-30 0:05 ` E Honsch @ 2021-11-30 9:59 ` Neil Armstrong 2021-12-01 5:51 ` E Honsch 0 siblings, 1 reply; 9+ messages in thread From: Neil Armstrong @ 2021-11-30 9:59 UTC (permalink / raw) To: E Honsch, linux-amlogic 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 > _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: YUV Display 2021-11-30 9:59 ` Neil Armstrong @ 2021-12-01 5:51 ` E Honsch 2021-12-01 9:15 ` Neil Armstrong 0 siblings, 1 reply; 9+ messages in thread From: E Honsch @ 2021-12-01 5:51 UTC (permalink / raw) To: Neil Armstrong, linux-amlogic 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. 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? 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. Thanks, Eric _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: YUV Display 2021-12-01 5:51 ` E Honsch @ 2021-12-01 9:15 ` Neil Armstrong 2021-12-03 4:48 ` E Honsch 0 siblings, 1 reply; 9+ messages in thread From: Neil Armstrong @ 2021-12-01 9:15 UTC (permalink / raw) To: E Honsch, linux-amlogic 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: YUV Display 2021-12-01 9:15 ` Neil Armstrong @ 2021-12-03 4:48 ` E Honsch 2021-12-03 9:09 ` Neil Armstrong 0 siblings, 1 reply; 9+ messages in thread From: E Honsch @ 2021-12-03 4:48 UTC (permalink / raw) To: Neil Armstrong, linux-amlogic Neil, On 2021-12-01 01:15, Neil Armstrong wrote: > 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 >> Here's a link to a lot of drm and meson stuff from the monitor boot up: https://pastebin.com/TfeQnUTR [ 9.039206] meson-dw-hdmi c883a000.hdmi-tx: input format 0x2025, output format 0x200f [ 9.039215] [drm:meson_venc_hdmi_encoder_atomic_check [meson_dw_hdmi]] output_bus_fmt 2025 Thanks, Eric _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: YUV Display 2021-12-03 4:48 ` E Honsch @ 2021-12-03 9:09 ` Neil Armstrong 2021-12-04 7:12 ` E Honsch 0 siblings, 1 reply; 9+ messages in thread From: Neil Armstrong @ 2021-12-03 9:09 UTC (permalink / raw) To: E Honsch, linux-amlogic Hi, On 03/12/2021 05:48, E Honsch wrote: > Neil, > > On 2021-12-01 01:15, Neil Armstrong wrote: >> 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 >>> > Here's a link to a lot of drm and meson stuff from the monitor boot up: > https://pastebin.com/TfeQnUTR > > [ 9.039206] meson-dw-hdmi c883a000.hdmi-tx: input format 0x2025, output format 0x200f > [ 9.039215] [drm:meson_venc_hdmi_encoder_atomic_check [meson_dw_hdmi]] output_bus_fmt 2025 0x200f is YUV422 output, so it seems it doesn't support YUV, and the EDID is wrong. Please try this to completely disable YUV output even if EDID reports so, and only allow RGB output: diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index f08d0fded61f..373ef277c05b 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -2612,10 +2612,10 @@ static u32 *dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge, output_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30; } - if (info->color_formats & DRM_COLOR_FORMAT_YCRCB422) + if (0 && info->color_formats & DRM_COLOR_FORMAT_YCRCB422) output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16; - if (info->color_formats & DRM_COLOR_FORMAT_YCRCB444) + if (0 && info->color_formats & DRM_COLOR_FORMAT_YCRCB444) output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; /* Default 8bit RGB fallback */ Neil > > > Thanks, > > Eric _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: YUV Display 2021-12-03 9:09 ` Neil Armstrong @ 2021-12-04 7:12 ` E Honsch 0 siblings, 0 replies; 9+ messages in thread From: E Honsch @ 2021-12-04 7:12 UTC (permalink / raw) To: Neil Armstrong, linux-amlogic On 2021-12-03 01:09, Neil Armstrong wrote: > Hi, > > On 03/12/2021 05:48, E Honsch wrote: >> Neil, >> >> On 2021-12-01 01:15, Neil Armstrong wrote: >>> 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 >>>> >> Here's a link to a lot of drm and meson stuff from the monitor boot up: >> https://pastebin.com/TfeQnUTR >> >> [ 9.039206] meson-dw-hdmi c883a000.hdmi-tx: input format 0x2025, output format 0x200f >> [ 9.039215] [drm:meson_venc_hdmi_encoder_atomic_check [meson_dw_hdmi]] output_bus_fmt 2025 > 0x200f is YUV422 output, so it seems it doesn't support YUV, and the EDID is wrong. > > Please try this to completely disable YUV output even if EDID reports so, and only allow RGB output: > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > index f08d0fded61f..373ef277c05b 100644 > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > @@ -2612,10 +2612,10 @@ static u32 *dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge, > output_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30; > } > > - if (info->color_formats & DRM_COLOR_FORMAT_YCRCB422) > + if (0 && info->color_formats & DRM_COLOR_FORMAT_YCRCB422) > output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16; > > - if (info->color_formats & DRM_COLOR_FORMAT_YCRCB444) > + if (0 && info->color_formats & DRM_COLOR_FORMAT_YCRCB444) > output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; > > /* Default 8bit RGB fallback */ > > > Neil >> >> Thanks, >> >> Eric >> That worked perfectly. I have a correctly working display and I've even wrote the software rotation code tonight. If I ever run into you, the first beer is on me. Thanks, Eric _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-12-04 7:12 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-11-27 7:06 YUV Display E Honsch 2021-11-29 10:27 ` Neil Armstrong 2021-11-30 0:05 ` E Honsch 2021-11-30 9:59 ` Neil Armstrong 2021-12-01 5:51 ` E Honsch 2021-12-01 9:15 ` Neil Armstrong 2021-12-03 4:48 ` E Honsch 2021-12-03 9:09 ` Neil Armstrong 2021-12-04 7:12 ` E Honsch
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®