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.
<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.
<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
<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
<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...
<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.