08:45phasta: Seems the server migration was a success. Congrats to everyone who contributed to this!
08:47HdkR: Early celebration, it's still happening
08:47phasta: ._.
09:33javierm: tzimmermann: nice series! I just read the cover letter but will likely review on Friday, since is the day that I don't have meetings and save some time for catching up with the mailing lists
09:36tzimmermann: javierm, great. thanks for reviewing. from the 'future directions', you'll see that there's still work to do to reach the full potential. but it should already en par with simpledrm wrt features
09:37javierm: tzimmermann: yes, noticed that there is still work to do on the efistub and futher consolidation with ast and mgag200 for the palette support
09:37javierm: do you know if that grub patch has already been proposed upstream ?
09:38javierm: although I know how hard is to get grub patches merged and most distros just carry a bunch of them out-of-tree :(
10:09sima: vgadrm when?
10:09sima: (we had patches I think over a decade ago for vga helpers)
10:17tzimmermann: javierm, i made that patch, but didn't submit it to upstream. i plan to do so. but i expect that it'll end up in suse's branch of grub2 (together with 270 other ustom patches)
10:19tzimmermann: sima, vgadrm is the end, sort of. we'd need format conversion xrgb8888 to c4 palette. and vga has a custom non-linear framebuffer format, which requires some care to get right. i do have prototype patches, but nothing for upstream yet
10:21javierm: tzimmermann: yeah, I guess so and I'll probably carry in fedora's grub2 branch (more than 200 patches as well...)
10:21tzimmermann: and there's STI on ancient HP. it's still being used by a few people AFAIK. no idea if they'd be interested in DRM support
10:22tzimmermann: javierm, that patch also works on 64-bit machines. i guess grub is 32-bit code?
10:23tzimmermann: for something modern, there's an UEFI call that reads the edid. i briefly moked at how to add this to efistub, but nothing concrete has materialized yet
10:23tzimmermann: s/moked/looked/
10:28tzimmermann: javierm, about the palette helpers: those palettes all have 256 entries. i made little functions for each individual format, but then dropped them from th e series. it's worth a separate patchset
10:37javierm: tzimmermann: yeah, makes sense
10:41crowen: Heyyas. i am running fedora 42 beta and i have updated mesa to latest git and the vulkan-{headers,loader,tools} to 1.4.310. Videocard is a 7900xtx. When trying to run e.g. ptyxis i get: "(ptyxis:320425): Gdk-WARNING **: 11:31:42.232: vkQueuePresentKHR(): A surface has changed in such a way that it is no longer compatible with the swapchain. (VK_ERROR_OUT_OF_DATE_KHR) (-1000001004)"
10:44crowen: Downgrading mesa to mesa-25.0.1 and vulkan-{headers,loader,tools} to 1.4.304 seems to fix the issue.
10:44crowen: I would be thankful for any pointers on how to tackle this further.
10:58crowen: Trying with WAYLAND_DEBUG=1 i see "[3766470.532] {Display Queue} wl_display#1.error(wp_color_manager_v1#48, 1, "surface already requested")"
11:01llyyr: can you show the output of vulkaninfo --summary?
11:02llyyr: if you installed the VK_hdr_layer then remove it with mesa-git
11:03crowen: https://privatebin.net/?b28bd82be0d17192#FZZJXtx6UNKFTfR3GBuEZCAGpUAB18r9GnZ2nuJnQYnE
11:05crowen: you mean that: https://github.com/Drakulix/VK_hdr_layer?
11:05crowen: Not installed.
11:05llyyr: hmm you don't have it, not sure why the surface is already requested then
11:06crowen: I am very willing to provide any info that is helpful.
11:07crowen: I also have a copr repository with the mesa packages i use on top of f42 and updates-testing.
11:09crowen: Last build was yesterday with git5b11c3f
11:40daniels: crowen: can you please run with WAYLAND_DEBUG=1?
11:41crowen: daniels, i did. "Trying with WAYLAND_DEBUG=1 i see "[3766470.532] {Display Queue} wl_display#1.error(wp_color_manager_v1#48, 1, "surface already requested")""
11:41crowen: daniels, do you want the full output of trying to start ptyxis or any other application that fails?
11:41daniels: yeah, I mean to paste the entire output
11:41crowen: daniels, absolutely!
11:41crowen: daniels, give me a second :)
11:42crowen: daniels, https://paste.centos.org/view/9500960a
11:49zamundaaa[m]: crowen: color management in GTK is supposed to be disabled by default
11:49zamundaaa[m]: That's what you're running into - GTK and Mesa try to use it at the same time
11:50zamundaaa[m]: Do you have some GTK environment variable set to change that default?
11:52crowen: zamundaaa[m], not that i am aware of. Let me check.
12:03zamundaaa[m]: Company: until what release did you have the color management protocol enabled in GTK?
12:05zamundaaa[m]: If it was still enabled by default recently, perhaps we should go back on the "use color management with sRGB" thing in Mesa for a while
12:05crowen: zamundaaa[m], gtk4-4.17.6-2.fc42.x86_64 <- thats what i am running... just checking the build options... one minute please.
12:06zamundaaa[m]: IIRC it was an environment variable, not a build option
12:08crowen: zamundaaa[m], okay. i can certainly say though one thing: -Dcolord=enabled \ is whats enabling the feature for the build i am using (fedora 42 beta) (i guess there is a separate on / off switch for the environment)
12:10jannau: color-management was still enabled by default in 4.17.6
12:11jannau: crowen: try after `export GDK_DEBUG=color-mgmt`
12:11crowen: jannau, sure. give me a second.
12:13crowen: Unrecognized value "color-mgmt". Try GDK_DEBUG=help
12:14jannau: sorry, GDK_DISABLE
12:15crowen: ❯ GDK_DISABLE=color-mgmt
12:15crowen: ❯ ptyxis
12:15crowen: (ptyxis:336728): Gdk-WARNING **: 13:14:51.019: vkQueuePresentKHR(): A surface has changed in such a way that it is no longer compatible with the swapchain. (VK_ERROR_OUT_OF_DATE_KHR) (-1000001004)
12:15crowen: Gdk-Message: 13:14:51.019: Error 71 (Protokollfehler) dispatching to Wayland display.
12:15crowen: oops... need to export i guess :D
12:15crowen: yeah, then it opens as expected!