ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Brainium has joined #wayland
nerdopolis has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
sevz has joined #wayland
Consolatis_ has joined #wayland
Consolatis is now known as Guest2083
Consolatis_ is now known as Consolatis
Guest2083 has quit [Ping timeout: 480 seconds]
daz has joined #wayland
Hypfer has quit [Remote host closed the connection]
Hypfer has joined #wayland
d42 has quit [Ping timeout: 480 seconds]
d42 has joined #wayland
daz has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
dcz_ has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
Consolatis has quit [Ping timeout: 480 seconds]
Consolatis has joined #wayland
nerdopolis has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
dcz_ has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
cool110 is now known as Guest2090
Guest2022 has quit [Ping timeout: 480 seconds]
carlos_ has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
kenny has quit [Quit: WeeChat 4.0.4]
kenny has joined #wayland
nerdopolis has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
Guest2090 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest2099
mblenc has quit [Read error: Connection reset by peer]
mblenc has joined #wayland
gspbirel5687340886706131 has joined #wayland
gspbirel568734088670613 has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Remote host closed the connection]
rgallaispou has joined #wayland
<zzag>
MrCooper: mutter will delay applying surface state until the committed buffer is ready. How does this work with subsurfaces? Let's say there's the following tree: A -> B -> C -> D. "A" is the main surface. If surface C is committed and its buffer is not ready, what will mutter do? Will it put A, B, and C in the same transaction? or C and D? or all of them?
<zzag>
B, C, and D are sync subsurfaces
mblenc has joined #wayland
mblenc1 has joined #wayland
mblenc1 has quit [Read error: Connection reset by peer]
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
carlos_ has joined #wayland
<ascent12>
zzag: I don't know anything about their imeplementation, but a synced subsurface that is not ready should block its parent surface. It would violate the "every frame is perfect" thing otherwise.
<pq>
right, and a non-ready surface that has a sync'd sub-surface should block the sub-surface too if the sub-surface attempts an update.
<pq>
The usual rules apply too, so if C is committed, that update cannot become a transaction until B is committed, and then A is committed.
rederick29 has joined #wayland
fmuellner has joined #wayland
rv1sr has joined #wayland
Cyrinux9474 has quit []
Cyrinux9474 has joined #wayland
Company has joined #wayland
vbt_ has quit [Remote host closed the connection]
vbt has joined #wayland
nerdopolis has joined #wayland
dcz_ has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
MrCooper has quit [Remote host closed the connection]
<kennylevinsen>
the other side might also want to mmap the the profile, rather than waste time reading it into a new buffer
<Company>
and I guess using wl_shm sucks for that, too
<Company>
I'm just thinking that this is an application requirement for any app that wants to use that part of the protocol
<kennylevinsen>
wl_shm wraps an fd with the same requirements
<swick[m]>
yeah, this is the same
<swick[m]>
and it's horrible we can't specify that it should be sealed
<swick[m]>
just because some OSes are horrible
<swick[m]>
so, even more horrible signal mess
<kennylevinsen>
Did talk about fixing the sealing/sigpipe/etc. hell server-side through the kernel end anywhere or did it die? I remember talk of a new mmap flag
<swick[m]>
didn't see anything new
<Company>
I wish there was code in libwayland that gave you a memory region to share with the compositor
<swick[m]>
Company: really, client side has nothing to complain about...
<swick[m]>
all the horribleness is in the compositor
<Company>
then the compositor can hand over the fd that the client gets to write the icc profile into!
<swick[m]>
Company: but sure, if you want to add something to libwayland, go ahead
<kennylevinsen>
Company: I mean it could be there, but libwayland shouldn't become a generic platform helper lib...
<swick[m]>
eh, too late
<kennylevinsen>
... on the client-side at least
<kennylevinsen>
maybe one day we get to nuke the event lib from server
<Company>
kennylevinsen: i'm just thinking that the eog or whatever image viewer devs - who usually write python code - decide to send the icc profile for the image they just loaded to the compositor
<Company>
but then, they might just send the fd of the png file + the offset where the profile starts
<kennylevinsen>
Company: it would be quite silly to force the client to write this to an FD. It's quite likely that the compositor would want to mmap the profile, and quite likely that the profile is on disk and can be sent directly.
<kennylevinsen>
plus there's nothing hard about using shm or memfd
<Company>
apparently it's >100 lines of code littered with #ifdefs
<kennylevinsen>
wouldn't the ICC profile in case of eog be in the file on disk?
<kennylevinsen>
That's if you want all the bells and whistles, shm is portable but lacks sealing
<kennylevinsen>
re: eog, the current approach would let you just send an fd to the file and an offset to the ICC profile assuming it's in a readable format
<swick[m]>
indeed
<Company>
yeah, works for png probably
<Company>
if the file format is compressed, it'll stop working
<Company>
and there's all the races you can get into if the compositor and the app do stuff
<kennylevinsen>
What races?
<kennylevinsen>
The lifetime of the fd is well-defined, no?
<Company>
yeah, if you assume app developers have the same skills in lifetime management as compositor developers
<kennylevinsen>
Company: Not closing an fd or modifying its content prematurely is a pretty simple requirement
<dottedmag>
Users may inadvertently do that, right? Overwriting the file while it's open.
<kennylevinsen>
sure, if you overwrite the image file that the image viewer and compositor are both reading from, they'll equally fail to read it. Seems like a sound error case, and IIRC the protocol defines errors for being unable to read?
<Company>
it just feels very cumbersome and brittle for "here's an array of bytes"
<kennylevinsen>
well, this is how all data is passed in wayland
<dottedmag>
keymaps are passed this way too, though in another direction
<kennylevinsen>
Because it's the only "smart" way to pass data on *nix
<Company>
that's why I said I wished libwayland had an API for "here's an array of bytes"
<Company>
so the code doesn't have to be "smart"
<kennylevinsen>
I get that, but then you could extend it to saying libwayland should have all sorts of other generic convenience things a Wayland client would need, and we'd prefer to keep stuff out...
<kennylevinsen>
We made the mistake of adding an event loop lib to the server for example under the same idea of "well you'll need it" - huge mistake :(
<kennylevinsen>
So if it's not a Wayland specific thing - and fds are certainly not - it's best done elsewhere, in whatever way you like
<Company>
it's pretty wayland-specific to me
<Company>
dbus can send an array of bytes for example
<kennylevinsen>
it's entirely generic Unix fds, with a handful of Unix ways if making it. Very Unix and not Wail and if you ask me.
<kennylevinsen>
You can call open(3) to get a compatible fd from a file, or shm_open(3) to make an anonymous file. POSIX.
<kennylevinsen>
s/Wail and/Wayland/ - I feel like my phone's autocorrect is doing this on purpose at this point
<Company>
this is not about files though, this is about byte arrays
<kennylevinsen>
That's an anonymous file
<dottedmag>
libanonfile anyone? :)
<kennylevinsen>
(just like your process heap is btw)
<Company>
now we figured it out, we just send an offset + size into the process heap!
<kennylevinsen>
lol I was just about to say that hahaha
<kennylevinsen>
bad idea of the day
<Company>
I'm all for that, because that's literally what a pointer is
<Company>
all the compositor has to figure out is how to read it, but that's not the client's problem
<kennylevinsen>
yeah - but also why making a new anonymous file to share is not weird
<kennylevinsen>
and sharing your heap would *definitely* have some if those races you mentioned :P
<Company>
I consider that very weird, because as an app developer I never have to do that
heapify is now known as heapheap
<kennylevinsen>
Odd that you'd say that considering how much it happens. Maybe because a toolkit is taking care of it most of the time? gdk, gtk, Mesa WSI...
<kennylevinsen>
we pass fds for copy/paste and dnd, shm, dmabufs, keymaps, etc.
junaid has quit [Remote host closed the connection]
mblenc has joined #wayland
mblenc1 has quit [Read error: Connection reset by peer]
heapheap has quit []
Brainium has quit [Ping timeout: 480 seconds]
mblenc has quit [Ping timeout: 480 seconds]
vbt has quit [Remote host closed the connection]
vbt has joined #wayland
junaid has joined #wayland
gspbirel56873408867061314 has joined #wayland
gspbirel5687340886706131 has quit [Ping timeout: 480 seconds]
Moprius has joined #wayland
Moprius has quit [Quit: bye]
Cyrinux9474 has quit []
Cyrinux9474 has joined #wayland
Guest2099 has quit [Remote host closed the connection]
rederick29 has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
gspbirel568734088670613144 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
gspbirel56873408867061314 has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
iomari892 has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
cool110 is now known as Guest2162
Guest2162 has quit [Remote host closed the connection]
cool110_ has joined #wayland
cool110_ has quit [Remote host closed the connection]
junaid has quit [Ping timeout: 480 seconds]
cool110_ has joined #wayland
cool110_ is now known as Guest2163
Guest2163 has quit [Remote host closed the connection]
rasterman has joined #wayland
junaid has joined #wayland
sima has quit [Ping timeout: 480 seconds]
cool110- has joined #wayland
cool110- has quit [Remote host closed the connection]
cool110- has joined #wayland
cool110- has quit [Remote host closed the connection]
cool110- has joined #wayland
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
cool110- has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest2171
mblenc1 has quit [Ping timeout: 480 seconds]
Guest2171 has quit [Remote host closed the connection]
cool110_ has joined #wayland
cool110_ is now known as Guest2173
Guest2173 has quit [Remote host closed the connection]
cool110- has joined #wayland
cool110- has quit [Remote host closed the connection]
Brainium has joined #wayland
junaid has quit [Remote host closed the connection]
nerdopolis has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
cool110- has joined #wayland
cool110- has quit [Remote host closed the connection]
cool110- has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
Cyrinux9474 has quit []
Cyrinux9474 has joined #wayland
nerdopolis has joined #wayland
kts has joined #wayland
Brainium has quit [Remote host closed the connection]
kts has quit [Quit: Leaving]
fmuellner has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
<ascent12>
Company: dbus can theoretically work over TCP (as rare as that is), which is why it needs to be able to push bytes over the protocol. Wayland _always_ uses unix domain sockets, so there is no reason to not just use file descriptior passing for basically everything.
<ascent12>
I think the protocol buffers were made intentionally quite small so people didn't get any silly ideas.