[regression] RPI4B drm vc4: no crtc or sizes since 5.17 (works in 5.16; and still broken in at least 6.1)

2023-03-06 Thread AL13N

Hi,

I have a RPI4B connected on 2nd HDMI port (furthest away from power) to 
a 4K TV, which works until 5.16, from 5.17 there is no X (or plymouth), 
the cause of no X is that EDID gives nothing, and in the journal; there 
is "Cannot find any crct or sizes". Only the kernel is changed for this.


In 5.16 instead of this message there is a bunch of hex lines prefixed 
with BAD.


It is still broken in 6.1 at the very least.

I donno if this is related to this part, but I wanted to try a newer 
kernel, because the RPI4 seems to do all the video decoding in software 
and cannot seem to handle it.



logs:
vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
checking generic (3ea81000 12c000) vs hw (0 )
fb0: switching to vc4 from simple
Console: switching to colour dummy device 80x25
[drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
vc4-drm gpu: [drm] Cannot find any crtc or sizes


Re: [regression] RPI4B drm vc4: no crtc or sizes since 5.17 (works in 5.16; and still broken in at least 6.1)

2023-03-07 Thread AL13N

AL13N schreef op 2023-03-06 17:34:

Hi,

I have a RPI4B connected on 2nd HDMI port (furthest away from power)
to a 4K TV, which works until 5.16, from 5.17 there is no X (or
plymouth), the cause of no X is that EDID gives nothing, and in the
journal; there is "Cannot find any crct or sizes". Only the kernel is
changed for this.

In 5.16 instead of this message there is a bunch of hex lines prefixed 
with BAD.


It is still broken in 6.1 at the very least.

I donno if this is related to this part, but I wanted to try a newer
kernel, because the RPI4 seems to do all the video decoding in
software and cannot seem to handle it.


logs:
vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
checking generic (3ea81000 12c000) vs hw (0 )
fb0: switching to vc4 from simple
Console: switching to colour dummy device 80x25
[drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
vc4-drm gpu: [drm] Cannot find any crtc or sizes


5.16 log has:

vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
[drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
   [00] BAD  00 ff ff ff ff ff ff 00 36 74 00 00 00 00 00 00
   [00] BAD  0b 1f 01 03 00 23 01 78 0a cf 74 a3 57 4c b0 23
   [00] BAD  09 48 4c 00 00 00 01 01 01 ff 01 ff ff 01 01 01
   [00] BAD  01 01 01 01 01 20 08 e8 00 30 f2 70 5a 80 b0 58
   [00] BAD  8a 00 c4 8e 21 00 00 1e 02 3a 80 18 71 38 2d 40
   [00] BAD  58 2c 45 00 c4 8e 21 00 00 1e 00 00 00 fc 00 53
   [00] BAD  41 4c 4f 52 41 0a 20 20 20 20 20 20 00 00 00 fd
   [00] BAD  00 3b 46 1f 8c 3c 00 0a 20 20 20 20 20 20 01 aa
Console: switching to colour frame buffer device 240x67
vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device


i donno what this bad is, but it doesn't happen in 5.17... maybe these 
BAD got filtered out, but they did end up working for me? or something? 
i donno...



I also noticed that earlier in the logs there are more bound lines: 
(some are double)


vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops [vc4])
vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops [vc4])

and then here for some reason systemd does modprobe@drm.service ? is 
this just a delayed starting log line, or does it actually try to unload 
drm and reload? i doubt it?

in any case there is more that appears before:

vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops [vc4])
vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops [vc4])
vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops [vc4])
vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops [vc4])
vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])


so, the error message is weird, as it implies 2 possibilities. however, 
i think it did find a crtc since all those pixelvalve things use crtc 
functions?


So then why do i have this problem on my RPI4? do most people just use 
the raspberry pi kernels?


I looked at what was changed in crtc between 5.16 and 5.17, but not 
much:


2022-02-17	drm/vc4: crtc: Fix runtime_pm reference counting	Maxime 
Ripard	1	-3/+5
2022-02-07	drm/vc4: crtc: Fix redundant variable assignment	Maxime 
Ripard	1	-1/+0
2021-11-05	drm/vc4: crtc: Copy assigned channel to the CRTC	Maxime 
Ripard	1	-2/+2
2021-11-05	drm/vc4: Fix non-blocking commit getting stuck forever	Maxime 
Ripard	1	-1/+4

2021-11-05  drm/vc4: crtc: Drop feed_txp from state Maxime Ripard   1   
-2/+1
2021-11-04	drm/vc4: Increase the core clock based on HVS load	Maxime 
Ripard	1	-0/+15

2021-11-04  drm/vc4: crtc: Add some logging Maxime Ripard   1   -0/+6
2021-11-04	drm/vc4: crtc: Rework the encoder retrieval code 
(again)	Maxime Ripard	1	-21/+9
2021-11-04	drm/vc4: crtc: Add encoder to vc4_crtc_config_pv 
prototype	Maxime Ripard	1	-4/+3
2021-11-04	drm/vc4: Make vc4_crtc_get_encoder public	Maxime 
Ripard	1	-4/+4
2021-10-25	drm/vc4: crtc: Make sure the HDMI controller is powered when 
disabling	Maxime Ripard	1	-1/+18



I looked at them, but in my layman's knowledge, none of those really 
seemed to have any impact?


So, maybe the problem is someplace else?

Can anyone help to find out where this problem might be? even though 
this is old code, i still have this issue at least on 6.1 ?


Regards,

Maarten


