Fix kmsprint fourcc

[tomba]

No description provided.

[popcornmix]

Yes, that looks better:

$ build/utils/kmsprint
Connector 0 (33) HDMI-A-1 (connected)
  Encoder 0 (32) TMDS
    Crtc 2 (92) 3840x2160@60.00 594.000 3840/176/88/296/+ 2160/8/10/72/+ 60 (60.00) D 
      Plane 2 (81) fb-id: 685 (crtcs: 2) 0,0 3840x2160 -> 0,0 3840x2160 (XR24 AR24 AB24 XB24 RG16 BG16 AR15 XR15 RG24 BG24 YU16 YV16 YU24 YV24 YU12 YV12 NV12 NV21 NV16 NV61 P030 XR30 AR30 AB30 XB30 RGB8 BGR8 XR12 AR12 XB12 AB12 BX12 BA12 RX12 RA12 P010 P012 P016 S010 S012 S016)
        FB 685 3840x2160 P030
      Plane 4 (105) fb-id: 681 (crtcs: 1 2 3) 0,0 3840x2160 -> 0,0 3840x2160 (XR24 AR24 AB24 XB24 RG16 BG16 AR15 XR15 RG24 BG24 YU16 YV16 YU24 YV24 YU12 YV12 NV12 NV21 NV16 NV61 P030 XR30 AR30 AB30 XB30 RGB8 BGR8 XR12 AR12 XB12 AB12 BX12 BA12 RX12 RA12 P010 P012 P016 S010 S012 S016)
        FB 681 3840x2160 AR30

[popcornmix]

Note: when run multiple times I sometimes get:

Connector 0 (33) HDMI-A-1 (connected)
  Encoder 0 (32) TMDS
    Crtc 2 (92) 3840x2160@60.00 594.000 3840/176/88/296/+ 2160/8/10/72/+ 60 (60.00) D 
      Plane 2 (81) fb-id: 683 (crtcs: 2) 0,0 3840x2160 -> 0,0 3840x2160 (XR24 AR24 AB24 XB24 RG16 BG16 AR15 XR15 RG24 BG24 YU16 YV16 YU24 YV24 YU12 YV12 NV12 NV21 NV16 NV61 P030 XR30 AR30 AB30 XB30 RGB8 BGR8 XR12 AR12 XB12 AB12 BX12 BA12 RX12 RA12 P010 P012 P016 S010 S012 S016)
        FB 683 0x0 /
      Plane 4 (105) fb-id: 681 (crtcs: 1 2 3) 0,0 3840x2160 -> 0,0 3840x2160 (XR24 AR24 AB24 XB24 RG16 BG16 AR15 XR15 RG24 BG24 YU16 YV16 YU24 YV24 YU12 YV12 NV12 NV21 NV16 NV61 P030 XR30 AR30 AB30 XB30 RGB8 BGR8 XR12 AR12 XB12 AB12 BX12 BA12 RX12 RA12 P010 P012 P016 S010 S012 S016)
        FB 681 3840x2160 AR30

Note the FB 683 0x0 /.
I suspect this is due to asynchronous nature of updates occurring and kmsprint sampling the state and it catches the framebuffer just as it's being removed?

I have seen this sort of behaviour on Bookworm, so this isn't a regression.
I Just thought I'd mention it in case you had any ideas.

[tomba]

Hmm interesting. Your guess sounds feasible. The Framebuffer(fb_id) constructor just gets the data with drmModeGetFB2() and uses it. I would have thought that drmModeGetFB2() fails if the fb is being torn down, though...

[tomba]

The fourcc is odd too. I would have expected 0, but it looks like it has "/" character...

[popcornmix]

The / appeared to be consistent with my current test on trixie, but perhaps that is just being lucky.

I can see what looks like garbage from a run on another platform (this is LibreELEC):

Connector 0 (33) HDMI-A-1 (connected)
  Encoder 0 (32) TMDS
    Crtc 2 (92) 1920x1080i@60.00 74.250 1920/88/44/148/+ 1080/4/10/31/+ 60 (60.00) P|D 
      Plane 2 (81) fb-id: 685 (crtcs: 2) 0,0 3840x2160 -> 0,0 1920x1080 (XR24 AR24 AB24 XB24 RG16 BG16 AR15 XR15 RG24 BG24 YU16 YV16 YU24 YV24 YU12 YV12 NV12 NV21 NV16 NV61 P030 XR30 AR30 AB30 XB30 RGB8 BGR8 XR12 AR12 XB12 AB12 BX12 BA12 RX12 RA12)
        FB 685 0x0 踃�

[tomba]

Have you by any chance tried libdrm's modetest to get the fb info (I have to say I'm not sure if it does show the fb data)?

[popcornmix]

It doesn't seem to (or if it's meant to it doesn't seem to be working for me).

$ modetest -f
trying to open device '/dev/dri/card1'... done
opened device `Broadcom VC4 graphics` on driver `vc4` (version 0.0.0 at 0)
Frame buffers:
id	size	pitch

(this is when kmsprint is showing two FBs).