ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
nerdopolis has quit [Ping timeout: 480 seconds]
lsd|2 has quit [Remote host closed the connection]
<E_Megas>
Simple question: How do I show the names of all available displays in Wayland? I'm trying to get conky to run wayland-native and need to feed nvidia_display the proper display name.
<E_Megas>
kinfocenter has given me some names, but none of them are working. I need some kind of specific display identifier that this information isn't providing.
mvlad has joined #wayland
E_Megas has quit [Quit: Konversation terminated!]
<davidre>
E_Megas: Without knowing what you want or if you are using some toolkit, wl_output has name and description events
<davidre>
Darn to slow
manuel1985 has joined #wayland
rv1sr has joined #wayland
<davidre>
robert.mader: Sorry for ignoring you on chromium-review. Seems I misconfigured emails somewhere, I just saw your messages from August/October...
glennk has joined #wayland
rgallaispou has joined #wayland
___nick___ has joined #wayland
kts has quit [Ping timeout: 480 seconds]
leon-anavi has joined #wayland
i509vcb has quit [Quit: Connection closed for inactivity]
garnacho has joined #wayland
rasterman has joined #wayland
riteo has quit [Ping timeout: 480 seconds]
bnason has quit [Read error: Connection reset by peer]
bnason has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
<robertmader[m]>
David Redondo: No worries, thanks for working on that protocol!
<Martin42>
Hello Wayland team, I am looking for the documentation of weston.ini, but specific for version 10. I found only this manpage, but it doesn't specify the specific version: https://www.mankier.com/5/weston.ini. Thanks for the help :-)
Brainium has quit [Quit: Konversation terminated!]
glennk has joined #wayland
privacy has joined #wayland
lsd|2 has joined #wayland
mvlad has quit [Remote host closed the connection]
<romangg>
Is wl_display_add_socket_fd used in practice? It was added for some systemd feature https://gitlab.freedesktop.org/wayland/weston/-/commit/265aeb31, but when looking at the source of some wlroots compositors, I didn't see it being implemented there.
<emersion>
it's used by security-context iirc
<romangg>
It's server-side interface though. How would this relate to security-context? Server gets the socket fd from some trusted source?
<romangg>
Ah, the client sends a new fd, then server should add it?
tzimmermann has quit [Quit: Leaving]
<emersion>
yea
leon-anavi has quit [Remote host closed the connection]
<riteo>
mh, quick dumb question: should I manually call `wl_surface_commit`?
<vyivel>
yes?
<riteo>
It looks like obviously when I set a new buffer scale after scaling and commit later for whatever reason before rendering it messes up
<vyivel>
no requests are made automatically
<riteo>
sorry, should've been clearer
<vyivel>
ah
<riteo>
like, we have a vulkan/EGL render loop that internally calls wl_surface_commit
<vyivel>
you have set the buffer scale and the corresponding buffer in the same commit
<riteo>
we can't really do that with Godot
<riteo>
the rendering is done in a whole different place and we don't have any sort of fancy hook for that
<vyivel>
not sure what to do here then
<riteo>
mh, _maybe_ I can set the buffer scale without committing right before drawing
<riteo>
now that you let me think about it
<riteo>
but it feels kinda weird to me. I'm wondering if I should just not call `wl_surface_commit` at every single dumb windowing Godot API call and simply wait for the next frame
<vyivel>
you can, assuming you only commit on render and the next buffer is guaranteed to have the new scale
<vyivel>
"if I should just not call `wl_surface_commit` at every single dumb windowing Godot API call" most probably yes
<riteo>
yes as in "not calling" or yes as in "you should call"
<vyivel>
not calling
<riteo>
mh I see
<vyivel>
i think that's what is usually done actually
<riteo>
it actually makes a lot of sense loll
<vyivel>
just store the new state and remember that a new frame is required or something
<riteo>
mh we've got a pretty generic abstraction
<riteo>
since cross-platform and all that
<riteo>
I _think_ I can just let that queue up in the native wayland event queue and call it a day?
<riteo>
let's see how this goes, thanks for the help!
<vyivel>
until a commit, the pending state will stay pending
<vyivel>
np, good luck
rgallaispou has quit [Quit: Leaving.]
aknot has quit [Ping timeout: 480 seconds]
kasper93_ has joined #wayland
<riteo>
all right, status update: libdecor commits on every operation probably for the same reason we do it too, to make it feel "snappier", as we have no control on whether the drawing thread will stall or slow down for whatever reason
kasper93 has quit [Ping timeout: 480 seconds]
<riteo>
so I just called `wl_surface_set_buffer_scale` right after marking the window for drawing in the frame callback and it seems to work fine, at least on sway!
cmichael has quit [Quit: Leaving]
<riteo>
so, yeah, weird stuff. Maybe one day we'll be able to make rendering better integrated with Wayland, but this will do :)
<MrCooper>
committing every state change separately defeats the purpose of atomic state commits
<riteo>
weirdly libdecor does too
<riteo>
I suppose that it's to avoid for the state to, well, change only between frames
<MrCooper>
it means the user may see inconsistent state, violating the Wayland "every frame is perfect" motto
<riteo>
how can it be inconsistent?
psydroid[m] has joined #wayland
<riteo>
the only inconsistency I've noticed is this buffer scaling one.
<Company>
opaque region can be visible, too, but it's harder to spot
* Company
knows because he fixed a bug with opaque regions yesterday
sevz has joined #wayland
<riteo>
mh
<riteo>
thinking about it, I worked so hard on a separate wayland event thread exactly to uncouple the backend from the renderer (it's currently main-thread and it was giving various issues regarding to event thread overflow)
<emersion>
for instance you were setting the scale separately from the new buffer earlier
<riteo>
I think I can commit during frame callbacks
<riteo>
also I'm not so sure anymore that the WSI actually commits
<emersion>
without atomicity, the user might see a frame with the old buffer scaled
<MrCooper>
riteo: nothing can be presented without a commit :)
<emersion>
for instance, if your window is 100x100 scale 1, then you set scale 2, the window will appear as 50x50
<emersion>
on-screen
<riteo>
emersion: the user will sadly always see some inconsistincies for now as we don't really have much choice when it comes to hooking up with the renderer
<emersion>
later on, your client will commit a proper 200x200 buffer, and the appearance will revert to 100x100
<emersion>
nonetheless, there will be an intermediate bad state
<riteo>
like, if the user has a viewport available and fracscale, it will probably see a frame of a stretched out fame
<Company>
to be fair, getting rendering right on Wayland sucks
<Company>
because GL/Vulkan just randomly call commit()
<emersion>
not randomly
<Company>
and hook random properties
<emersion>
on eglSwapBuffer only
<emersion>
and it's a guarantee
<riteo>
we currently have pretty much only a main thread renderer, so we're handling rendering in a pretty funky way through some signalling and cleverness
<riteo>
hopefully we'll be able to sort this out, perhaps with the multithreaded renderer but I'm not really that experienced with rendering
<Company>
yeah, but feels kinda random - I'd like to have a way where they just attach a buffer and I can call commit myself()
<ManMower>
why?
<Company>
because it forces me to engineer my code around that, by ensuring that I have everything properly set up before calling into the rendering code
mvlad has joined #wayland
<riteo>
yeah I'm having a similar issue
<emersion>
i'd also prefer a WSI which lets you handle the buffers
<riteo>
rn we have backend ticking before the rendering loop
<emersion>
vulkan kinda-of does this
<riteo>
so I don't really have much of a choice on when to commit I think
<ManMower>
istr vulkan mandates a commit in vkQueuePresent
<riteo>
I could do some cleverness at the start but I'd really like to handle this at the frame callback since we also tick independently and also have a separate event handling queue
<Company>
ManMower: yeah, but you can always queue some fancy new extension into it that makes it not do that
<riteo>
mh I think I can definitely reduce the amount of commits though, but I'll still have to be careful and send buffer-related data _after_ my own "custom" commit
<Company>
threaded rendering is another issue - I'd like to have a nice interface at the thread boundary
<MrCooper>
riteo: BTW, I suspect libdecor commits only the synchronized sub-surfaces it uses for the decorations separately, which takes effect only the next time the application commits the parent surface
<Company>
and passing wl_buffers would be a nice interface
<riteo>
MrCooper: nope, it has a special event for committing the toplevel it's attached to
<riteo>
and it calls it every time it changes the title or whatever
<riteo>
it's quite explicitly called `libdecor_frame_toplevel_commit`
<MrCooper>
sounds wonky
<Company>
ie the rendering thread renders to a wl_buffer, hands that off to the main thread, and the main thread can commit() it with everything else
<riteo>
mh, so it looks like it's not really possible to have an absolutely atomic surface update logic, at least with some architectures
<riteo>
am I understanding correctly?
<Company>
currently that doesn't work, both because vkQueuePresent() calls commit() but also because it fiddles with other surface properties - like damage region
<riteo>
(by architecture I'm referring to the actualy way the program is structured)
<MrCooper>
Company: you can do all the Wayland protocol handling yourself if you don't need an EGLsurface
<Company>
MrCooper: yeah, I'm aware - but Mesa has a ton of code around format negotiation that I don't want to copy - because I'll end up with slight differences and then random compositors start breaking
<MrCooper>
another option might be an EGLsurface with the GBM platform
<MrCooper>
guess that won't help for format negotiation though
<Company>
that might change when Vulkan gets more common
<Company>
and GL + Vulkan + another Vulkan config + another Vulkan config + ... start existing
<riteo>
so, I've tried moving all window commits to its frame callback and it's a bit wonky when it comes to viewport scaling :(
<riteo>
it looks like it has a bit of trouble catching up with the flow of reconfigurations
<riteo>
wait I'm making sure
___nick___ has quit [Ping timeout: 480 seconds]
<riteo>
nvm, was always like that. Got influenced by the idea that it might've been worse
<riteo>
it genuinely looks like committing only on frames and only then prepping up buffer-dependant data in preparation for the renderer might be a good compromise
<riteo>
not ideal but I think that it might be better for the whole atomicity thing, right?
<riteo>
oh wait but what about titles changing while the window is tabbed/minimized?
<riteo>
that might be another reason that libdecor instantly commits stuff like title changes, to let them show up when the window is "hidden"
<MrCooper>
show up where, if it's hidden?
<riteo>
dunno, like in the tabbed container of Sway or the icon bar on KDE
<riteo>
there's no actual frame callback getting, well, called, but there's still useful metadata that _has_ to be given through surface committing
<MrCooper>
for consistency, ideally the only surface commit should be the one in eglSwapBuffers / vkQueuePresent
<riteo>
yeah, but it's impossible without losing functionality
<riteo>
stuff like max-min sizes I think could be deferred to the frame callback, but stuff like app id and title must be instantly committed
<MrCooper>
is that double-buffered state in the first place?
<riteo>
mh, IIRC yes, lemme double check
<riteo>
uh
<riteo>
looks like it isn't
<riteo>
sorry
<riteo>
well, this sounds pretty sweet then!
<riteo>
like, all double-buffered state is always visible only per frame so committing it at least there should already improve stuff a lot
<riteo>
I'm not sure if I can get rid of the frame callback commit as for some reason it looks like it doesn't "restart", but that might be just me being dumb
<riteo>
I'd argue that it'd pretty darn close to atomic though if you ask me, so it'd definitely be an improvement I think
<ManMower>
restart? you get one frame callback per wl_surface_frame()+wl_surface_commit()
<riteo>
yeah, but I then destroy it an allocate a new one with wl_surface_frame
<ManMower>
that's appropriate, yeah
<riteo>
but that's the thing, I'd have to commit to "register it" properly
<ManMower>
yeah, it's double buffered state
<riteo>
so we're at two commits, one before rendering and one at buffer presentation
<riteo>
because godot's rendering architecture, and this was already a stretch in some ways
<riteo>
I'd assume that it'd get registered at the buffer presentation but I feel like something goes wrong, probably because we actually use MAILBOX
<riteo>
yeah this gets into cursed stuff territory
<riteo>
basically we "emulate" vsync by messaging to godot when to draw by listening to the frame request
<riteo>
it's ugly ugly ugly _ugly_ but it works good enough for now
iomari891 has quit [Ping timeout: 480 seconds]
<riteo>
yeah all right just realized we can't do better than two commits
<riteo>
I think mostly because the renderer is "lazy", especially in UI only projects, so we're done I think
<riteo>
well, thanks a lot, folks! This was a very educational and useful discussion!
<ManMower>
so you do frame+commit, wait for that, then render+commit, then at some point in the future some kind of event tells you you'd like to generate an image again and you repeat?
<riteo>
so, the new state of things is as such: we frame+commit, set buffer-dependant data and send a message to the main thread to draw which in turn comes to the attention of the main loop that we should draw at this iteration instead of just ticking
<riteo>
thing is, it's not even guaranteed that we'll have a new buffer, unless we tell it that the window size e.g. changed (this includes scaling because we have our own scaling logic)
<riteo>
or the content changes obv
<riteo>
that's not always turned on (e.g. in games its not), but godot has also a lot of UI only projects, such as the editor itself, which use a lazier render mode
<riteo>
as I said this is mostly a hack to not stall the whole main loop since otherwise the driver will wait forever until it gets a frame event
<ManMower>
starting to get that. cursed indeed. :(
<ManMower>
isn't the first frame+commit only really required to get things rolling, and from that point on you could add the wl_surface_frame() call before the render commit?
<riteo>
that's the thing
<riteo>
we _could_
<riteo>
but then it's not _guaranteed_ that we'll actually get a new frame
<riteo>
since lazy rendering
<riteo>
like, if it's a game and doesn't have that feature turned on, cool, but the editor and project manager has it turned on by default
<riteo>
no new frame, no commit
<ManMower>
I mean, you could also post MAX_INT,MAX_INT damage :(
<riteo>
on a "stale" buffer :(
<riteo>
or are you implying that it'd call a new frame event
<riteo>
that would still not unlock the main loop to ask a new draw iteration
<riteo>
consider though that the backend is currently a floating branch PR/MR something, it's not yet merged
<ManMower>
yeah maybe don't do that. I'm not sure what a compositor will make of it.
<riteo>
once it will be we'll perhaps be able to adapt godot better to wayland's particular rendering architecture
<ManMower>
"I never released this buffer, yet you're tellilng me it's dirty? die." seems reasonable
<riteo>
ManMower: indeed
<riteo>
as I said this cursed hack works kinda well, as long as we tick at a reasonable rate
<riteo>
hopefully either with the MT renderer (if that's even a proper solution for this issue) or with some other solution we'll be able to make it cleaner
<riteo>
but we gotta first merge it, which is going to happen soon since 4.3 started a week ago or something
<riteo>
it's a pull-push thing really. "Wayland adapts" a bit, godot "adapts" a bit too
<riteo>
we also have like 5 platforms to support too with the same API after all
<riteo>
maybe more
<riteo>
BTW I'd really be curious to know why libdecor has this whole "let's commit the toplevel" thing
<riteo>
I'm pretty darn sure that it shouldn't care
<riteo>
tbh libdecor's a bit funky, it has some weird bugs, one of which I recently reported. Most of those aren't exactly trivial to fix I think, hence why I didn't make a MR
Moprius has joined #wayland
Rayke has left #wayland [WeeChat 4.1.1]
Brainium has joined #wayland
floof58 has quit [Remote host closed the connection]