ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Lyude has quit [Read error: Connection reset by peer]
Lyude has joined #wayland
ahartmetz has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Company has quit [Quit: Leaving]
nerdopolis has quit [Ping timeout: 480 seconds]
Leopold has quit [Ping timeout: 480 seconds]
sima has joined #wayland
andyrtr has joined #wayland
andyrtr_ has joined #wayland
andyrtr has quit [Ping timeout: 480 seconds]
andyrtr_ is now known as andyrtr
tzimmermann has joined #wayland
junaid has joined #wayland
Cyrinux9 has quit [Ping timeout: 480 seconds]
Cyrinux9 has joined #wayland
manuel1985 has joined #wayland
kts has joined #wayland
<jadahl>
so how are other compositors enforcing `buffer_size % buffer_scale == 2` today? in mutter we started todo, and at first we got crash reports about gtk cursor with custom themes so we disabled it for cursors, but now also it's causing Qt clients to crash left and right too because of it
<emersion>
wlroots is enforcing it, except for cursors
<jadahl>
have you seen any users complaining about it taking down qt clients?
<jadahl>
sendExposeEvent() I guess does the drawing and eventually a eglSwapBuffers()?
kts has quit [Ping timeout: 480 seconds]
i509vcb has quit [Quit: Connection closed for inactivity]
co1umbarius has joined #wayland
<davidre>
jadahl: I just realized I was following the fractional scale code path and you are talking about buffer scale :D
columbarius has quit [Ping timeout: 480 seconds]
<jadahl>
davidre: it seems to be setting a buffer scale yes, but there is a suspiciously similar thing happening in gtk, and the unique thing that both has in common is the egl implementation
rebustosanches has joined #wayland
kts has joined #wayland
gallo has quit [Remote host closed the connection]
<davidre>
I think KWin at the moment is not enforcing it
gallo has joined #wayland
kts has quit [Quit: Konversation terminated!]
MrCooper has quit [Remote host closed the connection]
<pq>
dottedmag, probably not for a typical single-person PC desktop. Multiple wl_seat could be used to expose two independent keyboards with different keymaps for eaxmple.
rasterman has joined #wayland
MrCooper has joined #wayland
nerdopolis has joined #wayland
jmdaemon has quit [Quit: WeeChat 3.8]
<wlb>
weston/main: Alexandros Frantzis * xwayland: Allow shells to make xwayland surfaces fullscreen https://gitlab.freedesktop.org/wayland/weston/commit/ca7b631310ae libweston/desktop/xwayland.c xwayland/window-manager.c xwayland/xwayland-internal-interface.h
<dottedmag>
pq: I guess it would confuse a heck out of any application if one presesd, say, a Ctrl key on one keyboard and a a letter on another.
<dottedmag>
Not a far-fetched situation, actually. Macs with touchbar expose their F-keys as a separate input device, so keyboad (with Fn key) and touchbar have to be in the same seat.
junaid has quit [Ping timeout: 480 seconds]
mvlad has joined #wayland
<pq>
dottedmag, the "independent keyboards" specifically means they are independent. So pressing Ctrl on one would not affect the other.
<pq>
it might confuse end users, or it might be what end users expect - I don't know, because I never use multiple keyboards.
<pq>
such a touchbar would arguably not be an independent keyboard, so it would not be exposed in a separate wl_seat
<pq>
if all three exist at the same time, I guess there is a judgement call (end user preference) to be made, I guess, which big keyboard gets the touchbar
<pq>
ISTR some compositors multiplex multiple keyboards into the same wl_seat by sending a new keymap whenever the end user switches to the other keyboard. That may not support using both keyboards simultaneously either.
junaid has joined #wayland
fmuellner has joined #wayland
Cyrinux94 has joined #wayland
Cyrinux9 has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
carbonfiber has joined #wayland
Company has joined #wayland
rebustosanches has quit []
ahartmetz has joined #wayland
bindu has quit [Quit: leaving]
bindu has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
rv1sr has quit [Ping timeout: 480 seconds]
rasterman has quit [Read error: Connection reset by peer]
rasterman has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
junoidmanoid has joined #wayland
<orowith2os>
is it just me or does wayland-protocols look like it's been getting a lot more attention recently?
<daniels>
a lot more
rasterman has joined #wayland
<emersion>
ever since daniels said we need to share a brain
<daniels>
haha, in fairness that only came up because there'd already been a huge burst of activity over the past couple/few months
junaid has quit [Remote host closed the connection]
ciara has quit [Read error: Connection reset by peer]
ciara has joined #wayland
i509vcb has joined #wayland
nurupo has quit [Quit: nurupo.ga]
nurupo has joined #wayland
opotin65 has joined #wayland
Leopold_ has joined #wayland
junoidmanoid has quit [Remote host closed the connection]
iomari891 has quit [Ping timeout: 480 seconds]
glennk has quit [Read error: Connection reset by peer]
mvlad has quit [Remote host closed the connection]
glennk has joined #wayland
rv1sr has quit [Remote host closed the connection]
rv1sr has joined #wayland
iomari891 has joined #wayland
riteo has joined #wayland
rv1sr has quit [Ping timeout: 480 seconds]
<riteo>
Hi! I'm working on the wayland port of Godot, a game engine with multiwindow capabilities.
rasterman has quit [Quit: Gettin' stinky!]
<riteo>
I'm aware that there have been discussions (I event participated to them) but I have to ask: in the end, what is the solution we want to take with programs with an occluded main thread bound render loop?
<riteo>
I have no idea if this is the right place to ask btw.
<riteo>
Basically, I know that there's presentation v2 being worked on, but someone (I think they were named joshua) in the end discarded the idea of zero extents on vulkan
<riteo>
I'm asking this because I tried implementing multi windowing anyways and "grabby" xdg_popups being dismissed cause a really weird race condition where the renderer stalls because of the fact that they're destroyed immediately server side
<riteo>
This means that godot can't have multi-windowing at all, since not only toplevels can get occluded, but also popups (and they're finnickier overall), stalling everything.
<kchibisov>
Are you talking about frame callbacks not being sent for occluded surfaces?
<riteo>
yes
<kchibisov>
Could godot manage frame callbacks on its own?
<kchibisov>
And not rely on vsync of any sort, so nothing gets blocked?
<riteo>
I'm not sure, platform code is very very isolated from the rendering code
<riteo>
I have no idea how to manually handle frame callbacks.
<kchibisov>
So I think your issue is the same as mine in winit, though, our situation is that we don't have any rendering or graphics initialization.
<riteo>
what do you mean by no graphics initialization?
<kchibisov>
We don't touch OpenGL/vulkan, it's on users.
<kchibisov>
unlike libs like glfw.
<kchibisov>
And we don't do any drawing at all.
<riteo>
oh, godot has some hooks for OpenGL and Vulkan when it comes to initializing both of them and has hooks for calling stuff like swap_buffers on OpenGL
<kchibisov>
So, you could ask frame callback before you call swap buffers for example.
<kchibisov>
if it's all hooked.
<riteo>
mh
<kchibisov>
That's whay vsync is doing btw.
<riteo>
that wouldn't still fix vulkan
<kchibisov>
it simply ask for frame callback and waits for them.
<kchibisov>
yeah, you'd need the same hook for vulkan.
<riteo>
the issue is that vulkan viewport stuff is actually initialized/cleaned core-side
<riteo>
also, wouldn't waiting for the frame callback cause a stall still?
<kchibisov>
in winit, for example, we agreed on having a hook on a Window called "pre_present_notify", so users could notify winit about presenting something and winit could schedule frame throttling hint.
<kchibisov>
You don't wait, you send a user event back saying that you can draw.
<kchibisov>
Once you receive a frame callback.
<riteo>
oooh all right
<riteo>
we have some "can_draw" getters but I'm not sure they'd be reliable enough
<kchibisov>
And you can do the same thing on all platfroms to get non blocking drawing at refresh rate.
<riteo>
draw notifications sound like a nice workaround
<kchibisov>
I mean you could try your best to provide all the bits for users trying multiwindow, it's not like vsync breaks in single window.
<kchibisov>
it's not really a workaround, you have something like that on macOS.
<kchibisov>
And Windows.
<kchibisov>
On macOS there's a drawRect when the system really wants you to redraw.
<kchibisov>
So you have notifications from the OS comming that you must redraw.
<riteo>
oh. I'm pretty sure that godot just calls the render loop and if, in the case of Vulkan, it gets null extents it treats the surface as minimized and goes on
<riteo>
that's the mess, it relies heavily on the WSI
iomari891 has quit [Ping timeout: 480 seconds]
<kchibisov>
it's true that you can use presentation feedback to do manual scheduling on some platforms.
<riteo>
actually there's a proposal for presentation v2 which adds a "suspended" state for surfaces
<kchibisov>
(e.g. macOS with display link).
<riteo>
and the idea is that the WSI could in theory use that to signal minimized windows
<kchibisov>
I remember reading about something like that, but it was a long ago.
<kchibisov>
It's true that other Oses have Occluded feedback, like macOS/X11.
<riteo>
that's what godot expects and that's the mess
<kchibisov>
s/Oses/display servers/
<riteo>
with X11 it returns whether the window is minimized through WM_STATE_HIDDEN or something named like that
<riteo>
with Windows it checks for null extents
<riteo>
with MacOS I have no idea :P
<kchibisov>
Is godot event driven or it's some sort of regular pumping like a 'real game engine'?
<riteo>
yup, it's a dumb loop
<riteo>
there's a "window can draw" getter but it's that, a getter
<kchibisov>
Yeah, so you likely never targetted anything other than desktops for real.
<riteo>
there's also android and ios support
<kchibisov>
Oh, but how dump loop handles suspend/resume?
<riteo>
I think they just freeze? Lemme check
<riteo>
yup
<riteo>
"window_can_draw" always return true
<kchibisov>
Oh, that's interesting, given that your resources are destroyed and you'll get egl/vulkan errors if you try.
<kchibisov>
Though, maybe your loop isn't { collect_events(); do_drawing(); }.
<kchibisov>
The issue though, is that you can't really do synchronious event handling like some display systems want.
<kchibisov>
like macOS sometimes expects sync reply to events.
<kchibisov>
Because 'everything is on the main thread'.
<riteo>
that's funny because wayland expects the exact opposite
<kchibisov>
writing crossplatform stuff like that is a good way to establish your constant suffering.
* kchibisov
is writing it for 4-5 years...
* riteo
*shrugs*
<riteo>
that's the platform port maintainer life ig
<kchibisov>
Wayland is the nicest one, because you can tune it to work with everything.
<riteo>
...sort of
<riteo>
the grabby popup deletion order is another mess but that's way more manageable than occluded surfaces stalling the renderer or even hardlocking it
<kchibisov>
That's just the design you've opted in.
<riteo>
not me, I'm new-ish here :P
<kchibisov>
you as in godot.
<riteo>
oh all right
<kchibisov>
If it was event driven you were fine.
<riteo>
that said, we do have a single-window mode which works fine enough (ignoring the render loop stalling) but good luck telling users that you can't use the new hyped feature
<riteo>
I could try using window_can_draw as a way of signaling drawing but I fear race conditions
<riteo>
the wayland event loop is on a thread, the rendering one on another and the compositor is another process entirely
<kchibisov>
riteo: frame callback request is sent on surface commit.
<kchibisov>
if you commit from rendering thread it'll be fine.
<kchibisov>
like you could ask the callback on your main thread, but commit on other thread just fine, because the callback won't be sent until you commit.
<kchibisov>
And you commit with swap_buffers/vulkan stuff.
<riteo>
oh I see
<kchibisov>
that's why we decided to go with `pre_present_notify` hook, so users could simply tell winit to schedule something for them, but the actual delivery is on the user, since they must ask `request_redraw` to get a throttling hint.
<kchibisov>
Just ensure when doing that sort of things, with frame callbacks from different thread that commit is entirely on the user.
<kchibisov>
Then your can_draw function could align with Wayland common rendering loop, since the users can if (!can_draw()) { continue; }
<riteo>
That sounds a pretty good plan, I'm a bit confused on one thing
<riteo>
The commit is probably done very close to the method that actually stalls, so we can't rely on _that_ commit. We could commit in `can_draw` but we'd have to do a wl_display_roundtrip and hope that it comes after the roundtrip but I'm not sure that's guaranteed
<riteo>
nor by design
sima has quit [Ping timeout: 480 seconds]
<kchibisov>
riteo: disable vsync.
<kchibisov>
Or not allow users set it on Wayland.
<kchibisov>
And instead suggest them to call something like pre_present_notify and signal it from the can_draw().
<riteo>
That's doable. Has TEARING support been merged in Mesa? IIRC it hasn't yet
<kchibisov>
I've asked the other day and got a reply as 'not yet'.
<riteo>
that's a bit of an issue
<kchibisov>
The thing is that wayland vsync is different to what you're used to.
<kchibisov>
it's the same frame callbacks.
<kchibisov>
it's just mesa blocks and waits for them to get back, that's why you have stalling.
<riteo>
yeah, but that's because it has no tools to not stall
<riteo>
that's the idea with wp_presentation_v2
<kchibisov>
Yeah, but the thing is that everything goes through compositor.
<kchibisov>
you have tools to not stall, disable vsync.
<zamundaaa[m]>
riteo: toplevel suspension has nothing to do with that
<riteo>
yeah ik
<riteo>
It was just to clarify the MRs I meant
<riteo>
they've been split exactly because of the fact that it has nothing to do with that
<riteo>
sorry for the misunderstanding, I know that it has been for some reason a pretty delicate subject, especially after the mesa 1hz MR
<riteo>
BTW we do support mailbox. I can try that
junaid has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
<riteo>
oh well, it seems to definitely avoid the issue
<riteo>
thanks for the tip!
<riteo>
I guess that this could be a good enough workaround. I would still like to know the proper way forward though but I suppose I should talk about it in the relevant MR, shouldn't I?
<riteo>
Because of the person discarding the proposal for zero extents
<riteo>
*null extents
<riteo>
anyways, thanks for everything folks! This motivated me further to keep trying to make this work!
<riteo>
I think I'll go for now, cya!
riteo has quit [Quit: epic mailbox moment]
Moprius has joined #wayland
Moprius has quit []
junaid has quit [Remote host closed the connection]