ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
fmuellner has quit [Ping timeout: 480 seconds]
Guest5049 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest5111
simpleman has joined #wayland
sima has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
systwi has quit [Ping timeout: 480 seconds]
systwi has joined #wayland
simpleman has quit [Quit: WeeChat 3.8]
systwi_ has joined #wayland
systwi has quit [Ping timeout: 480 seconds]
systwi_ has quit []
systwi has joined #wayland
ids1024 has joined #wayland
ids1024 has quit []
ids1024 has joined #wayland
junaid has joined #wayland
junaid has quit [Ping timeout: 480 seconds]
junaid has joined #wayland
rv1sr has joined #wayland
manuel1985 has joined #wayland
TheCompany has quit []
mvlad has joined #wayland
rasterman has joined #wayland
tzimmermann has joined #wayland
paramount has joined #wayland
paramount has quit [Remote host closed the connection]
paramount has joined #wayland
caveman has joined #wayland
cvmn has quit [Remote host closed the connection]
iomari891 has joined #wayland
paramount has quit [Ping timeout: 480 seconds]
<pq> kchibisov, I don't understand why you would need to know when the compositor is done destroying things. The moment a client sends a destroy request, the protocol object is gone from client perspective. Any incoming event marshalling in the client would drop events coming through the destroyed object, and turn event arguments with the destroyed object to NULL.
<pq> kchibisov, not reading the connection is hazarduous; the compositor might even add and remove wl_registry globals enough to overflow the connection buffers.
<pq> swick[m], how would a client know which parts of such profile a compositor is applying and which not? Or does it make no difference?
<pq> swick[m], hmm, I guess it makes no difference if the client is also using the same image description for its surface.
<kchibisov> pq: I might have profiled the issue wrong, but I think my surface was still shown even though I've destoreyed it.
<kchibisov> And only roundtrip made it go away.
<kchibisov> The issue though is that we can't really destroy the event loop, but we want suspend it after it run for a while.
<pq> kchibisov, yes, compositors can keep showing your surface after you have destroyed it, and even after the compositor has fully processes the wl_surface destruction.
<pq> but it'll be just a frozen image as the client obviously has no means of updating it anymore, and the compositor has no means of sending e.g. input to it anymore
<pq> it's mostly used for window closing animations
<kchibisov> But why they show it indefinitely, if everything related to it is gone?
<pq> sounds like compositor bug?
<pq> or maybe you didn't actually flush the destroy request out?
<kchibisov> Hm, that could also be the case.
<pq> kchibisov, if you do a protocol dump on the compositor side, that would tell if you forgot to flush.
<kchibisov> Yeah, I've added a flush and it worked.
<pq> cool
<pq> usually a flush cannot be forgotten, because the main event loop always flushes before sleeping
<kchibisov> Now I wonder what should I do wrt not reading connection. Maybe I should start a background thread on demand?
<pq> Any reason you can't simply let your main event loop sleep and run?
<kchibisov> I can't in this case.
<pq> why?
<kchibisov> API parity.
<pq> *facepalm*
<pq> well, another approach is to have a separate reading thread always.
<kchibisov> it just comes from macOS where you can't destroy the loop. And there's a demand to run event loop for a short period of time and destroy everything when returning from event loop callback.
<pq> is this using libwayland-client or something else?
<kchibisov> Partially yes.
<kchibisov> I suspend the loop only after destroying everything though.
<pq> that demand sounds quite wonky
<kchibisov> you can't recreate the event loop on macOS.
<pq> I'm confused why anyone would even want to destroy the event loop unless the process is exiting.
<kchibisov> The don't want to run the event loop on constant basis.
<kchibisov> Because they have their own event loop.
<pq> why? it just sleeps when there is nothing to do, right?
<kchibisov> It's not like you have epoll everywhere, so you have to actually run and listen.
<kchibisov> Which they don't want to.
<pq> it's conceptually impossible to have two main event loops, and a bad idea to have multiple event loops. They should be properly integrated into one instead.
<pq> epoll is not the only way to integrate events loop, though it is likely one of the simplest
<pq> *event loops
<kchibisov> Be aware that event loop means not display server loop or even Wayland related loop.
<pq> I know.
<pq> It sounds like home-grown event loops that are not portable enough. Using a proper portable event loop library would solve that, but it also ties one to the library.
<pq> Any design where a single thread is expected to spin more than one independent event loop seems like a very bad idea to me. I'm sorry if others have decided to impose that on you.
Dami_Lu has quit [Ping timeout: 480 seconds]
jmdaemon has quit [Ping timeout: 480 seconds]
manuel1985 has quit [Remote host closed the connection]
manuel1985 has joined #wayland
<kchibisov> Are you aware that macOS or Windows event loop can't integrate into anything?
<pq> No, but I'm also not surprised: everyone is supposed to use them and nothing else, right?
Dami_Lu has joined #wayland
<kchibisov> They simply run macOS loop ondemand, because it's a gui only thing.
<kchibisov> And the rest handle with kqueue.
<pq> oh, I didn't expect the OS to conflict itself like that. How does it work at all?
<kchibisov> At least I've seen things like that...
<kchibisov> They have special proprietary stuff for their gui stuff.
<kchibisov> It's TCP connection iirc, but it's not near stable.
<pq> Do you have to choose a thread being either gfx or non-gfx, and switching or combining is not possible?
<pq> or is it even a process-wide decision?
<kchibisov> I don't quite understand that, but the thread for GUI is bound to main application thread.
<kchibisov> And if you try to touch gui stuff outside of it it sigills.
<pq> ok, that sounds extremely painful for any library that would like to be portable
<kchibisov> That's the reason I don't look into macOS that much myself.
<pq> and the library really odd to use for anyone who hasn't developed for macOS
<kchibisov> Well, you can make X11/Wayland behave.
<pq> yeah, but the library API has to live by the most restrictive OS it supports, and that would be surprise to a library user who doesn't know the most restrictive OS
<pq> imposing restrictions and designs that seem unncessary on everything one knows about
<kchibisov> We have alternative event loop APIs. The common one assumes that you run everything from the event loop.
<kchibisov> And you can't rerun it.
<pq> On one hand, it makes perfect sense to me that all GUI stuff is limited to one thread at a time, and exiting the event loop means closing the display connection. That's how Wayland was supposed to work originally.
<kchibisov> The most restrictive is iOS though, but we gave up on idea to design around it.
<pq> aha
<kchibisov> You simply setup a callback for it and then you pass the entire control flow from your app to ffi function.
<kchibisov> The similar situation is on wasm, your code is run async by the browser so you can't just block in `main` and wait for event loop to exit.
<kchibisov> So we sort sort of decided that ppl who really want to deal with all of that are on their own and we just try our best to provide robust handling of all of that.
<kchibisov> GUI toolkits are expected to wrap all of that mess into something nice, like they could all make a #[my_gui_toolkit:entry] and handle all event loop details for the users.
<kchibisov> Such wierd platforms come with an extra glue code you must write inside your main, like setuping subclass of java activity class on android.
<wlb> wayland-protocols Issue #151 opened by Simon Ser (emersion) Members meetings https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/151
fmuellner has joined #wayland
<emersion> drakulix[m]: ^
<pq> btw. when I said "all GUI stuff", that excludes actual drawing.
<wlb> weston Issue #772 opened by Jim B (d3x0r) WSL2 and xwayland cause weston to crash https://gitlab.freedesktop.org/wayland/weston/-/issues/772
<any1> What about adding a new namespace that's like ext but with even lower "priority"? Could be called opt for optional?
junaid_ has joined #wayland
junaid has quit [Ping timeout: 480 seconds]
Leopold has quit [Remote host closed the connection]
paramount has joined #wayland
<wlb> wayland-protocols Merge request !230 opened by Jonas Ådahl (jadahl) xdg-shell: Add edge constraints https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/230 [xdg-shell], [In 30 day discussion period], [Needs acks], [Needs review], [Needs implementations]
junaid_ has quit [Remote host closed the connection]
junaid has joined #wayland
pochu has joined #wayland
<wlb> wayland-protocols Merge request !231 opened by Jonas Ådahl (jadahl) Add staging system bell protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/231 [In 30 day discussion period], [New Protocol], [Needs acks], [Needs review], [Needs implementations]
<jadahl> drakulix[m]: mind if I edit notes from yesterday to add the part about the known type-to-search bug and the intended fix & action item?
<jadahl> oh you added! nm
<drakulix[m]> That one should be in there, but no in general I don't mind other people editing it, that is why I added the disclaimer at the top.
<jadahl> ah, missed that
<jadahl> interesting, can't edit
<jadahl> maybe we should use the wiki instead after all
<jadahl> which someone would need to enable I guess, I don't have enough super powers
<drakulix[m]> I guess you could reply to the comment to add to the notes?
<drakulix[m]> The only thing that is annoying with an issue is correcting other people, maybe that is not a huge deal?
<jadahl> not super huge, but messier than just collaboratively editing a notes document
<drakulix[m]> I am not opposed to use a wiki instead, but I can't enable that either. ^^
<jadahl> what I wanted to add was the action item that carlos was going to find the draft protocol change for the type-to-search fix
<drakulix[m]> I'll quickly add that, while we discuss moving to a wiki.
<jadahl> thanks
<drakulix[m]> jadahl: Do you know if GTK does anything with the "tiled_*" xdg-shell state today?
<drakulix[m]> Or in general does anyone have any examples for any toolkit for that matter? I can't find the original motivation for these states.
<jadahl> it should
<vyivel> i think it affects e.g. whether the window corners are rounded
<jadahl> it's more or less about not showing shadow on those edges
<jadahl> yea that kind of stuff
<drakulix[m]> vyivel: It certainly doesn't for GTK.
<jadahl> it does *some* things, can't remember what
<drakulix[m]> We briefly talked about rounded corners yesterday, is that something we might want to tie more closely to the tiled state?
<jadahl> you need gtk 4.9.2 it seems
<jadahl> my tiled gtk windows have square corners
<drakulix[m]> hmm, gtk4 in fedora should be 4.10, maybe it's an issue on my side then. thanks
<jadahl> drakulix[m]: https://i.imgur.com/Dj2oIfB.png as square can be
Leopold has joined #wayland
<Max1> drakulix: Chromium doesn't show CSDs on edges that are tiled
FLHerne has quit [Quit: There's a real world out here!]
nerdopolis has joined #wayland
<drakulix[m]> thanks!
FLHerne has joined #wayland
<wlb> weston Issue #773 opened by Baskar R (baskar_forum) weston-screenshooter https://gitlab.freedesktop.org/wayland/weston/-/issues/773
Moprius has joined #wayland
navi has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
<pq> At least I have the power to edit drakulix[m]'s gitlab comment (minutes), so maybe jadahl could have too.
<jadahl> pq: I think it's because you have a 'maintainer' role in gitlab. i don't.
<pq> surely about role, yeah
<pq> Then again, if you want to go for a wiki, I guess that's fine, but then also consider having a git repository with minutes if you want full access control and traceability.
<jadahl> a wiki has history
<emersion> yeah, i asked about wiki in the meeting, but then ultimately got lazy and opened an issue
<emersion> i'll enable the wiki
<pq> ah, edit anyone's comments is a Maintainer or Owner power.
<pq> make sense
<wlb> wayland-protocols Issue #151 closed \o/ (Members meetings https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/151)
Moprius has quit [Quit: bye]
andyrtr has joined #wayland
kts has joined #wayland
pbsds has quit [Quit: The Lounge - https://thelounge.chat]
kts has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
<davidre> emersion: Maybe make the meetings separate
<davidre> the page is going to be very long very fast
<davidre> and gitlab offers no jump labels or anything
<emersion> we can always split when need be
<davidre> Sensible
<emersion> and the most recent meetings are at the top
<davidre> 👍️
<davidre> the real gitlab pro there :)
<emersion> didn't know, done
kts has joined #wayland
kts has quit [Quit: Konversation terminated!]
<emersion> MrCooper: hmm, it seems like my compositor is still stuttering when i run very demanding clients, send them frame callbacks, but don't use their DMA-BUF at all…
<emersion> (with a high priority EGL context, on Intel)
<emersion> maybe i'm hitting a case where i can't do anything about it, the GPU is busy so my work is delayed even if i don't implicitly wait on buffers…
<MrCooper> what clients specifically? The GPU HW/driver/firmware preemption capabilities are limited
<emersion> compositor-killer configured so that the work takes >150ms
<emersion> right
<MrCooper> it works well for me with GpuTest plot3d, but not with pixmark_piano
rasterman has quit [Quit: Gettin' stinky!]
<emersion> i don't get stuttering running gputest plot3d with a naive compositor
<MrCooper> did you tweak its parameters as described on https://gitlab.gnome.org/GNOME/mutter/-/issues/1162 ?
<MrCooper> the default parameters are light
nerdopolis has joined #wayland
<emersion> thanks, this works!
pochu has quit [Quit: leaving]
<pq> oh dear, I just found the CTA-861 table whether quantization is limited or full range for each combination of colorimetry and CE vs. IT vide format.
<pq> *video format
tawonga1 has joined #wayland
<emersion> a simple flag would've been too much to ask, clearly
tawonga has quit [Ping timeout: 480 seconds]
kts has joined #wayland
<swick[m]> how could anyone possibly get any of this wrong
immibis has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<kchibisov> Is tearing control of any use for regular shm clients? I'd assume not really due to the way it works and it can only work for real with the dmabuf?
immibis has joined #wayland
manuel1985 has quit [Ping timeout: 480 seconds]
<emersion> it could be used, a CPU->GPU copy is not super different from a GPU->GPU one
<emersion> from a tearing PoV
<kchibisov> Hm, I was somehow thinking of a case where you are doing direct scanout.
<zamundaaa[m]> There is no direct scanout with shm, but you don't need direct scanout for tearing
<kchibisov> I mean, that's expected, I was thinking of dmabuf path.
<kchibisov> But yeah, given that it's all non-blocking basically it doesn't really matter for the compositon time...
<wlb> weston/main: Marius Vlad * clients/window: Update min_allocation for smaller widths/heights https://gitlab.freedesktop.org/wayland/weston/commit/955511809558 clients/window.c
<wlb> weston Merge request !1298 merged \o/ (clients/window: Allow smaller pending allocation in clients https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1298)
Company has joined #wayland
junaid has quit [Ping timeout: 480 seconds]
<wlb> weston Issue #774 opened by Kirill Primak (vyivel) NULL pointer dereference when an xdg_surface role object is recreated https://gitlab.freedesktop.org/wayland/weston/-/issues/774
jmdaemon has joined #wayland
danshick has quit [Remote host closed the connection]
danshick has joined #wayland
<wlb> wayland Merge request !326 opened by Sebastian Wick (swick) server: add const qualifier to function arguments where possible https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/326
pbsds has joined #wayland
<dottedmag> Is there a use-case for multiple wl_seats for a typical PC desktop/laptop configuration? Or multiple wl_seats are for embedded/specialized cases?
tzimmermann has quit [Quit: Leaving]
jmdaemon has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
Guest5111 has quit []
zvarde1988303206779191681 has joined #wayland
cool110 has joined #wayland
zvarde198830320677919168 has quit [Ping timeout: 480 seconds]
zvarde1988303206779191681 is now known as zvarde198830320677919168
cool110 is now known as Guest5164
jmdaemon has quit [Ping timeout: 480 seconds]
jlco has quit [Quit: No Ping reply in 180 seconds.]
<kchibisov> When reading `wl_data_device::selection` it's very confusing how to even track what it wants.
<kchibisov> It says ' The data_offer is valid until a new data_offer or NULL is received or until the client loses keyboard focus'
<kchibisov> ' Switching surface with keyboard focus within the same client doesn't mean a new selection will be sent'
<kchibisov> So if I have 2 windows how would I even track that to call `destroy` as the spec wants?
tlwoerner has quit [Ping timeout: 480 seconds]
<kchibisov> For now it all reads like you must check with some debouncing that none of your clients windows got a keyboard focus then you got to you data offers and rip them.
<kchibisov> which is just horrible to write in clients.
jlco has joined #wayland
<kchibisov> Or was the intent of the message in the spec to say that I must not try to use that offer once I don't have any keyboard focus in any of my clients windows?
<emersion> do you not have only one data device and keyboard, regardless of number of toplevels?
<kchibisov> I have, but how do you know that you changed focus from one to another.
<kchibisov> my understanding is that there's no guarantee that wl_keyboard::leave and wl_keyboard::enter will arive at the same time.
<kchibisov> Like what if the server delivered them with the delay.
<kchibisov> And at which point I should run the cleanup logic, I can't run it from the `leave` handler as I wanted for example.
<kchibisov> Because leave will arrive before I could get enter, so I have a state during dispatching the callbacks when my client doesn't have a focus at all.
Cyrinux9 has quit []
<kchibisov> And then we have zwp_primary_selection, with a different wording for the exact same event.
<kchibisov> It would be much better if server would just send a NULL once they decide that client lost focus.
Cyrinux9 has joined #wayland
<kchibisov> vyivel: yeah, sort of that. Though, the particular issue could be solved by compositor sending NULL.
<kchibisov> Because it "clearly knows when my client lost the focus".
jlco_ has joined #wayland
jlco_ has quit []
jlco_ has joined #wayland
kts has quit [Quit: Konversation terminated!]
jlco has quit [Ping timeout: 480 seconds]
<wlb> wayland-protocols Merge request !232 opened by Sebastian Wick (swick) security-context-v1: Document out of band mechanism and clarifications on socket usage https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/232
jlco_ has quit []
jlco has joined #wayland
jlco has quit []
Leopold has quit [Remote host closed the connection]
jlco has joined #wayland
jlco has quit []
Leopold has joined #wayland
jlco has joined #wayland
paramount has quit [Remote host closed the connection]
manuel1985 has joined #wayland
tlwoerner has joined #wayland
<wlb> wayland Issue #392 opened by Kirill Chibisov (kchibisov) No way to robustly handle `{wl_data,zwp_primary_selection}_device::selection` assumptions https://gitlab.freedesktop.org/wayland/wayland/-/issues/392
___nick___ has joined #wayland
jmdaemon has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
modin has quit [Quit: ZNC 1.8.2 - https://znc.in]
modin has joined #wayland
<wlb> weston/main: Marius Vlad * desktop-shell: Use a common helper to handle surface resizes https://gitlab.freedesktop.org/wayland/weston/commit/ecab79bfb7cd desktop-shell/shell.c
<wlb> weston/main: Marius Vlad * desktop-shell: Keep track of shsurf being created/removed https://gitlab.freedesktop.org/wayland/weston/commit/aeabba8e1873 desktop-shell/ shell.c shell.h
<wlb> weston/main: Marius Vlad * desktop-shell: Handle all other shsurfs https://gitlab.freedesktop.org/wayland/weston/commit/eefd8ae2e011 desktop-shell/shell.c
<wlb> weston Merge request !1299 merged \o/ (desktop-shell: Handle all other shell surfaces in case of an output resize https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1299)
sbine has joined #wayland
Narrat has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
___nick___ has quit []
ahartmetz has joined #wayland
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
Guest5164 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest5184
mvlad has quit [Remote host closed the connection]
jmdaemon has quit [Ping timeout: 480 seconds]
pq has quit [Ping timeout: 480 seconds]
___nick___ has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
Brainium has joined #wayland
rv1sr has quit []
sbine has quit [Quit: sbine]
xhivo97 has joined #wayland
xhivo97 has quit [Remote host closed the connection]
lsd|2 has joined #wayland
<lsd|2> kubuntu 23.04 doesnt wake up from suspend. wayland in use, didnt try on x11 but should survive suspending
<lsd|2> any ideas
<lsd|2> where to search
<lsd|2> commands, pastes?
<dottedmag> lsd|2: Please ask in Kubuntu support channel
<lsd|2> ok i will thanks
<wlb> weston Merge request !1303 opened by Sergio Gómez (SergioGDR) Improve fullscreen handling in Xwayland https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1303
lsd|2 has quit [Quit: KVIrc 5.0.1 Aria http://www.kvirc.net/]
manuel1985 has quit [Ping timeout: 480 seconds]
jmdaemon has quit [Ping timeout: 480 seconds]
Narrat has quit []
jmdaemon has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
pq has joined #wayland