ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
columbarius has joined #wayland
zebrag has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
floof58 is now known as Guest2416
floof58 has joined #wayland
Guest2416 has quit [Ping timeout: 480 seconds]
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
smallville7123 has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
mxz has quit [Quit: cya]
mxz has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
Dami_Lu has joined #wayland
<repetitivestrain>
how exactly do clients communicate the fractional scale to the server?
<repetitivestrain>
under the fractional scaling protocol
<repetitivestrain>
or is the viewport dest size specified in device pixels?
Company has quit [Quit: Leaving]
<smallville7123>
does the compositor run with vsync or no vsync?
<smallville7123>
and what happens when a client runs with vsync and another with no vsync
<repetitivestrain>
smallville7123: if you're referring to the tearing control protocol, afaiu compositors are just supposed to ignore the hint if it's not actually flipping only the surface to the crtc
<smallville7123>
like, the compositor FPS vs the client's FPS
<smallville7123>
eg, if the client has a FPS of 400, would the compositor also have an FPS of 400 ? assuming client has vsync disabled
<repetitivestrain>
smallville7123: nobody knows
<repetitivestrain>
the compositor can do whatever it wants
<repetitivestrain>
also by "fps" i presume you mean the client is committing at 400 fps
<repetitivestrain>
400 hz*
<repetitivestrain>
but - if it does that - then it is at least wasting a lot of battery
smallville7123 has quit [Ping timeout: 480 seconds]
danvet has joined #wayland
smallville7123 has joined #wayland
hardening has joined #wayland
manuel_ has joined #wayland
<smallville7123>
still
lgaryrlmtdltb^ has joined #wayland
<smallville7123>
would it mean the compositor would also be commiting at 400 fps?
<dottedmag>
compositor is not committing.
<dottedmag>
compositor may do whatever it wants
<dottedmag>
discard everything but 30 frames per second. show every 100th frame. don't display anything.
<smallville7123>
like
<dottedmag>
I'd expect most compositors to discard everything but the latest buffer committed by client at the time compositer decides to draw a frame.
<smallville7123>
if the client is submitting at 400 fps, would the compositor also have to accept the commits at 400 fps to avoid blocking the client
manuel_ has quit [Ping timeout: 480 seconds]
<dottedmag>
yes, though accepting these buffers doesn't mean much: compositor probably will just store the pointers for later processing, and maybe also release the previous buffer.
<dottedmag>
400 ops per second is not much
<smallville7123>
so the compositor would be processing as fast as its fastest client is commiting?
<repetitivestrain>
ideally. you can always overload another program with requests
<smallville7123>
(assuming it polls the client socket)
<repetitivestrain>
not saying that can practically happen
<repetitivestrain>
but why are you asking this?
<repetitivestrain>
how fast the compositor can process wl_surface_commit is not very meaningful
<repetitivestrain>
not a very meaningful metric*
<smallville7123>
cus im making my own compositor
<dottedmag>
smallville7123: you may impose any limits on the client if you wish, to make sure no client may hog all the resources.
<dottedmag>
and yes, this will throttle chattiest clients, but that's probably ok
<repetitivestrain>
smallville7123: btw, what is the practical use case for letting clients commit at 400fps
<repetitivestrain>
clients should just commit in response to frame callbacks or at some predicted time (with wp_presentation)
<dottedmag>
they should, but one can't predict what a buggy client might do
<smallville7123>
repetitivestrain: to see how fast the opengl driver can render the clients graphics
<i509VCB>
There are 360hz monitors so you can get pretty close
<smallville7123>
eg to test how fast a program can render graphics and optimize the graphics drawing so it takes less time to render each frame
<repetitivestrain>
repetitivestrain: i think that is a fundamentally wrong approach to benchmarking the GL driver
<repetitivestrain>
can't you create pbuffers yourself
<smallville7123>
(eg, "profiling" without actually profiling using a cpu profiling application)
<smallville7123>
eg, the faster a program can render without vsync, the more room the program has to fit more stuff in without going below X fps
<smallville7123>
(typically no more than 16 ms per frame)
<repetitivestrain>
smallville7123: why exactly does the wayland compositor have to be involved in this?
<repetitivestrain>
if benchmarking the GL driver is all you want
<repetitivestrain>
or rather your program
<repetitivestrain>
not the GL driver
<smallville7123>
cus the wayland compositor provides its own gl drivers to help clients render to the wayland compositor
<repetitivestrain>
smallville7123: no, they don't
<repetitivestrain>
the wayland compositor doesn't even know about how clients are drawing to their buffers
<smallville7123>
or at least, it provides a way to hook into the glswapbuffers/eglswapbuffers function
<repetitivestrain>
smallville7123: wdym?
<repetitivestrain>
why would you benchmark eglSwapBuffers?
<repetitivestrain>
if you're benchmarking your own render loop
<smallville7123>
like, when eglSwapBuffers is called, it would need a way to upload the gpu data to the wayland compositor without the user needing to do this manually
<i509VCB>
Yes, the window system integration in vulkan and EGL would manage how the compositor gets the buffer
<smallville7123>
(eg, most gl applications just magically work with the compositor when linked with -l gl)
<i509VCB>
Which is implemented by your driver
hendry has joined #wayland
<smallville7123>
yea
<i509VCB>
If you create a gl triangle client and set WAYLAND_DEBUG=1, you'll see requests being sent you didn't explicitly engage
<i509VCB>
Those hidden requests are done by mesa
<repetitivestrain>
smallville7123: the buffer data is already in the GPU
<smallville7123>
yea
<repetitivestrain>
as long as the compositor supports wl_drm or dmabuf
<repetitivestrain>
you're drawing to the buffer and just telling the compositor about commits
<smallville7123>
and as such, wayland itself would need to handle such requests at how ever fast the client is sending them, right?
<repetitivestrain>
which is pointless to benchmark
<i509VCB>
Mesa can use wl_shm given the worst as well (albeit the driver would need to download the texture data)
<smallville7123>
or rather
<repetitivestrain>
a compositor i've written uses the same "smart scheduling" mechanism as the X.org server
<repetitivestrain>
so no, it will decrease the priority of clients that exceed their request quota
<smallville7123>
when eglSwapBuffers is called and the wayland compositor does NOT handle any requests, would eglSwapBuffers block?
<repetitivestrain>
yes afaik
<repetitivestrain>
either at the time of the swap or after the immediately subsequent swap
<smallville7123>
so to be able to for example, obtain 400 fps in the client, the compositor would ALSO be able to handle the requests at 400 fps or higher as well, right?
<smallville7123>
have to be able*
<repetitivestrain>
smallville7123: yes, but you should simply NOT try to benchmark your render loop involving the wayland compositor
<repetitivestrain>
or X server
<repetitivestrain>
or any window system integration code
<repetitivestrain>
just create a pbuffer surface or something
<smallville7123>
what if your benchmarking the compositor itself?
<smallville7123>
eg to see how fast it is able to handle requests
<repetitivestrain>
smallville7123: then why would you involve egl in this?
<smallville7123>
cus we would need to send data to wayland somehow
<repetitivestrain>
smallville7123: if you're benchmarking the wayland compositor, then you can just create a single pixel buffer
<repetitivestrain>
or a shm buffer, but that will involve the compositor uploading data to the gpu if there is any damage
<smallville7123>
eg, client -> set up egl, render whatever as fast as it possibly can, wayland -> connect to client, handle requests as fast as it possible can
<repetitivestrain>
how about: client -> wl_display_connect -> wl_surface_create -> <create whatever role and buffer you want> -> damage buffer and commit in a loop
<repetitivestrain>
why do you have to set up egl?
<repetitivestrain>
if you want to benchmark the compositor
<smallville7123>
or that :)
<smallville7123>
to send requests, does wayland use a blocking socket or a non blocking socket?
<repetitivestrain>
the file descriptor is blocking afaik, meaning wl_display_flush can block
<repetitivestrain>
i don't know if libwayland-client implicitly flushes every N requests like Xlib does
<smallville7123>
and to handle the requests?
<repetitivestrain>
i don't think wl_display_flush_clients can block (but am not sure)
<smallville7123>
hmm
<smallville7123>
as i currently use a blocking socket for the client, and a non blocking socket for the compositor
<repetitivestrain>
so are you using libwayland-client/server?
<repetitivestrain>
or some other library
<kennylevinsen>
smallville7123: the compositor does not do any notable work when a client commits its surface. The compositor usually only renders on e.g. “vsync”, and only then does it look at the last buffers it got from clients
<smallville7123>
repetitivestrain: im writing my own library for android
<kennylevinsen>
So a client rendering at 400fps doesn’t make the compositor do much if the compositor only runs at, say, 60Hz.
<smallville7123>
kennylevinsen: hmmm, how would the compositor go about handling the client requests such that the client is able to render at 400HZ
<smallville7123>
would it just be polling the client fd in a loop?
<kennylevinsen>
repetitivestrain: the fractional scale protocol tells the client the preferred scale, while the client uses viewporter to apply it
<kennylevinsen>
smallville7123: a compositor always polls all client sockets continuously. See poll/epoll. This is normally managed through an event loop, such as the one included in libwayland-server
<kennylevinsen>
(polling tells the kernel to put us to sleep and only wake us up when something happened)
<smallville7123>
yea
rv1sr has joined #wayland
manuel_ has joined #wayland
<smallville7123>
if the client wants to do software rendering to the compositor, how would the client's fps be synced?
<smallville7123>
eg the client does not depent on GL vsync to sync the client to the display refresh
<smallville7123>
would the compositor sync the client to the compositor's vsync ?
___nick___ has joined #wayland
mvlad has joined #wayland
<smallville7123>
eg
<smallville7123>
eg client -> wl_display_connect -> wl_surface_create -> <create whatever role and buffer you want> -> while(true) { draw to buffer via CPU -> damage buffer and commit }
<smallville7123>
assuming it doesnt need to use the GPU to draw to the buffer
mr-rich has quit [Ping timeout: 480 seconds]
<smallville7123>
or would the client need to manually sync itself to a chosen refresh rate?
<smallville7123>
eg client -> wl_display_connect -> wl_surface_create -> <create whatever role and buffer you want> -> while(true) { draw to buffer via CPU -> damage buffer and commit -> sleep for TIME_REQUIRED_TO_OBTAIN_60_FPS }
<smallville7123>
such that the client is not using like 90% cpu just to draw something at 60 fos
<smallville7123>
fps*
rasterman has joined #wayland
<smallville7123>
(it would probably use 1 to 5% cpu usage under normal GL vsync rendering i think)
<smallville7123>
maybe 20% max? depends on device and driver, assuming it is only drawing very simply stuff to the display, such as the GL triangle example
<smallville7123>
or a rotating cube
<smallville7123>
idk
mr-rich has joined #wayland
tzimmermann has joined #wayland
<daniels>
smallville7123: see wl_surface.frame, that’s what it’s there for. weston-simple-shm has an example of using this
lgaryrlmtdltb^ has quit [Remote host closed the connection]
<MrCooper>
"vblank_mode=0 weston-simple-egl" does around 5000 commits/s on this laptop, 400 is a cinch :)
<MrCooper>
repetitivestrain: Wayland doesn't have expensive requests like X, so colour me skeptical that "smart scheduling" makes sense in a Wayland compositor
MajorBiscuit has joined #wayland
Major_Biscuit has joined #wayland
MajorBiscuit has quit [Ping timeout: 480 seconds]
gschwind has joined #wayland
pochu has joined #wayland
<pq>
repetitivestrain, no, libwayland-client socket operations are fundamentally non-blocking, unless explicitly documented otherwise in the API.
<pq>
repetitivestrain, flush does not block.
<pq>
smallville7123, you have to define what you mean by "compositor processing" first. There are many different kinds of processing any compositor does. Handling requests practically never touches any actual pixel data or does any rendering. Those are scheduled and done independently at compositor chosen times, otherwise a compositor would be far too easy to overwhelm.
dcz_ has joined #wayland
manuel_ has quit [Ping timeout: 480 seconds]
pH5 has quit [Read error: Network is unreachable]
shoragan has quit [Read error: Network is unreachable]
<smallville7123>
MrCooper: 5000 fps o.o
<smallville7123>
pq: hmm ok
pH5 has joined #wayland
fmuellner has joined #wayland
pH5 has quit []
mtretter has quit [Ping timeout: 480 seconds]
<pq>
smallville7123, for example, a Wayland client uploading pixel data to a compositor does not copy any pixel data. The client simply delivers a handle to the storage. That's extremely fast to process.
<pq>
Things are a bit different when the compositor decides it actually wants to use those pixels. Then buffer type comes into play.
<pq>
If it's wl_shm and the compositor is rendering with a GPU, a compositor will usually indeed copy into GPU memory before it can use the pixels.
pH5 has joined #wayland
<pq>
If it's dmabuf, then quite likely the pixels are already accessible by the GPU, so there is no copy.
<smallville7123>
alright
<pq>
If it's dmabuf and direct scanout is possible, then the handle is passed to KMS, where the display hardware will directly read from the client buffer. This is called zero-copy.
shoragan has joined #wayland
<repetitivestrain>
pq: right, thanks for the correction! til
<smallville7123>
is it normal for a process to take more than 16 ms to respond to an update request?
<repetitivestrain>
kennylevinsen: thank you. so the compositor should just directly put the buffer pixels onto the display after the viewport is applied?
<pq>
smallville7123, what process and what update request?
<pq>
smallville7123, or, compositor or client? who is asking who to do what?
<pq>
The Wayland terminology is that "request" is a message from client to compositor, and "event" is a message from compositor to client.
<smallville7123>
for my compositor, every frame i send a request to the client to render their stuff
<pq>
smallville7123, Wayland does not work like that.
<repetitivestrain>
smallville7123: no, you send an event to the client telling it when it is time to draw a frame
<smallville7123>
repetitivestrain: yea
<pq>
Wayland compositors never *wait* for a client to draw, ever.
<smallville7123>
i do that every frame
<repetitivestrain>
smallville7123: there is no guarantee that the client has new contents
<repetitivestrain>
smallville7123: in that case it really is not a wayland compositor...
<pq>
Compositors can suggest a client to update their windows, but they never wait for it to happen, blocking the compositor's own updates.
<pq>
Compositors always keep hold of a wl_surface's latest contents, so that the compositor can update the screen at any time, at any rate, regardless of what clients do or don't do.
<smallville7123>
eg draw() { handle_draw_callbacks(); send_update_to_all_connected_clients(); } // clients sent data to compositor which adds to a queue of callbacks to be invoked on the next frame
<pq>
That does not sound like Wayland.
<smallville7123>
eg comp -> write(UPDATE_MSG, client_fd); client -> recv UPDATE_MSG -> send dummy data to comp; comp -> recv dummy data -> callbacks.push(create_dummy_render(dummy_data));
<pq>
No idea what that's about.
<repetitivestrain>
what are you doing?
<repetitivestrain>
smallville7123, that diagram is not very descriptive
<repetitivestrain>
maybe you should just post the code you are working on
<smallville7123>
ok so the buffer read begins at 49.975 and ends at 50.052 about 4 frames later
<smallville7123>
socket*
<smallville7123>
for only 5 bytes
<repetitivestrain>
as it stands we have no idea what you are trying to do
<pq>
we always use non-blocking sockets and non-blocking socket operations, with the only exception being the call to poll() or equivalent in the main event loop, for both compositors and clients.
<pq>
smallville7123, maybe you need to study the concept of an event loop? That is, watch many event sources at once, and react when any of them has something to do.
<repetitivestrain>
pq: he says he is using his own wayland library
<pq>
yes, I remembered something like that
<repetitivestrain>
but i don't really understand what he's trying to do here... the topic jumps from eglSwapBuffers at 400fps to god knows where :(
<pq>
so I'm guessing smallville7123 does not understand what an event loop is, and attempts to communicate with each client in turn in a blocking way.
<repetitivestrain>
my guess is he is trying to adapt wayland for only a single client..?
<repetitivestrain>
smallville7123: could you *please* try to explain what you are doing, clearly? what program is your compositor going to be used in?
<pq>
single client or multiple clients makes no difference - if one is trying to make a difference, it's going to fail
<smallville7123>
this is for a DAW which each client sends graphical data for the compositor to render
<smallville7123>
for the DAW's compositor*
<pq>
what's DAW?
hardening has quit [Read error: No route to host]
<smallville7123>
digital audio workstation
<pq>
Nevertheless, it doesn't change how Wayland works. Everything must be non-blocking always, except when you sleep in the main event loop waiting for something to happen. For both compositors and clients.
sozuba has joined #wayland
<smallville7123>
the best i can do while keeping CPU usage of the client minimal is 60 messages every ~1.3 seconds
<pq>
When people are trying to integrate Wayland in a code base that has been designed not with an event loop, they struggle a lot and have to use nasty hacks to work around the existing designs.
<smallville7123>
200 seconds elapsed with ~8300 messages recieved
<pq>
smallville7123, I don't know why you would be interested in such numbers.
<pq>
number of messages per second is very much irrelevant
<smallville7123>
im trying to measure the FPS of my compositor and in tern the FPS of my client
<pq>
you're probably too deep in the details here
<pq>
message count is not FPS, not even by a long shot
<pq>
smallville7123, do you understand what an event loop is? How it sleeps most of the time waiting for something to happen?
<smallville7123>
a bit
sozuba has joined #wayland
<pq>
do you use select(), poll() or epoll?
<smallville7123>
i use poll
<pq>
ok, and with infinite timeout, yes?
<smallville7123>
yes
<pq>
good
<pq>
btw. why would you not use libwayland? Re-inventing all that is a huge burden.
<smallville7123>
specifically i am unable to create a graphical instance in my client due to SDL2 depending on JVM which i do not have access to, and every UI framework i could use (for my chosen language) depends on SDL2 to render any graphics
<pq>
it also makes you not able to use other libraries that use libwayland themselves, like EGL
<pq>
ok, but that does not explain why you can't use libwayland
<smallville7123>
my usage is for android and windows
<pq>
aha, so into the deepest end straight, oh dear :-)
<smallville7123>
:)
<smallville7123>
the highest i can get is 60 messages every 0.002 seconds but them my CPU temp goes from ~47 to ~78
<smallville7123>
then*
<smallville7123>
which is not good for a phone lmao
<pq>
It might still be easier to port libwayland than start from scratch. We used to have an Android port of libwayland many years ago.
<smallville7123>
specifically i need to be able to transmit both audio and visual data, with audio data arriving in under 4 ms to be able to fill the audio buffer in time to avoid buffer underruns
<smallville7123>
not quite sure how i would do that yet since it depends highly on the transmission speed between client and server, and the buffer size
<pq>
Good luck! That's all I can say. We don't do audio here.
<pq>
well, Wayland data transmission speed is essentially infinite, because bulk data is *not sent*. All we do is pass buffer handles around, nothing is shoveling bulk data with CPU at communications level.
<smallville7123>
eg, simply reading 1 byte every 16 ms takes almost 0 ms, while reading 5 bytes every 16 ms takes 4 additional 16 ms frames, so god knows how i am going to be able to get this down to 4 ms with a decent audio buffer size
<smallville7123>
i do have shared memory available but i have not tested it with my current setup yet
<repetitivestrain>
smallville7123: why are you trying to shove audio *data* down the wayland connection?
<pq>
that really sounds like you are just using sockets wrong
<smallville7123>
if i could use shared memory then i might just be able to client: update -> lock, memcpy, unlock, send_update_to_server server -> read_update -> lock, memcpy, unlock
<smallville7123>
and hopefully it should be a lot faster
<smallville7123>
since we need only transfer 1 byte to sync updates between client and server
<pq>
no, you really have something fundamental wrong in how you use your sockets
<smallville7123>
how should i be using the sockets then?
<repetitivestrain>
smallville7123: we can't know that without you telling us how you are *currently* using sockets
<pq>
somehow differently
<pq>
are you perhaps reading a single byte at a time, then returning back to poll() even if there was more data available?
<pq>
do you have sleep() or such things?
<pq>
sleep(), nanosleep(), udelay() etc. are all purely harmful in an event loop based program.
<smallville7123>
atm i just do client:{ poll, read byte, render } server: { poll clients, read up to BUFFER_SIZE bytes, if (read > 0) decode_and_handle_messages }
<pq>
so where does the "every 16 ms" come from?
<smallville7123>
by client sends 5 bytes of data, and my BUFFER_SIZE is 5
<smallville7123>
on every frame update i send a message to my client telling it that it is time to render
jmdaemon has quit [Ping timeout: 480 seconds]
<pq>
yeah, what exactly is waiting 16 ms and when?
<smallville7123>
the vsync of the compositor
<repetitivestrain>
smallville7123: where is that vsync coming from
<repetitivestrain>
how are you polling it?
<repetitivestrain>
are they drm events?
<smallville7123>
SDL2 application
<pq>
oh, you did the classic mistake all games are doing: render from the event loop itself, instead of when necessary
<smallville7123>
eg android Java SDL2
<repetitivestrain>
how are you polling it
<pq>
your compositor should render only when it needs to, and not every event loop cycle. Also the rendering must not wait for vblank by blocking but listening for an event in the event loop.
<smallville7123>
pq: how else am i supposed to sync the render updates in a GL-less/Vulkan-less client
<pq>
SDL2 may not be capable of this
<pq>
so you may have to use another thread
<smallville7123>
SDL2 is only in the compositor, the client cannot use SDL2 at all
<pq>
yes
<repetitivestrain>
smallville7123: you can't wait for vsync in the compositor
<smallville7123>
why
<pq>
your compositor is blocked when it should not be, that limits your message rate
<smallville7123>
the vsync is only used to send update messages to the client
<pq>
"update messages" are not the Wayland design
<pq>
Wayland clients update whenever they feel like. Not when a compositor tells them to.
<pq>
although it's good manners to update when something has changed that warrants an update, otherwise the application seems unresponsive.
<smallville7123>
tho most clients draw at 60 fps, right?
<pq>
That's the naive and broken main loop no-one should be using.
<smallville7123>
oof
<smallville7123>
android uses it :)
<smallville7123>
since it always needs to redraw its main texture to the back buffer
<pq>
That's the reason why gamers are so hell-bent demanding tearing and fps in hundreds or thousands, or why they claim that vsync is Bad (tm).
<smallville7123>
otherwise black screen :)
<smallville7123>
or rather
<pq>
smallville7123, I don't believe that. Linux does not work like that.
<pq>
hardware does not work like that
<smallville7123>
this is needed when using double-buffered display thing (to avoid tearing) right?
<smallville7123>
eg gpu draws front while app draws back, then they swap
<pq>
Display hardware will repeat scanning out the same frame until that frame is replaces with a new one. It doesn't go black after the first cycle.
<smallville7123>
pq: hmmm
Major_Biscuit has quit [Ping timeout: 480 seconds]
<smallville7123>
so we only need to swap buffers once to actually draw to the screen on the very first frame?
<pq>
Wayland compositors actually do the same: they keep on re-using the window image until a client posts a new image.
<pq>
you swap buffers when you have something *different* to show
<smallville7123>
wait what if the vsync loop is also used for animating? (eg animation callbacks)
<smallville7123>
or UI callbacks?
<smallville7123>
(eg to update the app from a seperate non-ui thread)
<pq>
what about that?
<smallville7123>
wouldnt we need to constantly wait for vsync there?
<smallville7123>
to ensure we update each frame
<pq>
not wait, and not vsync, otherwise yes
<smallville7123>
hmm
<pq>
there is an upper limit on how often a screen can be updated, and without tearing that limit is the refresh rate.
<pq>
With an animation, simply the passage of time is something that causes a change in what you want to show.
<pq>
But it's useless to re-draw unless you can also update the screen with the drawing, hence we need throttling.
<pq>
In Wayland, throttling works by the client send wl_surface.frame request, and the compositor will respond to that once it's a good time to draw the next frame.
<smallville7123>
alright
<pq>
While vblank does happen at refresh rate, it's not the thing waited for. Vblank is the time when a screen update does not tear. A good time to start drawing can be different.
<pq>
Because of how screens work, a compositor will render at most once per screen refresh. When it does so, it uses the latest available window image from all clients.
<pq>
This makes the compositor updates completely independent of what clients do.
<pq>
If the compositor has nothing different to show, it does not render.
<pq>
If a client posts a new window image (frame), then the compositor does have something different to show.
<smallville7123>
can a wayland client work without a GPU context
<pq>
How and when will a compositor actually render a new frame for the screen is a whole another topic, which does involve vblanks.
<pq>
yes
<pq>
all software rendered clients by definition do not use a GPU context
<smallville7123>
how would a software-rendered client work?
<pq>
on the CPU :-)
<smallville7123>
like, how would wayland handle it
<pq>
e.g. Weston's clients/simple-shm.c
<pq>
not in any different way
<pq>
the client draws in a buffer (just write bytes with CPU, really), passes the buffer handle to a Wayland compositor, and then the compositor reads it.
<smallville7123>
how does wayland know if the client is backed by a GPU buffer or a software buffer?
<pq>
*reads it later, when the compositor renders
<pq>
the client uses a different protocol interface: wl_shm for software buffers, zwp_linux_dmabuf_v1 for hardware buffers.
jgrulich has joined #wayland
<smallville7123>
hmm alright
<repetitivestrain>
or wl_drm
<pq>
Wayland, as in libwayland, does not actually understand anything about the messages it relays, so it's really the compositor that understands or knows.
<smallville7123>
can wayland work on windows?
<smallville7123>
(without relying on WSL)
<repetitivestrain>
does windows have sendmsg/recvmsg, the ability to send file descriptors via those two interfaces, and POSIX shared memory
<pq>
smallville7123, well, Wayland is not a program. It's not something one can execute. It's a protocol, which is like a language, and it's also an architecture.
<pq>
smallville7123, as such, Wayland could work on Windows once you solve any practical issues.
<smallville7123>
hmm alright
<smallville7123>
where would i start?
<pq>
make libwayland build and pass its test suite on Windows, if Wayland is really what you want to use. You need to fork the repository, because will likely need to rewrite some pieces of it.
<pq>
you also need to figure out what "buffer handles" on Windows are, and how they can be sent across processes.
<smallville7123>
alright
<pq>
if the handles do not really fit any of the existing wl_buffer factory interfaces, you define a new one.
eroux has quit [Remote host closed the connection]
<smallville7123>
how would i go about embedding a wayland compositor into an application
<smallville7123>
also how would i handle passing input (eg mouse/touch-screen) to the compositor
sozuba has quit [Quit: sozuba]
<pq>
smallville7123, nothing special to that, but also it's all just details. I don't think there is a generic answer.
<pq>
A Wayland compositor is really just any IPC server that talks Wayland. It might not even composite.
<smallville7123>
alright
<pq>
application internal Wayland usage can also freely choose which Wayland interfaces they implement and what private extensions they want.
<pq>
it's total freeedom, because neither the server nor client need to be compatible with anything else.
<pq>
smallville7123, another apporach to porting libwayland is to choose a generic IPC library (like Google protobufs, maybe?) that already works on the target OS, check that it can send whatever buffer handles are on that OS, and write a tool to translate Wayland XML specs for that lib.
<smallville7123>
yea
smallville7123 has quit [Quit: Konversation terminated!]
manuel1985 has joined #wayland
hardening has joined #wayland
<kennylevinsen>
repetitivestrain: when the viewport scaling matches the output scaling done by the compositor, the scaling factors cancel out and you get 1:1 buffer pixel to physical pixel mapping
<kennylevinsen>
That is already true right now - what was missing was just a way of knowing what that scaling factor was
<repetitivestrain>
repetitivestrain: ah i see what you mean now, so it's just like the regular buffer scale
smallville7123 has joined #wayland
<smallville7123>
im not sure how to fix this
<smallville7123>
Run-time dependency libffi found: NO (tried cmake)
smallville7123 has quit [Quit: Konversation terminated!]
fmuellner_ has joined #wayland
kts has quit [Quit: Leaving]
fmuellner has quit [Ping timeout: 480 seconds]
gschwind has quit [Quit: Leaving]
manuel1985 has quit [Ping timeout: 480 seconds]
floof58 has quit [Remote host closed the connection]
manuel1985 has quit [Read error: Connection reset by peer]
heeen[m] has quit []
heeen[m] has joined #wayland
Guest2443 is now known as heeen
<heeen>
weird
manuel1985 has joined #wayland
smallville7123 has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
Company has joined #wayland
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #wayland
rv1sr has quit [Ping timeout: 480 seconds]
<mvlad>
emersion, we'd like to do another point release, one for weston 11 (11.0.1) and one for weston 10 (10.0.2). Merged today the fixes for 11, and for 10 those were merged a while ago. You'll need to cut/tag them. Thinking 2, or maybe 3 weeks from now would be a good time. Two seems reasonable, but maybe 3 might be better. I'm fine either way.
<mvlad>
pq, daniels ^^
<emersion>
do we really need to maintain old versions?
<mvlad>
well, there hasn't been that many updates, but I see people using 10.0.1.
<daniels>
emersion: if we're breaking API compat then I don't see a reason to not keep them alive
<emersion>
just trying to (1) check what the policy is and (2) make sure it's applied fairly
<emersion>
#695 is just about migrating to another org, the migration off of FDO is just a note
<jadahl>
sounds more like a threat/ultimatum than "note" tbh
<emersion>
okay, let me delete it then
<emersion>
i still want an answer for #473
<emersion>
and #695 is still independently something which makes sense to me
<emersion>
even libinput has its own org!
<emersion>
you're playing with words, mriesch
<emersion>
err
<emersion>
you're playing with words, MrCooper
<emersion>
but yeah, i will for sure create an issue to ask weston to migrate off of FDO if sway gets denied
<jadahl>
here we go with the ultimatums again...
<emersion>
if that's what you call a "coup"
<MrCooper>
various words come to mind, no nice ones though
<emersion>
why should weston get special treatment?
<MrCooper>
because it happens to be here for hysterical reasons
<MrCooper>
*raisins
<emersion>
ah, yes, not everybody is born equal
<ManMower>
ooi, and admittedly quite tangentially, is sway dissastisfied with its current hosting?
<emersion>
yes :(
<emersion>
GitHub doesn't align with our philosophy
<emersion>
we do have _some_ other options, like Codeberg or sr.ht
<ManMower>
meh, sorry to hear it. :(
<emersion>
btw, why do you think "create an issue to migrate" is that aggressive?
<emersion>
some people asked for the master branch to be renamed, that's a somewhat similar thing IMHO
<emersion>
some people care about it, some don't, but what's the harm in discussing these things?
<emersion>
similar in the sense that it's a migration
<ManMower>
it kinda reads like "host us or you have to dehost this other project, ok?". ignoring for a moment the legitimate discussion to be had here, the hot take is that this is a coup...
* ManMower
makes some popcorn and watches the proceedings
<emersion>
i wonder how i could've phrased this better
<emersion>
it's not like i'll kick weston out
<emersion>
"historical reasons, bear with the unfairness" is a valid reply
<emersion>
one that i'm not 100% happy with, but i'll live with it :)
<ManMower>
fair enough :)
andyrtr has joined #wayland
andyrtr has quit []
manuel1985 has quit [Ping timeout: 480 seconds]
andyrtr has joined #wayland
tzimmermann has quit [Quit: Leaving]
kts has quit [Ping timeout: 480 seconds]
markbolhuis has quit [Quit: markbolhuis]
nerdopolis has quit [Ping timeout: 480 seconds]
* daniels
finishes work, reads scrollback ... a quiet afternoon here, I see
<daniels>
emersion: I'm not sure if it's what you intended, but I'm not sure how to read those two issues as anything other than 'if you don't host my project then I'll try to get yours kicked off', which is really quite confrontational
<daniels>
of course you don't have to be Weston RM - we can find someone more involved with Weston to step up and do that. thanks a lot for all your work having done it in the past, and no need at all to feel like you're held hostage to continuing to volunteer for it :)
<daniels>
I have no issue moving Weston to its own namespace which would put it more in line with wlroots, because those two projects are basically equivalent. Weston's functional output is libweston as a piece of common infrastructure, and probably most usefully kiosk-shell as its flagship environment, which is very similar to wlroots+tinywl. desktop-shell is a laughably skeletal demo
<emersion>
tinywl is documentation
<emersion>
it's not installed, has no protocol support
<daniels>
its readme describes it as an MVP Wayland compositor
<emersion>
yes, it's like westiny
<daniels>
to explain policy by analogy - GStreamer/PipeWire/NetworkManager are all foundational infrastructure projects. they do have fairly skeletal interfaces in-project - gst-launch, pw-cli, nmcli, etc. for some uses, those interfaces are perfectly acceptable, even though they're insanely basic and limited. we've never put an ultimatum to kick them out though, because they're fairly straightforward implementations on top of the projects.
<emersion>
i think the policy is dumb, tbqh
<daniels>
but we wouldn't host Kodi or VLC, we wouldn't host Ardour, and we wouldn't host ... whatever the network equivalent would be ... because they are primarily user-facing projects, whose main interface and value is in the user interface they present
jgrulich has quit [Ping timeout: 480 seconds]
<daniels>
that's why I would personally -1 sway, because sway is primarily user-facing, unlike wlroots which is primarily developer-facing
<daniels>
if you think the policy is dumb, then the foundation is currently rewriting its bylaws, so now would be a good time to get involved and get it changed
<daniels>
emersion: I'm happy to have a conversation with you about what you would like to see change, but tbh if you fire ultimatums out and then close them before I've even had a chance to read and respond, I don't think it's going to go anywhere
wlb has quit [Ping timeout: 480 seconds]
Major_Biscuit has joined #wayland
danvet has quit [Ping timeout: 480 seconds]
junaid has joined #wayland
midgard has quit [Quit: Bye]
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
midgard has joined #wayland
___nick___ has joined #wayland
everfree has joined #wayland
rv1sr has quit []
jmdaemon has joined #wayland
___nick___ has quit [Ping timeout: 480 seconds]
junaid has quit [Ping timeout: 480 seconds]
Major_Biscuit has quit [Ping timeout: 480 seconds]