ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
paulk-ter has joined #wayland
paulk-bis has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
paulk-ter has quit [Remote host closed the connection]
paulk-ter has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
paulk-ter has quit [Remote host closed the connection]
paulk-ter has joined #wayland
paulk has joined #wayland
paulk-ter has quit [Ping timeout: 480 seconds]
molinari has quit [Remote host closed the connection]
molinari has joined #wayland
molinari has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
Company has quit [Quit: Leaving]
nerdopolis has quit [Ping timeout: 480 seconds]
dcz_ has joined #wayland
sima has joined #wayland
iomari891 has joined #wayland
andyrtr_ has joined #wayland
andyrtr has quit [Ping timeout: 480 seconds]
andyrtr_ is now known as andyrtr
molinari has joined #wayland
tzimmermann has joined #wayland
neonking has quit [Quit: Leaving]
<pq>
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.
<pq>
the actual id is plausible, it's in the server allocation range: 0xff000002
Dami_Lu has quit [Ping timeout: 480 seconds]
Dami_Lu has joined #wayland
pochu has joined #wayland
rasterman has joined #wayland
neonking has joined #wayland
cmichael has joined #wayland
kts has joined #wayland
fmuellner has joined #wayland
neonking has quit [Remote host closed the connection]
<Max1>
MrCooper: Didn't know about that mode for XWayland, thanks!
<Max1>
Unfortunately it's as blurry as Xephyr, but at least it integrates more nicely into Wayland
<emersion>
mvlad: your blog post says "Wayland's reference compositor", but that's no longer the case
<MrCooper>
Max1: yeah looks like Xwayland ignores scaling for now, might not be too hard to improve though
<Max1>
MrCooper: If you tell me where to look and maybe broadly what to change, I can give it a try :)
<Vanfanel>
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
<Vanfanel>
However, wl_display_dispatch() blocks forever the second time it's called. Any idea on why, please?
<MrCooper>
Max1: wow, thanks for the offer, I actually meant "not too hard" for someone familiar with Xwayland code though :)
<mvlad>
emersion, I'll need to ask around. That's been added afterwards.
<kennylevinsen>
Vanfanel: wl_display_dispatch blocks if there is nothing queued until data arrives. You should mainly call that from your event loop.
<kennylevinsen>
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)
<Max1>
MrCooper: Hmm, I've hacked around inside Weston a bit, not sure if that might help me?
<Max1>
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)
<Max1>
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 :)
<kennylevinsen>
Vanfanel: what ar eyou trying to do specifically?
<MrCooper>
Max1: are you using integer or fractional scaling?
<Vanfanel>
kennylevinsen: I am trying to block after eglSwapBuffers() until the new buffer is actually on screen.
<Max1>
MrCooper: I think I'd be happy to have it work with only integer scaling for now
<pq>
Vanfanel, did your wl_surface actually get on screen first?
<Vanfanel>
pq: yes, first frame is onscreen in fact
<pq>
Vanfanel, is it possible that your gfx_ctx_wl_swap_buffers() is being called from inside a protocol event handler?
kasper93_ has joined #wayland
kasper93_ has quit [Remote host closed the connection]
<pq>
Nesting calls to wl_display_dispatch() is not a good idea, so if that happens, remove that first.
<pq>
is the rest of your program prepared to have event handlers dispatches from inside this "low-level" function?
<pq>
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.
<pq>
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.
<MrCooper>
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
kasper93 has quit [Ping timeout: 480 seconds]
<Vanfanel>
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
<ofourdan>
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.
<MrCooper>
I'm sure there's other pesky details
<kennylevinsen>
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
<MrCooper>
that's just where I'd start the ride :)
<Max1>
MrCooper: Sounds good, I'll try it next week! Thanks already :)