04:42 <chewitt> xdarklight: the blue-ish screen is an exact-match description of the issue we see on G12 hardware when mainline kernels run on-top of bsp u-boot

04:44 <chewitt> I suspect it's not specific to G12, more about the bsp u-boot version - and beyond a certain point which is used with G12 and up hardware the issue is seen

04:44 <chewitt> if we use mainline u-boot the issue is not seen

04:45 <chewitt> our current hack is chainloading mainline u-boot from vendor u-boot

06:32 <xdarklight> chewitt: when you get that blue screen, does running kmscube, starting X, etc. show an image on the screen or does it stay blue-ish?

06:54 <chewitt> everything runs as normal .. I have Kodi etc. but overlayed behind a blue-tinged screen

06:54 <chewitt> it looks like an RGB vs YUV issue

06:58 <chewitt> it might not be the same thing you're seeing .. but it all sounds related

12:13 <narmstrong> xdarklight: this is weird, the framebuffer is a drm client, so it should behave the same

12:13 <narmstrong> xdarklight: is the framebuffer using argb32 ? check the mode used in both situations

12:15 <narmstrong> Darkmatter66_: "kms: can't enable cloning when we probably wanted to." is expected, it means DRM would like a copy CVBS and HDMI, but can't

12:16 <narmstrong> Darkmatter66_: if you boot without monitor, DRM will select CVBS output, and "576p@50Hz", if you connect an HDMI monitor and this monitor has a "576p@50Hz" mode, then it will keep this mode, this is expected

12:16 <narmstrong> Darkmatter66_: check the signal doesn't go to CVBS when it "looses" the signal in to /sys/kernel/debug/dri/0/state or with `modetest -M meson`

16:40 <xdarklight> narmstrong: it's using DRM_FORMAT_XRGB8888 in both cases in meson_plane_atomic_update

16:42 <xdarklight> (just for reference: both cases == framebuffer console and kmscube)

17:02 <xdarklight> narmstrong: oh: https://pastebin.com/qDVqKRYg - now I have the same situation as chewitt: framebuffer in the background and blue tint over it

17:05 <narmstrong> xdarklight: weird, looks like the alpha stuff is not configured correctly

17:05 <narmstrong> Did you use the GXBB path ? You should

17:05 <xdarklight> yes

17:06 <xdarklight> basically I grep'ed for GXBB in the whole driver and added "|| old SoCs"

21:56 <xdarklight> narmstrong: from the HDMI controller's view: what pixel format does VPU output?

21:57 <xdarklight> narmstrong: from the HDMI controller bridge view I'm getting MEDIA_BUS_FMT_YUV8_1X24 for both, input format and output format

22:28 <xdarklight> narmstrong: https://github.com/xdarklight/linux/commit/1b9543643eb4c96a7d4548c8a198f07ce366d083 - the first part is to make our driver match with https://github.com/endlessm/linux-s905x/blob/454897396b1d3c0be417e0bfde7cf94041873944/drivers/amlogic/display/osd_ext/osd_fb.h#L35 (struct declaration is here: https://github.com/endlessm/linux-s905x/blob/454897396b1d3c0be417e0bfde7cf94041873944/drivers/amlogic/display/osd/osd.h#L103 )

22:29 <xdarklight> narmstrong: I think we need this because the VIU_OSD1_CTRL_STAT2 register with OSD_REPLACE_EN ("For XRGB, replace the pixel's alpha by 0xFF") only exists in GXBB and newer. however, the values from that OSD code are the same for old and new SoCs

22:31 <xdarklight> narmstrong: the meson_viu_osd_burst_length_reg change is a random one I stumbled across when I compared register values with u-boot. the old calculation always gives me 0x0. I wonder if that is also related to some of the video problems on G12A (since we configure a burst length of 64 there instead of 32 - the actual setting due to the mis-calculation is 24!)