08:29pq: bwidawsk, er, I thought leasing HMDs out of a generic DE was the main use case of leasing? So very much not closed systems.
08:32pq: MrCooper, do you mean that a DRM lessee can also brute-force FB IDs, like a DRM master can?
08:33MrCooper: not sure, possibly
10:20mripard: vsyrjala: ping for https://lore.kernel.org/dri-devel/20240326-kms-hdmi-connector-state-v11-15-c5680ffcf261@kernel.org/ and https://lore.kernel.org/dri-devel/20240326-kms-hdmi-connector-state-v11-21-c5680ffcf261@kernel.org/
12:08tursulin: mripard: could I bother you to merge https://lore.kernel.org/lkml/CABdmKX3V3HGA4mNQvqHqhcLqyr-A5kJK8v9vmuDybRvV-KsiOg@mail.gmail.com/ to drm-misc-next by any chance please? Alternatively I kind of failed to find instructions for requesting commit access in the new gitlab world. :)
12:11mripard: tursulin: will do by tomorrow
12:11mripard: and yeah, we haven't really settled on a procedure yet, sorry
12:11mripard: I'll restart that conversation
12:11mripard: I guess your best bet at the moment is to follow the old one
12:11tursulin: thank you! I will keep an eye on the branch
12:12mripard: it won't give you access to cgit, but we will give you access to gitlab
12:55pq: why do I need to start Weston twice before HDR_OUTPUT_METADATA actually gets all the way to the monitor on amdgpu...
12:55pq: or maybe my monitor doesn't believe the first modeset
12:56jani: hrmh, do I really have to wait for everyone's ack on this https://lore.kernel.org/r/20240410141434.157908-1-jani.nikula@intel.com
12:56jani: (nobody has acked)
13:06pq: what kind of colorimetric clipping could turn gray and black into green, when I set Colorspace=BT2020... reds show up "correctly" though
13:10zamundaaa[m]: pq: I recall seeing an image with colors being wrong like that somewhere, but that was on I think Intel or NVidia, where KWin sets BT2020_RGB and the driver most likely converted the colors to YUV
13:11pq: zamundaaa[m], yeah, it's really hard to imagine this without dipping into YCbCr
13:13pq: more monitor lolz: PQ mode does not allow adjusting brightness, the menu entry is grayed out. Except, I can go to brightness setting via a shorthand, and then I can adjust it.
13:15pq: yeah, with Colorspace=BT2020, blue and red channels just disappear
13:17pq: reds and blues turn black... unless they are bright enough
13:20pq: magenta becomes black, light grey becomes magenta'ish...
13:26pq: ugh, so BT2020 mode looks crazy, and I need to start weston more than once to get new display settings to actually reflect on the monitor, what is this
13:28pq: I'd need a HDMI sniffer to debug this, or another monitor
16:56jfalempe: tzimmermann: when pushing drm_panic, I broke the build of the imx driver (https://lists.freedesktop.org/archives/dri-devel/2024-April/450180.html) may I push the fix from Maira, to avoid breaking drm-tip for too long ? This is a simple typo, I forget to change the function name in the .h file in the v12.
17:44demarchi: daniels: is "nice" == ack to merge?
17:51daniels: demarchi: context?
17:52demarchi: <daniels> 04:08:50> demarchi: nice, thanks!
17:52demarchi: I guess it was for the containers using ci-template in maintainer-tools?
17:53daniels: demarchi: oh yeah, ship it
17:53daniels: working > not working
17:55demarchi: daniels: thanks
17:56daniels: np
17:56daniels: thanks for fixing it
17:57daniels: please do feel free to unbreak igt as well ;)
18:04dcbaker: gfxstrand: Do you have a problem depending on cbindgen >= 0.25? I can make some of your cbindgen workarounds go away if that's an okay tradeoff?
18:13tzimmermann: jfalempe, yes of course
18:29demarchi: daniels: hehehe... ok. I can try later this week
21:36gfxstrand: dcbaker: Fine with me. It's a new dependency
23:16Lucretia: I must be mad, but I've decided to give looking at what can be done to port mesa to classic amigaos, rtg + acceleration only. The initial aim is to get a static link lib built for amigaos targetting opengl 1.5, so fixed function only for now. AmigaOS is a single address space OS with no memory protection, yay :( and doesn't have threads tho they can be emulated and are with a pthread lib. I'm currently looking at getting meson to support amigaos so I can
23:16Lucretia: get past the setup stage. Any pointers will be welcomed.
23:17Lucretia: The initial port will use swrast and osmesa.
23:23Lucretia: for going further with accelerated hw, i.e. pistorm vc4 driver, I'm not sure libkms/drm can be ported/used, I don't know.
23:23airlied: there is an old storm mesa thing
23:24Lucretia: I know, it's old.
23:24Lucretia: and closed, iirc
23:25airlied: but yeah probably want to copy the haiku code paths as they would be similiar in terms of porting to a platform that is insane :-P
23:26Lucretia: not insane, different
23:29airlied: I'll let you change your mind once you've done it :)
23:29Lucretia: change my mind to what?
23:29airlied: whether it's different or insane
23:29Lucretia: I used to use amigaos back in the 90's, it's different
23:29airlied: though I don't know if there any mesa ports to single address space OSes, so that might be a hurdle
23:29Lucretia: back then memory protection was only just happening
23:30airlied: we don't have a classic swrast driver, so you'd probably have to use softpipe
23:30airlied: probably won't have enough for llvmpipe
23:30Lucretia: can't use llvm yet, because it's c++ and dlsym on objects is tricky...
23:31Lucretia: pistorm is max 2GB RAM, FS-UAE which I'll be using until I get real hw going is a tad less.
23:31Lucretia: yeah, you're looking at 266MB
23:32Lucretia: eek
23:32airlied: how big a framebuffer?
23:33Lucretia: whatevr the pi3/4 can provide
23:33airlied: well a 1024x768 @ 32-bit is 3MB
23:34airlied: so that might be fine then
23:34Lucretia: yeah, fs-uae with their built in gfx card can't do massive resolutions.
23:38Lucretia: well, I can get about 751MB on this emulated miggy so far.
23:39Lucretia: and the screenmode res is 1280x1024 32 bit