08:57 <gamiee> jernej: ping

10:33 <linkmauve> Ok so the issue with importing my dmabuf is that even though sun4i-drm (/dev/dri/card0) accepts importing my buffer with DRM_FORMAT_MOD_ALLWINNER_TILED, Weston seems to be somewhat confused and exposes only formats supported by lima (/dev/dri/card1) with the modifier DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED…

10:33 <linkmauve> I guess because lima doesn’t support importing tiled YUV formats?

10:34 <linkmauve> And Weston can’t guarantee my buffer will never get composited.

10:36 <linkmauve> So I guess if I ever want to import my image into EGL, I need to detile it like Gstreamer does with yesterday’s command, on the CPU. :s

10:41 <linkmauve> Ok, and running weston seven seconds or more disables the HDMI connector until reboot on this A10 nowadays. :o

10:41 <linkmauve> I guess I was lucky with onix’s DRM examples having a timeout of five seconds…

12:02 <gamiee> hi apritzel , in relation to our yesterday discussion about configurable HDMI-CEC / IR wake up, I found discussion with you and smaeul from 2022 about this: https://oftc.irclog.whitequark.org/linux-sunxi/2022-06-19#31026312;

15:56 <jernej> gamiee: pong

15:57 <jernej> linkmauve: or you can add support for that modifier to mesa :)

15:57 <linkmauve> Is that a thing the GPU supports?

15:58 <linkmauve> Or would I need a conversion shader?

15:58 <jernej> afaik no, but conversion can be added

16:08 <linkmauve> It would also be a thing only for lima-on-sunxi, as it wouldn’t make much sense to expose it on other platforms.

16:09 <linkmauve> I’m also curious, lima always renders the final scanoutable buffers as LINEAR since the display controller doesn’t support its 16×16 tiled format? :(

16:29 <jernej> I think yes

16:30 <jernej> btw, linear NV16 is also supported for 422 or 444 JPEGs on A33 and newer

16:31 <linkmauve> \o/

19:40 <gamiee> jernej: related to the discussion about configurable wake up sources for Crust. Both smaeul and apritzel mentioned an option, to put the config data to some Crust known place (so I guess in same SRAM as Crust is living?) and Crust before suspend / shutdown will read it and configure itself accordingly. Theoretically, as I written it, it should work, right?

22:22 <KREYREN_oftc> So same packaging instructions meaning u-boot, crust, arm-trusted-firmware across all mainstream linux distros work without an issue, but if i am trying to package u-boot for alpine or postmarketos i don't get a display during the u-boot phase... does anyone have a hypothesis to why?

22:23 <vagrantc> toolchain differences?

22:24 <vagrantc> libc implementations?

22:27 <KREYREN_oftc> alpine's arm-trusted-firmware seems to be using clang, but i changed that on gcc and same issue

22:27 <KREYREN_oftc> vagrantc, libc seems to be same

22:30 <vagrantc> i thought alpine used something other than glibc

22:30 <vagrantc> shouldn't affect u-boot, but who knows...

22:35 <KREYREN_oftc> they use musl afaik

22:37 <KREYREN_oftc> yep musl + busybox

22:41 <apritzel> KREYREN_oftc: are you using Alpine as a build host, or just the packaging instructions from Alpine?

22:41 <KREYREN_oftc> apritzel, alpine as the build host and their package manager

22:42 <apritzel> in general those components are standalone parts, so a) you should be able to mix and match binaries (TF-A and U-Boot), and b) just compile this on any environment

22:43 <apritzel> I mean just grab any machine with a cross compiler and build TF-A and U-Boot

22:43 <apritzel> or even build it natively somewhere

22:43 <apritzel> and what version of TF-A and U-Boot are you building? the same mainline one, or does either alpine or PMOS apply some nasty patches

22:49 <jernej> gamiee: Yes, Crust can read config from any place. SRAM isn't accessed by Linux, so this is ideal

23:08 <KREYREN_oftc> same versions used, tested different once as well

23:09 <KREYREN_oftc> and mainline one are used now

23:09 <KREYREN_oftc> > <apritzel> I mean just grab any machine with a cross compiler and build TF-A and U-Boot < that's the thing.. it doesn't work on alpine which is any machine with a cross compiler

23:20 <apritzel> ah, I see. Maybe there is any host tool that is required during U-Boot build, that doesn't like musl?

23:22 <KREYREN_oftc> apritzel, musl should work though based on teres users telling me that it works on their end using various distros

23:23 <apritzel> do you build this manually, or using some build script?

23:23 <KREYREN_oftc> u-boot devs want me to try manual compilation with BL31.bin supplied from a working distro atm

23:23 <KREYREN_oftc> otherwise it's using the alpine and postmarketos's packaging

23:24 <KREYREN_oftc> which is apk and pmbootstrap

23:24 <KREYREN_oftc> apk is the package manager and pmbootstrap is framework to build images for lot of devices

23:24 <apritzel> yes, that would be my recommendation as well: try one known working component and build the other

23:24 <KREYREN_oftc> SCP is also needed but can be set to /dev/null to be excluded for testing