Re: [regression] RPI4B drm vc4: no crtc or sizes since 5.17 (works in 5.16; and still broken in at least 6.1)

2023-03-08 Thread AL13N

Maxime Ripard schreef op 2023-03-08 13:35:

Hi,

On Tue, Mar 07, 2023 at 05:10:16PM +, Dave Stevenson wrote:

On Tue, 7 Mar 2023 at 16:25, AL13N  wrote:
> AL13N schreef op 2023-03-06 17:34:
> > I have a RPI4B connected on 2nd HDMI port (furthest away from power)
> > to a 4K TV, which works until 5.16, from 5.17 there is no X (or
> > plymouth), the cause of no X is that EDID gives nothing, and in the
> > journal; there is "Cannot find any crct or sizes". Only the kernel is
> > changed for this.
> >
> > In 5.16 instead of this message there is a bunch of hex lines prefixed
> > with BAD.
> >
> > It is still broken in 6.1 at the very least.
> >
> > I donno if this is related to this part, but I wanted to try a newer
> > kernel, because the RPI4 seems to do all the video decoding in
> > software and cannot seem to handle it.
> >
> >
> > logs:
> > vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
> > vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
> > vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
> > vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
> > vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
> > vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
> > vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
> > checking generic (3ea81000 12c000) vs hw (0 )
> > fb0: switching to vc4 from simple
> > Console: switching to colour dummy device 80x25
> > [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
> > vc4-drm gpu: [drm] Cannot find any crtc or sizes
>
> 5.16 log has:
>
> vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
> vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
> vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
> vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
> vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
> vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
> vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
> [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
> [00] BAD  00 ff ff ff ff ff ff 00 36 74 00 00 00 00 00 00
> [00] BAD  0b 1f 01 03 00 23 01 78 0a cf 74 a3 57 4c b0 23
> [00] BAD  09 48 4c 00 00 00 01 01 01 ff 01 ff ff 01 01 01
> [00] BAD  01 01 01 01 01 20 08 e8 00 30 f2 70 5a 80 b0 58
> [00] BAD  8a 00 c4 8e 21 00 00 1e 02 3a 80 18 71 38 2d 40
> [00] BAD  58 2c 45 00 c4 8e 21 00 00 1e 00 00 00 fc 00 53
> [00] BAD  41 4c 4f 52 41 0a 20 20 20 20 20 20 00 00 00 fd
> [00] BAD  00 3b 46 1f 8c 3c 00 0a 20 20 20 20 20 20 01 aa
> Console: switching to colour frame buffer device 240x67
> vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
>
>
> i donno what this bad is, but it doesn't happen in 5.17... maybe these
> BAD got filtered out, but they did end up working for me? or something?
> i donno...

Run it through edid-decode - the checksum is wrong.

Block 0, Base EDID:
  EDID Structure Version & Revision: 1.3
  Vendor & Product Identification:
Manufacturer: MST
Model: 0
Made in: week 11 of 2021
  Basic Display Parameters & Features:
Analog display
Input voltage level: 0.7/0.3 V
Blank level equals black level
Maximum image size: 35 cm x 1 cm
Gamma: 2.20
RGB color display
First detailed timing is the preferred timing
  Color Characteristics:
Red  : 0.6396, 0.3398
Green: 0.2998, 0.6904
Blue : 0.1376, 0.0380
White: 0.2822, 0.2968
  Established Timings I & II: none
  Standard Timings:
GTF :  2288x1432   61.000 Hz  16:10   90.463 kHz 282.245 MHz
  Detailed Timing Descriptors:
DTD 1:  3840x2160   60.000 Hz  16:9   135.000 kHz 594.000 MHz (708
mm x 398 mm)
 Hfront  176 Hsync  88 Hback 296 Hpol P
 Vfront8 Vsync  10 Vback  72 Vpol P
DTD 2:  1920x1080   60.000 Hz  16:967.500 kHz 148.500 MHz (708
mm x 398 mm)
 Hfront   88 Hsync  44 Hback 148 Hpol P
 Vfront4 Vsync   5 Vback  36 Vpol P
Display Product Name: 'SALORA'
  Display Range Limits:
Monitor ranges (GTF): 59-70 Hz V, 31-140 kHz H, max dotclock 600 
MHz

  Extension blocks: 1
Checksum: 0xaa (should be 0xeb)

Weird that it also says that it's an analog display when it's
connected over HDMI. Something rather bizarre there, and I think it'll
hit problems in drm_edid at [1] as we end up with a connector having
no color_formats defined. I was discussing this with Maxime only last
week, but in relation to VGA monitors connected through HDMI to VGA
adapters without rewriting the EDID.

If you have an issue between 5.16 and 5.17

Re: [regression] RPI4B drm vc4: no crtc or sizes since 5.17 (works in 5.16; and still broken in at least 6.1)

2023-03-08 Thread AL13N

AL13N schreef op 2023-03-08 22:16:

Maxime Ripard schreef op 2023-03-08 13:35:

Hi,

On Tue, Mar 07, 2023 at 05:10:16PM +, Dave Stevenson wrote:

On Tue, 7 Mar 2023 at 16:25, AL13N  wrote:
> AL13N schreef op 2023-03-06 17:34:
> > I have a RPI4B connected on 2nd HDMI port (furthest away from power)
> > to a 4K TV, which works until 5.16, from 5.17 there is no X (or
> > plymouth), the cause of no X is that EDID gives nothing, and in the
> > journal; there is "Cannot find any crct or sizes". Only the kernel is
> > changed for this.
> >
> > In 5.16 instead of this message there is a bunch of hex lines prefixed
> > with BAD.
> >
> > It is still broken in 6.1 at the very least.
> >
> > I donno if this is related to this part, but I wanted to try a newer
> > kernel, because the RPI4 seems to do all the video decoding in
> > software and cannot seem to handle it.
> >
> >
> > logs:
> > vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
> > vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
> > vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
> > vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
> > vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
> > vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
> > vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
> > checking generic (3ea81000 12c000) vs hw (0 )
> > fb0: switching to vc4 from simple
> > Console: switching to colour dummy device 80x25
> > [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
> > vc4-drm gpu: [drm] Cannot find any crtc or sizes
>
> 5.16 log has:
>
> vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
> vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
> vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
> vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
> vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
> vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
> vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
> [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
> [00] BAD  00 ff ff ff ff ff ff 00 36 74 00 00 00 00 00 00
> [00] BAD  0b 1f 01 03 00 23 01 78 0a cf 74 a3 57 4c b0 23
> [00] BAD  09 48 4c 00 00 00 01 01 01 ff 01 ff ff 01 01 01
> [00] BAD  01 01 01 01 01 20 08 e8 00 30 f2 70 5a 80 b0 58
> [00] BAD  8a 00 c4 8e 21 00 00 1e 02 3a 80 18 71 38 2d 40
> [00] BAD  58 2c 45 00 c4 8e 21 00 00 1e 00 00 00 fc 00 53
> [00] BAD  41 4c 4f 52 41 0a 20 20 20 20 20 20 00 00 00 fd
> [00] BAD  00 3b 46 1f 8c 3c 00 0a 20 20 20 20 20 20 01 aa
> Console: switching to colour frame buffer device 240x67
> vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
>
>
> i donno what this bad is, but it doesn't happen in 5.17... maybe these
> BAD got filtered out, but they did end up working for me? or something?
> i donno...

Run it through edid-decode - the checksum is wrong.

Block 0, Base EDID:
  EDID Structure Version & Revision: 1.3
  Vendor & Product Identification:
Manufacturer: MST
Model: 0
Made in: week 11 of 2021
  Basic Display Parameters & Features:
Analog display
Input voltage level: 0.7/0.3 V
Blank level equals black level
Maximum image size: 35 cm x 1 cm
Gamma: 2.20
RGB color display
First detailed timing is the preferred timing
  Color Characteristics:
Red  : 0.6396, 0.3398
Green: 0.2998, 0.6904
Blue : 0.1376, 0.0380
White: 0.2822, 0.2968
  Established Timings I & II: none
  Standard Timings:
GTF :  2288x1432   61.000 Hz  16:10   90.463 kHz 282.245 MHz
  Detailed Timing Descriptors:
DTD 1:  3840x2160   60.000 Hz  16:9   135.000 kHz 594.000 MHz 
(708

mm x 398 mm)
 Hfront  176 Hsync  88 Hback 296 Hpol P
 Vfront8 Vsync  10 Vback  72 Vpol P
DTD 2:  1920x1080   60.000 Hz  16:967.500 kHz 148.500 MHz 
(708

mm x 398 mm)
 Hfront   88 Hsync  44 Hback 148 Hpol P
 Vfront4 Vsync   5 Vback  36 Vpol P
Display Product Name: 'SALORA'
  Display Range Limits:
Monitor ranges (GTF): 59-70 Hz V, 31-140 kHz H, max dotclock 600 
MHz

  Extension blocks: 1
Checksum: 0xaa (should be 0xeb)

Weird that it also says that it's an analog display when it's
connected over HDMI. Something rather bizarre there, and I think 
it'll

hit problems in drm_edid at [1] as we end up with a connector having
no color_formats defined. I was discussing this with Maxime only last
week, but in relation to VGA monitors connected through HDMI to VGA
adapters without rewriting the EDI

Re: [regression] RPI4B drm vc4: no crtc or sizes since 5.17 (works in 5.16; and still broken in at least 6.1)

2023-03-09 Thread AL13N

Dave Stevenson schreef op 2023-03-07 18:10:

Hi Maarten

On Tue, 7 Mar 2023 at 16:25, AL13N  wrote:


AL13N schreef op 2023-03-06 17:34:
> Hi,
>
> I have a RPI4B connected on 2nd HDMI port (furthest away from power)
> to a 4K TV, which works until 5.16, from 5.17 there is no X (or
> plymouth), the cause of no X is that EDID gives nothing, and in the
> journal; there is "Cannot find any crct or sizes". Only the kernel is
> changed for this.
>
> In 5.16 instead of this message there is a bunch of hex lines prefixed
> with BAD.
>
> It is still broken in 6.1 at the very least.
>
> I donno if this is related to this part, but I wanted to try a newer
> kernel, because the RPI4 seems to do all the video decoding in
> software and cannot seem to handle it.
>
>
> logs:
> vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
> vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
> vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
> vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
> vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
> vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
> vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
> checking generic (3ea81000 12c000) vs hw (0 )
> fb0: switching to vc4 from simple
> Console: switching to colour dummy device 80x25
> [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
> vc4-drm gpu: [drm] Cannot find any crtc or sizes

5.16 log has:

vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
[drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
[00] BAD  00 ff ff ff ff ff ff 00 36 74 00 00 00 00 00 00
[00] BAD  0b 1f 01 03 00 23 01 78 0a cf 74 a3 57 4c b0 23
[00] BAD  09 48 4c 00 00 00 01 01 01 ff 01 ff ff 01 01 01
[00] BAD  01 01 01 01 01 20 08 e8 00 30 f2 70 5a 80 b0 58
[00] BAD  8a 00 c4 8e 21 00 00 1e 02 3a 80 18 71 38 2d 40
[00] BAD  58 2c 45 00 c4 8e 21 00 00 1e 00 00 00 fc 00 53
[00] BAD  41 4c 4f 52 41 0a 20 20 20 20 20 20 00 00 00 fd
[00] BAD  00 3b 46 1f 8c 3c 00 0a 20 20 20 20 20 20 01 aa
Console: switching to colour frame buffer device 240x67
vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device


i donno what this bad is, but it doesn't happen in 5.17... maybe these
BAD got filtered out, but they did end up working for me? or 
something?

i donno...


Run it through edid-decode - the checksum is wrong.

Block 0, Base EDID:
  EDID Structure Version & Revision: 1.3
  Vendor & Product Identification:
Manufacturer: MST
Model: 0
Made in: week 11 of 2021
  Basic Display Parameters & Features:
Analog display
Input voltage level: 0.7/0.3 V
Blank level equals black level
Maximum image size: 35 cm x 1 cm
Gamma: 2.20
RGB color display
First detailed timing is the preferred timing
  Color Characteristics:
Red  : 0.6396, 0.3398
Green: 0.2998, 0.6904
Blue : 0.1376, 0.0380
White: 0.2822, 0.2968
  Established Timings I & II: none
  Standard Timings:
GTF :  2288x1432   61.000 Hz  16:10   90.463 kHz 282.245 MHz
  Detailed Timing Descriptors:
DTD 1:  3840x2160   60.000 Hz  16:9   135.000 kHz 594.000 MHz (708
mm x 398 mm)
 Hfront  176 Hsync  88 Hback 296 Hpol P
 Vfront8 Vsync  10 Vback  72 Vpol P
DTD 2:  1920x1080   60.000 Hz  16:967.500 kHz 148.500 MHz (708
mm x 398 mm)
 Hfront   88 Hsync  44 Hback 148 Hpol P
 Vfront4 Vsync   5 Vback  36 Vpol P
Display Product Name: 'SALORA'
  Display Range Limits:
Monitor ranges (GTF): 59-70 Hz V, 31-140 kHz H, max dotclock 600 
MHz

  Extension blocks: 1
Checksum: 0xaa (should be 0xeb)

Weird that it also says that it's an analog display when it's
connected over HDMI. Something rather bizarre there, and I think it'll
hit problems in drm_edid at [1] as we end up with a connector having
no color_formats defined. I was discussing this with Maxime only last
week, but in relation to VGA monitors connected through HDMI to VGA
adapters without rewriting the EDID.


If you have an issue between 5.16 and 5.17, then I'd guess at [2] and
your monitor not asserting hotplug correctly. The raw hotplug status
is reported in /sys/kernel/debug/dri/N/hdmi0_regs (N will be either 0
or 1 depending on the probe order of the vc4 and v3d drivers). Grep
for HDMI_HOTPLUG.

Incorrect hotplug behaviour causes grief when combin

Re: [regression] RPI4B drm vc4: no crtc or sizes since 5.17 (works in 5.16; and still broken in at least 6.1)

2023-03-10 Thread AL13N

Dave Stevenson schreef op 2023-03-09 13:59:

On Wed, 8 Mar 2023 at 22:46, AL13N  wrote:


AL13N schreef op 2023-03-08 22:16:
> Maxime Ripard schreef op 2023-03-08 13:35:
>> Hi,
>>
>> On Tue, Mar 07, 2023 at 05:10:16PM +, Dave Stevenson wrote:
>>> On Tue, 7 Mar 2023 at 16:25, AL13N  wrote:
>>> > AL13N schreef op 2023-03-06 17:34:
>>> > > I have a RPI4B connected on 2nd HDMI port (furthest away from power)
>>> > > to a 4K TV, which works until 5.16, from 5.17 there is no X (or
>>> > > plymouth), the cause of no X is that EDID gives nothing, and in the
>>> > > journal; there is "Cannot find any crct or sizes". Only the kernel is
>>> > > changed for this.
>>> > >
>>> > > In 5.16 instead of this message there is a bunch of hex lines prefixed
>>> > > with BAD.
>>> > >
>>> > > It is still broken in 6.1 at the very least.
>>> > >
>>> > > I donno if this is related to this part, but I wanted to try a newer
>>> > > kernel, because the RPI4 seems to do all the video decoding in
>>> > > software and cannot seem to handle it.
>>> > >
>>> > >
>>> > > logs:
>>> > > vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
>>> > > vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
>>> > > vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > > vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > > vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > > vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > > vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > > checking generic (3ea81000 12c000) vs hw (0 )
>>> > > fb0: switching to vc4 from simple
>>> > > Console: switching to colour dummy device 80x25
>>> > > [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
>>> > > vc4-drm gpu: [drm] Cannot find any crtc or sizes
>>> >
>>> > 5.16 log has:
>>> >
>>> > vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
>>> > vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
>>> > vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
>>> > [00] BAD  00 ff ff ff ff ff ff 00 36 74 00 00 00 00 00 00
>>> > [00] BAD  0b 1f 01 03 00 23 01 78 0a cf 74 a3 57 4c b0 23
>>> > [00] BAD  09 48 4c 00 00 00 01 01 01 ff 01 ff ff 01 01 01
>>> > [00] BAD  01 01 01 01 01 20 08 e8 00 30 f2 70 5a 80 b0 58
>>> > [00] BAD  8a 00 c4 8e 21 00 00 1e 02 3a 80 18 71 38 2d 40
>>> > [00] BAD  58 2c 45 00 c4 8e 21 00 00 1e 00 00 00 fc 00 53
>>> > [00] BAD  41 4c 4f 52 41 0a 20 20 20 20 20 20 00 00 00 fd
>>> > [00] BAD  00 3b 46 1f 8c 3c 00 0a 20 20 20 20 20 20 01 aa
>>> > Console: switching to colour frame buffer device 240x67
>>> > vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
>>> >
>>> >
>>> > i donno what this bad is, but it doesn't happen in 5.17... maybe these
>>> > BAD got filtered out, but they did end up working for me? or something?
>>> > i donno...
>>>
>>> Run it through edid-decode - the checksum is wrong.
>>>
>>> Block 0, Base EDID:
>>>   EDID Structure Version & Revision: 1.3
>>>   Vendor & Product Identification:
>>> Manufacturer: MST
>>> Model: 0
>>> Made in: week 11 of 2021
>>>   Basic Display Parameters & Features:
>>> Analog display
>>> Input voltage level: 0.7/0.3 V
>>> Blank level equals black level
>>> Maximum image size: 35 cm x 1 cm
>>> Gamma: 2.20
>>> RGB color display
>>> First detailed timing is the preferred timing
>>>   Color Characteristics:
>>> Red  : 0.6396, 0.3398
>>> Green: 0.2998, 0.6904
>>> Blue : 0.1376, 0.0380
>>> White: 0.2822, 0.2968
>

Re: [regression] RPI4B drm vc4: no crtc or sizes since 5.17 (works in 5.16; and still broken in at least 6.1)

2023-03-10 Thread AL13N

AL13N schreef op 2023-03-10 10:10:

Dave Stevenson schreef op 2023-03-09 13:59:

On Wed, 8 Mar 2023 at 22:46, AL13N  wrote:


AL13N schreef op 2023-03-08 22:16:
> Maxime Ripard schreef op 2023-03-08 13:35:
>> Hi,
>>
>> On Tue, Mar 07, 2023 at 05:10:16PM +, Dave Stevenson wrote:
>>> On Tue, 7 Mar 2023 at 16:25, AL13N  wrote:
>>> > AL13N schreef op 2023-03-06 17:34:
>>> > > I have a RPI4B connected on 2nd HDMI port (furthest away from power)
>>> > > to a 4K TV, which works until 5.16, from 5.17 there is no X (or
>>> > > plymouth), the cause of no X is that EDID gives nothing, and in the
>>> > > journal; there is "Cannot find any crct or sizes". Only the kernel is
>>> > > changed for this.
>>> > >
>>> > > In 5.16 instead of this message there is a bunch of hex lines prefixed
>>> > > with BAD.
>>> > >
>>> > > It is still broken in 6.1 at the very least.
>>> > >
>>> > > I donno if this is related to this part, but I wanted to try a newer
>>> > > kernel, because the RPI4 seems to do all the video decoding in
>>> > > software and cannot seem to handle it.
>>> > >
>>> > >
>>> > > logs:
>>> > > vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
>>> > > vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
>>> > > vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > > vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > > vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > > vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > > vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > > checking generic (3ea81000 12c000) vs hw (0 )
>>> > > fb0: switching to vc4 from simple
>>> > > Console: switching to colour dummy device 80x25
>>> > > [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
>>> > > vc4-drm gpu: [drm] Cannot find any crtc or sizes
>>> >
>>> > 5.16 log has:
>>> >
>>> > vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
>>> > vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
>>> > vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
>>> > [00] BAD  00 ff ff ff ff ff ff 00 36 74 00 00 00 00 00 00
>>> > [00] BAD  0b 1f 01 03 00 23 01 78 0a cf 74 a3 57 4c b0 23
>>> > [00] BAD  09 48 4c 00 00 00 01 01 01 ff 01 ff ff 01 01 01
>>> > [00] BAD  01 01 01 01 01 20 08 e8 00 30 f2 70 5a 80 b0 58
>>> > [00] BAD  8a 00 c4 8e 21 00 00 1e 02 3a 80 18 71 38 2d 40
>>> > [00] BAD  58 2c 45 00 c4 8e 21 00 00 1e 00 00 00 fc 00 53
>>> > [00] BAD  41 4c 4f 52 41 0a 20 20 20 20 20 20 00 00 00 fd
>>> > [00] BAD  00 3b 46 1f 8c 3c 00 0a 20 20 20 20 20 20 01 aa
>>> > Console: switching to colour frame buffer device 240x67
>>> > vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
>>> >
>>> >
>>> > i donno what this bad is, but it doesn't happen in 5.17... maybe these
>>> > BAD got filtered out, but they did end up working for me? or something?
>>> > i donno...
>>>
>>> Run it through edid-decode - the checksum is wrong.
>>>
>>> Block 0, Base EDID:
>>>   EDID Structure Version & Revision: 1.3
>>>   Vendor & Product Identification:
>>> Manufacturer: MST
>>> Model: 0
>>> Made in: week 11 of 2021
>>>   Basic Display Parameters & Features:
>>> Analog display
>>> Input voltage level: 0.7/0.3 V
>>> Blank level equals black level
>>> Maximum image size: 35 cm x 1 cm
>>> Gamma: 2.20
>>> RGB color display
>>> First detailed timing is the preferred timing
>>>   Color Characteristics:
>>> Red  : 0.6396, 0.3398
>>> Green: 0.2998, 0.6904
>>> Blue : 0.1376, 0.0380
>>>

Re: [regression] RPI4B drm vc4: no crtc or sizes since 5.17 (works in 5.16; and still broken in at least 6.1)

2023-03-10 Thread AL13N

Dave Stevenson schreef op 2023-03-09 13:59:

On Wed, 8 Mar 2023 at 22:46, AL13N  wrote:


AL13N schreef op 2023-03-08 22:16:
> Maxime Ripard schreef op 2023-03-08 13:35:
>> Hi,
>>
>> On Tue, Mar 07, 2023 at 05:10:16PM +, Dave Stevenson wrote:
>>> On Tue, 7 Mar 2023 at 16:25, AL13N  wrote:
>>> > AL13N schreef op 2023-03-06 17:34:
>>> > > I have a RPI4B connected on 2nd HDMI port (furthest away from power)
>>> > > to a 4K TV, which works until 5.16, from 5.17 there is no X (or
>>> > > plymouth), the cause of no X is that EDID gives nothing, and in the
>>> > > journal; there is "Cannot find any crct or sizes". Only the kernel is
>>> > > changed for this.
>>> > >
>>> > > In 5.16 instead of this message there is a bunch of hex lines prefixed
>>> > > with BAD.
>>> > >
>>> > > It is still broken in 6.1 at the very least.
>>> > >
>>> > > I donno if this is related to this part, but I wanted to try a newer
>>> > > kernel, because the RPI4 seems to do all the video decoding in
>>> > > software and cannot seem to handle it.
>>> > >
>>> > >
>>> > > logs:
>>> > > vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
>>> > > vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
>>> > > vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > > vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > > vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > > vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > > vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > > checking generic (3ea81000 12c000) vs hw (0 )
>>> > > fb0: switching to vc4 from simple
>>> > > Console: switching to colour dummy device 80x25
>>> > > [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
>>> > > vc4-drm gpu: [drm] Cannot find any crtc or sizes
>>> >
>>> > 5.16 log has:
>>> >
>>> > vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
>>> > vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
>>> > vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
>>> > [00] BAD  00 ff ff ff ff ff ff 00 36 74 00 00 00 00 00 00
>>> > [00] BAD  0b 1f 01 03 00 23 01 78 0a cf 74 a3 57 4c b0 23
>>> > [00] BAD  09 48 4c 00 00 00 01 01 01 ff 01 ff ff 01 01 01
>>> > [00] BAD  01 01 01 01 01 20 08 e8 00 30 f2 70 5a 80 b0 58
>>> > [00] BAD  8a 00 c4 8e 21 00 00 1e 02 3a 80 18 71 38 2d 40
>>> > [00] BAD  58 2c 45 00 c4 8e 21 00 00 1e 00 00 00 fc 00 53
>>> > [00] BAD  41 4c 4f 52 41 0a 20 20 20 20 20 20 00 00 00 fd
>>> > [00] BAD  00 3b 46 1f 8c 3c 00 0a 20 20 20 20 20 20 01 aa
>>> > Console: switching to colour frame buffer device 240x67
>>> > vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
>>> >
>>> >
>>> > i donno what this bad is, but it doesn't happen in 5.17... maybe these
>>> > BAD got filtered out, but they did end up working for me? or something?
>>> > i donno...
>>>
>>> Run it through edid-decode - the checksum is wrong.
>>>
>>> Block 0, Base EDID:
>>>   EDID Structure Version & Revision: 1.3
>>>   Vendor & Product Identification:
>>> Manufacturer: MST
>>> Model: 0
>>> Made in: week 11 of 2021
>>>   Basic Display Parameters & Features:
>>> Analog display
>>> Input voltage level: 0.7/0.3 V
>>> Blank level equals black level
>>> Maximum image size: 35 cm x 1 cm
>>> Gamma: 2.20
>>> RGB color display
>>> First detailed timing is the preferred timing
>>>   Color Characteristics:
>>> Red  : 0.6396, 0.3398
>>> Green: 0.2998, 0.6904
>>> Blue : 0.1376, 0.0380
>>> White: 0.2822, 0.2968
>

Re: [regression] RPI4B drm vc4: no crtc or sizes since 5.17 (works in 5.16; and still broken in at least 6.1)

2023-03-10 Thread AL13N

AL13N schreef op 2023-03-10 13:38:

Dave Stevenson schreef op 2023-03-09 13:59:

On Wed, 8 Mar 2023 at 22:46, AL13N  wrote:


AL13N schreef op 2023-03-08 22:16:
> Maxime Ripard schreef op 2023-03-08 13:35:
>> Hi,
>>
>> On Tue, Mar 07, 2023 at 05:10:16PM +, Dave Stevenson wrote:
>>> On Tue, 7 Mar 2023 at 16:25, AL13N  wrote:
>>> > AL13N schreef op 2023-03-06 17:34:
>>> > > I have a RPI4B connected on 2nd HDMI port (furthest away from power)
>>> > > to a 4K TV, which works until 5.16, from 5.17 there is no X (or
>>> > > plymouth), the cause of no X is that EDID gives nothing, and in the
>>> > > journal; there is "Cannot find any crct or sizes". Only the kernel is
>>> > > changed for this.
>>> > >
>>> > > In 5.16 instead of this message there is a bunch of hex lines prefixed
>>> > > with BAD.
>>> > >
>>> > > It is still broken in 6.1 at the very least.
>>> > >
>>> > > I donno if this is related to this part, but I wanted to try a newer
>>> > > kernel, because the RPI4 seems to do all the video decoding in
>>> > > software and cannot seem to handle it.
>>> > >
>>> > >
>>> > > logs:
>>> > > vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
>>> > > vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
>>> > > vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > > vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > > vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > > vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > > vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > > checking generic (3ea81000 12c000) vs hw (0 )
>>> > > fb0: switching to vc4 from simple
>>> > > Console: switching to colour dummy device 80x25
>>> > > [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
>>> > > vc4-drm gpu: [drm] Cannot find any crtc or sizes
>>> >
>>> > 5.16 log has:
>>> >
>>> > vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
>>> > vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
>>> > vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
>>> > [00] BAD  00 ff ff ff ff ff ff 00 36 74 00 00 00 00 00 00
>>> > [00] BAD  0b 1f 01 03 00 23 01 78 0a cf 74 a3 57 4c b0 23
>>> > [00] BAD  09 48 4c 00 00 00 01 01 01 ff 01 ff ff 01 01 01
>>> > [00] BAD  01 01 01 01 01 20 08 e8 00 30 f2 70 5a 80 b0 58
>>> > [00] BAD  8a 00 c4 8e 21 00 00 1e 02 3a 80 18 71 38 2d 40
>>> > [00] BAD  58 2c 45 00 c4 8e 21 00 00 1e 00 00 00 fc 00 53
>>> > [00] BAD  41 4c 4f 52 41 0a 20 20 20 20 20 20 00 00 00 fd
>>> > [00] BAD  00 3b 46 1f 8c 3c 00 0a 20 20 20 20 20 20 01 aa
>>> > Console: switching to colour frame buffer device 240x67
>>> > vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
>>> >
>>> >
>>> > i donno what this bad is, but it doesn't happen in 5.17... maybe these
>>> > BAD got filtered out, but they did end up working for me? or something?
>>> > i donno...
>>>
>>> Run it through edid-decode - the checksum is wrong.
>>>
>>> Block 0, Base EDID:
>>>   EDID Structure Version & Revision: 1.3
>>>   Vendor & Product Identification:
>>> Manufacturer: MST
>>> Model: 0
>>> Made in: week 11 of 2021
>>>   Basic Display Parameters & Features:
>>> Analog display
>>> Input voltage level: 0.7/0.3 V
>>> Blank level equals black level
>>> Maximum image size: 35 cm x 1 cm
>>> Gamma: 2.20
>>> RGB color display
>>> First detailed timing is the preferred timing
>>>   Color Characteristics:
>>> Red  : 0.6396, 0.3398
>>> Green: 0.2998, 0.6904
>>> Blue : 0.1376, 0.0380
>&g

Re: [regression] RPI4B drm vc4: no crtc or sizes since 5.17 (works in 5.16; and still broken in at least 6.1)

2023-03-10 Thread AL13N

Dave Stevenson schreef op 2023-03-10 14:10:

On Fri, 10 Mar 2023 at 12:59, AL13N  wrote:



I donno if this is related or not, but since 6.1 has v3d, i'm assuming
the opengl compositor will be faster and not draw too much cpu?

I did try youtube video, but that on 1080p fullscreen, takes all the 
CPU

and seems to have dropped frames still?


Does your browser actually use sensible EGL calls to pass dmabufs
around the system? Chromium with Ozone sort of does, but that's about
it.
It's another thing that is implemented in Raspberry Pi OS.


I'm on KDE, disabled compositor, used firefox, used the h264fi plugin to 
force h264, set in about:config the layers.acceleration-force to true. I 
do notice v3d_bin and v3d_render being active, but definately the RDD 
process is using a lot of CPU, so likely no video decoding...


I don't have chromium on this aarch64, there seemed to be some issue 
compiling it, so distro set exclusivearch on... I'll try to rebuild 
this... Ozone, meaning the theme, because it uses EGL? maybe this means 
that on plasma, i should turn the opengl compositor back on, it may 
help(?)



does rpi4B actually have video decoding hardware?


I've already referred you to 
https://github.com/lategoodbye/rpi-zero/issues/43

VCHIQ codecs - Unknown


It is present in our vendor kernel, but not upstreamed. You've chosen
to run mainline.


Ah, this is the crucial piece it seems... i remember the cec-client also 
needing vchiq_arm (there was an url someplace where you could build 
this), i need to take a look at this.



and is this related to
drm? because netflix did not work at all, which requires drm, but is
this a different a different drm than this driver?


Digital Rights Management != Direct Rendering Manager.

Netflix on an unsecured platform will only work through something like
Widevine for software decode.


I did find a widevine .so library built for aarch64 someplace, but that 
library alone doesn't seem to be enough, i need to find some widevine 
addon files, someplace? but widevine didn't seem to be available for 
aarch64, only armv7 ?



  Dave


Thanks for clarifying all this! That makes everything a ton clearer...


Re: [regression] RPI4B drm vc4: no crtc or sizes since 5.17 (works in 5.16; and still broken in at least 6.1)

2023-03-11 Thread AL13N

AL13N schreef op 2023-03-10 13:38:

Dave Stevenson schreef op 2023-03-09 13:59:

On Wed, 8 Mar 2023 at 22:46, AL13N  wrote:


AL13N schreef op 2023-03-08 22:16:
> Maxime Ripard schreef op 2023-03-08 13:35:
>> Hi,
>>
>> On Tue, Mar 07, 2023 at 05:10:16PM +, Dave Stevenson wrote:
>>> On Tue, 7 Mar 2023 at 16:25, AL13N  wrote:
>>> > AL13N schreef op 2023-03-06 17:34:
>>> > > I have a RPI4B connected on 2nd HDMI port (furthest away from power)
>>> > > to a 4K TV, which works until 5.16, from 5.17 there is no X (or
>>> > > plymouth), the cause of no X is that EDID gives nothing, and in the
>>> > > journal; there is "Cannot find any crct or sizes". Only the kernel is
>>> > > changed for this.
>>> > >
>>> > > In 5.16 instead of this message there is a bunch of hex lines prefixed
>>> > > with BAD.
>>> > >
>>> > > It is still broken in 6.1 at the very least.
>>> > >
>>> > > I donno if this is related to this part, but I wanted to try a newer
>>> > > kernel, because the RPI4 seems to do all the video decoding in
>>> > > software and cannot seem to handle it.
>>> > >
>>> > >
>>> > > logs:
>>> > > vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
>>> > > vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
>>> > > vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > > vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > > vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > > vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > > vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > > checking generic (3ea81000 12c000) vs hw (0 )
>>> > > fb0: switching to vc4 from simple
>>> > > Console: switching to colour dummy device 80x25
>>> > > [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
>>> > > vc4-drm gpu: [drm] Cannot find any crtc or sizes
>>> >
>>> > 5.16 log has:
>>> >
>>> > vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
>>> > vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
>>> > vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
>>> > [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
>>> > [00] BAD  00 ff ff ff ff ff ff 00 36 74 00 00 00 00 00 00
>>> > [00] BAD  0b 1f 01 03 00 23 01 78 0a cf 74 a3 57 4c b0 23
>>> > [00] BAD  09 48 4c 00 00 00 01 01 01 ff 01 ff ff 01 01 01
>>> > [00] BAD  01 01 01 01 01 20 08 e8 00 30 f2 70 5a 80 b0 58
>>> > [00] BAD  8a 00 c4 8e 21 00 00 1e 02 3a 80 18 71 38 2d 40
>>> > [00] BAD  58 2c 45 00 c4 8e 21 00 00 1e 00 00 00 fc 00 53
>>> > [00] BAD  41 4c 4f 52 41 0a 20 20 20 20 20 20 00 00 00 fd
>>> > [00] BAD  00 3b 46 1f 8c 3c 00 0a 20 20 20 20 20 20 01 aa
>>> > Console: switching to colour frame buffer device 240x67
>>> > vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
>>> >
>>> >
>>> > i donno what this bad is, but it doesn't happen in 5.17... maybe these
>>> > BAD got filtered out, but they did end up working for me? or something?
>>> > i donno...
>>>
>>> Run it through edid-decode - the checksum is wrong.
>>>
>>> Block 0, Base EDID:
>>>   EDID Structure Version & Revision: 1.3
>>>   Vendor & Product Identification:
>>> Manufacturer: MST
>>> Model: 0
>>> Made in: week 11 of 2021
>>>   Basic Display Parameters & Features:
>>> Analog display
>>> Input voltage level: 0.7/0.3 V
>>> Blank level equals black level
>>> Maximum image size: 35 cm x 1 cm
>>> Gamma: 2.20
>>> RGB color display
>>> First detailed timing is the preferred timing
>>>   Color Characteristics:
>>> Red  : 0.6396, 0.3398
>>> Green: 0.2998, 0.6904
>>> Blue : 0.1376, 0.0380
>&g

RPI4B: what is needed for /dev/video10 to work ( v4l_m2m )

2023-12-27 Thread AL13N

Hi,


I have a RPI4B with upstream kernel 6.1 64bit and there is no 
/dev/video10 present. I thought if I waited a bit more, it would appear 
in the kernel, but that was folly on my part.


Currently, watching a movie is painful since the software decoding is 
way too slow and it has very low fps on 1080p (or even 720p or even 
480p)


IIRC, someone told me something else has to be fixed before the codecs 
can be done, but I don't remember what it was, or i didn't find it in my 
email/the archives.


Can someone tell me what exactly needs to be done (in kernel) so that I 
can take a crack at it, (hopefully with some help)?


I don't remember if this was relevant, but there was some talk of 
needing to use opengl output with a specific texture format for it to 
work? or is that seperate?



Thanks in advance,

AL13N


Re: RPI4B: what is needed for /dev/video10 to work ( v4l_m2m )

2024-01-02 Thread AL13N

Maxime Ripard schreef op 2024-01-02 11:03:

Hi,

On Wed, Dec 27, 2023 at 04:19:19PM +0100, AL13N wrote:
I have a RPI4B with upstream kernel 6.1 64bit and there is no 
/dev/video10
present. I thought if I waited a bit more, it would appear in the 
kernel,

but that was folly on my part.

Currently, watching a movie is painful since the software decoding is 
way

too slow and it has very low fps on 1080p (or even 720p or even 480p)

IIRC, someone told me something else has to be fixed before the codecs 
can

be done, but I don't remember what it was, or i didn't find it in my
email/the archives.

Can someone tell me what exactly needs to be done (in kernel) so that 
I can

take a crack at it, (hopefully with some help)?

I don't remember if this was relevant, but there was some talk of 
needing to
use opengl output with a specific texture format for it to work? or is 
that

seperate?


That's something for linux-media. The hardware codec isn't part of vc4
or v3d, it's a separate controller that requires a separate driver (in
v4l2).

That driver isn't upstream, and that would need the first thing to
tackle.

Maxime


Can I assume you're talking about the vchiq driver, which would have 
multiple things including codecs, or am I misunderstanding it?