01:06 HdkR: looks like wl_shell internally is nullptr
01:06 HdkR: while it gets the internal wl_compositor
01:10 HdkR: I can see that wayland is sending waffle wl_shm and wl_compositor, no wl_shell
01:11 HdkR: `Note! This protocol is deprecated and not intended for production use. For desktop-style user interfaces, use xdg_shell.`
01:14 endrift: https://github.com/mgba-emu/mgba/issues/1837 here's the bug in question
01:14 HdkR: But I don't have xdg-shell either from weston-info
01:18 endrift: I'm really not sure where to begin here
01:18 HdkR: smells like a waffle limitation
01:20 endrift: uhhh so
01:20 endrift: is this a thing I can fix on my end or not?
01:20 HdkR: wlroots examples create gl instances correctly..hmmm
01:23 HdkR: Guess it would be figuring out how to create surfaces when wl_shell and xdg_shell isn't available
01:23 HdkR: and getting that working in waffle
01:24 HdkR: Probably just using wlroots and throwing everything else in the trash
01:37 endrift: crashed again
01:38 endrift: yeah moving it to the main thread didn't help
02:30 linkmauve: And it’s expected that Sway doesn’t implement wl_shell.
02:31 linkmauve: It’s totally possible that waffle doesn’t support the xdg-shell protocol (so the xdg_wm_base global) yet and thus aborts since it can’t assign a role to its surfaces.
02:31 endrift: I can try using a git build
02:32 kode54: is this waffle?
02:32 kode54: https://github.com/waffle-gl/waffle
02:32 kode54: (hasn't been touched in >3 years)
02:33 linkmauve: kode54, this is waffle: https://gitlab.freedesktop.org/mesa/waffle
02:34 kode54: oh
02:34 kode54: appears to be a newer version of the same thing, which apparently moved off github
02:34 linkmauve: Heh, it doesn’t even build atm. -_-
02:34 linkmauve: Getting a ton of /usr/bin/ld: src/waffle/CMakeFiles/waffle-1.dir/wayland/wayland_platform.c.o:/usr/src/debug/waffle/src/waffle/wayland/wayland_wrapper.h:81: multiple definition of `wfl_wl_proxy_marshal_constructor_versioned'; src/waffle/CMakeFiles/waffle-1.dir/wayland/wayland_display.c.o:/usr/src/debug/waffle/src/waffle/wayland/wayland_wrapper.h:81: first defined here
02:35 endrift: yeah I'm getting the same issue
02:35 linkmauve: Oh, the AUR package is *still* pointing to github.com…
02:36 endrift: oh
02:36 linkmauve: Builds perfectly now that I’m building upstream. :)
02:37 linkmauve: It still uses wl_shell here.
02:37 kode54: https://aur.archlinux.org/packages/waffle/
02:37 kode54: the stable package points to gitlab already
02:37 kode54: god
02:38 kode54: sounds like it isn't really updated anyway
02:38 linkmauve: I apparently commented on that in May: https://aur.archlinux.org/packages/waffle-git/#comment-748194
02:38 linkmauve: Oh look, xexaxo1 did a thing back in March: https://gitlab.freedesktop.org/mesa/waffle/-/merge_requests/68
02:38 linkmauve: And someone did a thing too in July: https://gitlab.freedesktop.org/mesa/waffle/-/merge_requests/76
02:40 kode54: I'll file an orphan request for the git package
02:40 kode54: unless you'd rather
02:40 linkmauve: endrift, so if wayland-info (or weston-info) doesn’t list wl_shell, it’s to be expected that waffle won’t work on your compositor atm.
02:40 linkmauve: kode54, go ahead. :)
02:40 kode54: it appears it hasn't been updated since it was first uploaded in 2017
02:40 linkmauve: I should be in bed, it’s almost 4am. :)
02:40 kode54: I'll file it when I'm in Linux again
02:41 endrift: well, apparently I can't start sway through SDDM for some reason
02:41 endrift: I'm not sure how to debug this
02:42 linkmauve: kode54, there, filed.
02:42 xexaxo1: kode54, linkmauve: yeah, nuking the -git AUR pkg won't be a bad idea.
02:43 linkmauve: xexaxo1, I probably got hit by that already back in May, although I have no recollection of it.
02:43 kode54: xexaxo1: I didn't mean to nuke it, so much as update it
02:43 linkmauve: endrift, Sway doesn’t support wl_shell at all, that’s known and expected.
15:38 HdkR: Yes. GL API and window system selection entirely at run time
15:39 HdkR: Window creation is a bit newer to waffle, it used to be only GL API selection
15:39 HdkR: ...Or I never used it?
18:55 Lyude: MrCooper: well I know we can't rely on a particular value in the X channel of XRGB, I'm just trying to figure out what possible reasons could be behind the weird crc behavior I'm seeing on nouveau
18:57 Lyude: although, a concerning theory I have is this weird behavior with cursors and crcs might just literally be some not-well thought out limitation of how CRCs are implemented for != DP displays on nvidia, since the normal outp CRCs (output paths) have this issue but the SF (symbol formatter) CRCs for DP outputs don't
19:05 danvet: Lyude, the crc should only capture actual color values (but yeah it might be a bit weird)
19:05 Lyude: danvet: yeah-that's what I thought :(
19:06 Lyude: probably won't figure out what's going on until nvidia gets back to me, but I've been bored and throwing stuff at the wall in the mean time to see if it sticks
19:10 Lyude: I just had a realization that the one thing we're not technically setting anywhere in situations where only the cursor is enabled afaik, is a LUT. Which makes me wonder if maybe at the point the CRC is being generated from the raster, maybe the colors are in some mysterious internal pipe format where the reference and cursor image technically differ as a result of the cursor not having a LUT
19:10 Lyude: applied to it, but that difference gets lost in conversion to the pixel data that's actually sent out to the screen
19:11 danvet: Lyude, if your lut interpolates that's easy to get
19:11 Lyude: danvet: ahh, I think it might
19:11 danvet: generally try to disable all that stuff
19:11 Lyude: I'm guessing intel hw does something different?
19:11 Lyude: erm
19:11 Lyude: *similar
19:11 Lyude: completely wrong word there brain
19:11 danvet: our lut is after plane blending
19:12 danvet: iirc amd hw had per-plane bits for "pls go through lut"
19:14 danvet: Lyude, on some of our hw not even 0.0 and 1.0 values really work in the lut/color matrix or alpha blending
19:14 danvet: it's occasionally a bit broken :-/
19:16 Lyude:goes to try to confirm this theory
19:16 danvet: work as in "no crc changes"
19:17 Lyude: danvet: ah, interesting, so you can just have some colors be shown twice and come up with different CRCs each time?
19:17 danvet: I mean with and without lut
19:17 Lyude: ah
19:17 danvet: like you'd expect x * 1.0 = x
19:17 danvet: but our hw tends to disappoint
19:18 danvet: e.g. the alpha blending tests only work with the cursor plane, not the other planes
19:18 danvet: and lots of fun with luts in general
19:19 Lyude: danvet: lol, wouldn't be surprised if it ends up being the other way around here (things working with other planes, but not cursor planes)
19:19 Lyude: cursor planes seem to be pretty "special" on nvidia
20:06 Lyude: mhh, a little less sure on the lut theory now :S, since I don't see any LUTs being set\
22:52 xexaxo1: pq: the waffle user can choose to show the window or not. depending on the test/usecase ...
22:52 xexaxo1: either of those can happen.
22:53 airlied: Kayden: ping
22:54 airlied: or anyone intel who knows how pre-gen6 vs/fs with mismatches outputs/inputs might work
22:58 airlied:hacks u_blitter for now to get around it
23:00 anholt: airlied: what do you mean, exactly?
23:05 airlied: anholt: u_blitter has paths which create an fs that wants a varying with a vs that doesn't give it one
23:06 airlied: anholt: it seems other drivers don't care, but the intel compiler does, I've fixed u_blitter for it locally I think\
23:09 anholt: that's something you have to sort out at some point for SSO, right?
23:12 anholt: I think the brw_link.cpp:unify_interfaces() looks like the thing that makes sure there's urb space for all the used slots
23:14 anholt: looks like iris drives it the other way, with the VS declaring slots_valid
23:14 anholt: (though, let's fix up u_blitter, anyway!)