07:38pq: DodoGTA, wl_data_device.data_offer is an extremely rare example of an event that creates a new protocol object. That error message comes from demarshal, i.e. receiving a message, so I suppose it's a client printing that. Might be due to a compositor bug if not memory corruption.
07:42pq: the actual id is plausible, it's in the server allocation range: 0xff000002
10:46wlb: weston/main: Leandro Ribeiro * color-lcms: do not repeat call to check if log scope is enabled https://gitlab.freedesktop.org/wayland/weston/commit/854631cbf5c8 libweston/color-lcms/color-transform.c
10:46wlb: weston/main: Leandro Ribeiro * color-lcms: print curve sets on pipeline optimizer debug scope https://gitlab.freedesktop.org/wayland/weston/commit/686f0d4f2b03 libweston/color-lcms/ color-transform.c meson.build
10:46wlb: weston Merge request !1245 merged \o/ (color-lcms: print curve sets on pipeline optimizer debug scope https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1245)
13:28DodoGTA: pq: So should I try a different compositor to rule out the first case?
13:28pq: sure, why not
13:29pq: which compositor did you hit it?
13:36DodoGTA: pq: The crash happened on KWin 5.27.5
13:39DodoGTA: But nested sway works fine 🤔️
13:55Max1: Is there a way to get something like Xephyr to run inside a Wayland session on a HiDPI monitor without being blurry?
13:58DodoGTA: Update: I reproduced the same bug on nested sway too 🤔️
13:59pq: I had a feeling it might be timing sensitive.
14:01DodoGTA: So maybe it's some race condition?
14:02pq: could be something the client is doing, someone might be able to spot something in a protocol dump
14:05d_ed[m]: DodoGTA: what's the client?
14:07MrCooper: Max1: there's non-rootless Xwayland, not sure how it handles scaling though
14:08ofourdan: worth a try :)
14:08DodoGTA: d_ed[m}: This might sound weird, but it's Battle.net
14:09DodoGTA: Here's a WAYLAND_DEBUG=1 log BTW: https://pastebin.com/fWL5UDrm
14:11Max1: MrCooper: Didn't know about that mode for XWayland, thanks!
14:11Max1: Unfortunately it's as blurry as Xephyr, but at least it integrates more nicely into Wayland
14:11emersion: mvlad: your blog post says "Wayland's reference compositor", but that's no longer the case
14:16MrCooper: Max1: yeah looks like Xwayland ignores scaling for now, might not be too hard to improve though
14:17Max1: MrCooper: If you tell me where to look and maybe broadly what to change, I can give it a try :)
14:17Vanfanel: Hi. I'm trying to shave off a frame of latency in RetroArch (Wayland + GL, for sytems without a Vulkan implementation), and for that, I am setting a frame callback before calling eglSwapBuffers() and waiting for completion after it: https://pastebin.com/fWCFjhUw
14:18Vanfanel: However, wl_display_dispatch() blocks forever the second time it's called. Any idea on why, please?
14:18MrCooper: Max1: wow, thanks for the offer, I actually meant "not too hard" for someone familiar with Xwayland code though :)
14:19mvlad: emersion, I'll need to ask around. That's been added afterwards.
14:20kennylevinsen: Vanfanel: wl_display_dispatch blocks if there is nothing queued until data arrives. You should mainly call that from your event loop.
14:22kennylevinsen: calling display_dispatch twice in a row without having made any requests is more or less guaranteed to block until the server wants to say something new (e.g., input events)
14:22Max1: MrCooper: Hmm, I've hacked around inside Weston a bit, not sure if that might help me?
14:23Max1: Of course I wouldn't object to someone actually familiar with XWayland doing it, but my use case for this is a talk that I give in ten days, and I can't demand someone else to do it in time (or to do it at all)
14:23Max1: So I'd be happy to invest one or two hours myself, and if that's not enough, one demo in my talk will have to be blurry :)
14:23kennylevinsen: Vanfanel: what ar eyou trying to do specifically?
14:23MrCooper: Max1: are you using integer or fractional scaling?
14:23Vanfanel: kennylevinsen: I am trying to block after eglSwapBuffers() until the new buffer is actually on screen.
14:24Max1: MrCooper: I think I'd be happy to have it work with only integer scaling for now
14:25Vanfanel: kennylevinsen: you can see it on my RetroArch branch here, starting at this line: https://github.com/vanfanel/RetroArch/blob/6ba84554787706e19f58b8fe81c4290140c0077a/gfx/drivers_context/wayland_ctx.c#L526
14:26pq: Vanfanel, did your wl_surface actually get on screen first?
14:27Vanfanel: pq: yes, first frame is onscreen in fact
14:27pq: Vanfanel, is it possible that your gfx_ctx_wl_swap_buffers() is being called from inside a protocol event handler?
14:31pq: Nesting calls to wl_display_dispatch() is not a good idea, so if that happens, remove that first.
14:31pq: is the rest of your program prepared to have event handlers dispatches from inside this "low-level" function?
14:33pq: These are two reasons why trying to implement a blocking function here is hazardous. At the very least there should be a separate wl_event_queue for the event you are waiting to not unintendedly dispatch other events.
14:35pq: The best model would be to simply return to your main event loop instead of blocking, and that requires a bit of a state machine.
14:36MrCooper: Max1: I'd start by remembering the output scale in xserver/hw/xwayland/xwayland-output.c:output_handle_scale and setting the buffer scale when attaching a buffer to the surface
14:38Vanfanel: pq: I don't think it's being called from an event handler, looking at the call stack which is always the same: https://pastebin.com/EXaV5E4k
14:39ofourdan: MrCooper: that would probably not be enough, because the size of the surface must be a multiple of the scale otherwise we'll get an error.
14:40MrCooper: I'm sure there's other pesky details
14:40kennylevinsen: Vanfanel: can you collect the output of WAYLAND_DEBUG=1 when it blocks? One should see if wl_surface.frame request and wl_callback.done event is present
14:40MrCooper: that's just where I'd start the ride :)
14:41Max1: MrCooper: Sounds good, I'll try it next week! Thanks already :)
14:45Vanfanel: kennylevinsen: Of course! Here it's hung blocking: https://pastebin.com/8GGUZA5k
14:47kennylevinsen: hmm, so two frame callbacks (@31 and @32) are being registered, but only the first is seen firing.
14:48MrCooper: the other one is presumably from eglSwapBuffers
14:49Vanfanel: kennylevinsen: yes, only one time the .done callback function is run...
14:49MrCooper: ah, nvm, the other one is from your code as well
14:50kennylevinsen: Vanfanel: In lin 530 you make a reference to a pointer as user data to the surface frame listener
14:51Vanfanel: kennylevinsen: do you mean I should pass the pointer directly?
14:53kennylevinsen: Whatever value you pass is given as-is to your listener
14:53Vanfanel: kennylevinsen: ooowwww.. it works, it works!!!
14:53Vanfanel: thanks, from the bottom of my heart.. thanks really
14:53Vanfanel: I have no words
14:53kennylevinsen: shit happens, you're welcome :P
14:53Vanfanel: That went under my nose for hours and hours...
14:54Vanfanel: kennylevinsen: is there a project I could donate in return for your help?
14:56kennylevinsen: give a buck to a local charity and I'll consider the invoice paid :)
14:57Vanfanel: ok, ok! I will do! This was driving me crazy..
15:56DodoGTA: Is it possible to call both lock_pointer() and confine_pointer() on the same wl_pointer and surface?