11:07 <xdarklight> narmstrong: progres.... MORE HACKS: https://github.com/endlessm/linux-meson/commit/d5c13bff89a9cd788b15c87106c38c6ac013b3e5 ;)

11:08 <xdarklight> narmstrong: that same hack still works more than 5 years later

11:23 <xdarklight> narmstrong: and here's someone reporting some that poking the replaced_alpha and replaced_alpha_en bits into VIU_OSD1_CTRL_STAT2 does something on Odroid-C1: https://forum.odroid.com/viewtopic.php?f=138&t=19403 - but when I read that register back at the end of meson_plane_atomic_update it gives me all zeros

11:24 <xdarklight> sorry, I'm getting back all zeros in meson_crtc_irq but setting the right value in meson_plane_atomic_update

11:26 <xdarklight> ah, that odroid link is for the C2

11:27 <xdarklight> but this is about Meson8b: https://forum.odroid.com/viewtopic.php?p=71621#p71621

11:31 <narmstrong> Wow weird hack

11:32 <xdarklight> I'm out for a while, if you have any ideas (on how to solve it or where to ask for help): I'll continue hacking tonight

12:23 <narmstrong> xdarklight: if I understand you can’t replace alpha with a fixed value to support xrgb but only argb ?

12:23 <narmstrong> xdarklight: solution is to not support xrgb but add support for 24bit formats without alpha

13:17 <xdarklight> ich123

14:50 <narmstrong> xdarklight: I hope it’s not your password !

15:14 <chewitt> some ge2d options mentioned in that thread too

15:18 <xdarklight> narmstrong: heh, no - I'm using generated passwords everywhere

15:23 <xdarklight> narmstrong: I'll try implementing the 24bit formats and see if that gives better results

15:24 <xdarklight> ah, support for DRM_FORMAT_RGB888 is already there

15:38 <xdarklight> hmm, dropping DRM_FORMAT_XRGB8888 makes kmscube unhappy

15:59 <narmstrong> Yep the default is xrgb8888

18:51 <xdarklight> narmstrong: do you think that this is some issue that can be worked around in the DRM code (or if there's a workaround somewhere already)?

19:26 <xdarklight> narmstrong: also does this make sense to you: https://pastebin.com/yL2yyprT ? (problem description in the comment)

21:28 <narmstrong> xdarklight: not sure, not having xrgb8888 is quite an issue

21:29 <narmstrong> xdarklight: do you still have a fbcon without it ?

21:30 <narmstrong> Pretty sure kmscube could run with argb8888 or rgb888 but it would need to be tweaked

21:30 <xdarklight> narmstrong: without DRM_FORMAT_XBGR8888 I still don't have any fbcon

21:31 <narmstrong> I think xrgb8888 is the default one

21:34 <xdarklight> narmstrong: I'm wondering if technically DRM_FORMAT_XBGR8888 is supported, it just needs surface_depth = 32 (whatever that means in the graphics world :-))

21:39 <xdarklight> narmstrong: I've seen that the GMA500 driver does this: https://elixir.bootlin.com/linux/v5.7-rc2/source/drivers/gpu/drm/gma500/framebuffer.c#L470 - but I'm not sure if that would "fix" all use-cases or if we would still have some broken cases afterwards

21:43 <narmstrong> It’s an old platform and is buggy, switching to 16bit for fbcon is not horrible for me

21:43 <narmstrong> Since other graphics stack will correctly handle argb8888

21:45 <xdarklight> instead of switching to 16bit we can also switch to 32bit. the only problem is 24bit (at least that's my understanding)

21:46 <xdarklight> right, I'll switch to 16-bit because that requires only one line of code to change

21:50 <xdarklight> good enough. even the Broadcom VC4 driver uses 16bit

22:03 <xdarklight> narmstrong: nice, DRM switches the format nicely between kmscube and fbcon (and vice versa) :-)

22:07 <xdarklight> and even better: it will even render 24-bit DRM_FORMAT_RGB888 fbcon - so that's worse than GXBB but better than VC4. I'm happy :-)

22:16 <xdarklight> this discussion helped me a lot - thank you narmstrong !