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
manuel_ has joined #wayland
manuel__ has quit [Read error: Connection reset by peer]
ybogdano is now known as Guest6422
ybogdano has joined #wayland
ybogdano has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
molinari has quit [Ping timeout: 480 seconds]
ybogdano has joined #wayland
ybogdano has quit [Ping timeout: 480 seconds]
julio7359 has joined #wayland
julio7359 has quit [Remote host closed the connection]
julio7359 has joined #wayland
julio7359 has quit [Ping timeout: 480 seconds]
julio7359 has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold___ has joined #wayland
CodeSpelunker has joined #wayland
Leopold_ has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
julio7359 has quit [Remote host closed the connection]
julio7359 has joined #wayland
Leopold___ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold___ has joined #wayland
Leopold_ has quit [Ping timeout: 480 seconds]
agd5f has joined #wayland
agd5f_ has quit [Ping timeout: 480 seconds]
julio7359 has quit [Remote host closed the connection]
julio7359 has joined #wayland
CodeSpelunker has quit [Quit: CodeSpelunker]
julio7359 has quit [Ping timeout: 480 seconds]
julio7359 has joined #wayland
julio7359 has quit [Ping timeout: 480 seconds]
dcz_ has joined #wayland
hardening has joined #wayland
molinari has joined #wayland
systwi has quit [Ping timeout: 480 seconds]
kts has joined #wayland
mvlad has joined #wayland
zvarde1988303206779 has joined #wayland
systwi has joined #wayland
zvarde198830320677 has quit [Ping timeout: 480 seconds]
<emersion>
(well except for the part about rust but that's a given at this point lol)
<emersion>
ofourdan: would there be a way to reparent only windows which are using xshape?
<emersion>
tbh i don't know much about reparenting, what changes does it make?
<ofourdan>
that's a good question - do tell that a client is using xshape, one would have to check if the client has set the shape extends, but a client would probably not do that if the xserver does not support shape...
<ofourdan>
s/do/to/
<ofourdan>
ah wait
<ofourdan>
context switch error on my side
<ofourdan>
that would be w/out diableing the shape extension i nthexserver, so yeah, the client could use xshape and the x11 wm can then check whether the client has set any shape extents
<pq>
emersion, glad to agree for once. :-)
<ofourdan>
wrt to reparenting, it's just reparenting the shaped window into a wm's own (unshaped) x11 window, so that the wayland compositor does not have to translate the shape into opaque regions.
<emersion>
ofourdan: can the XWM get an event when xshape is enabled/disabled?
<emersion>
hm
<ofourdan>
it does nto get an event, it queries the window using e.g. XShapeQueryExtents()
<ofourdan>
wait maybe there is an event as well
<emersion>
right but what happens if the client changes the shape while mapped?
<emersion>
hm i guess there's an event for X11 compositors anyways
<ofourdan>
yeah
<ofourdan>
I do nto remember which one though
<emersion>
the shaped windows can be used by O-R windows, can reparenting still happen there?
<ofourdan>
yeah, ShapeNotify
<emersion>
cool
<ofourdan>
sure, you can reparent O-R as well
hardening_ has joined #wayland
<emersion>
(because O-R is not supposed to be touched by the XWM in theory AFAIU)
<emersion>
ok
<ofourdan>
iirc, you would also need to select SubstructureNotifyMask and SubstructureRedirectMask on the wm parent window
<ofourdan>
but I do not think that would be a huge chnage
<ofourdan>
maybe it;s not worth it - for xeyes, I think it;s a bug in xeyes :)
<pq>
If O-R is reparented, does that actually work? Wouldn't the X11 client be wanting to position that O-R window in global coordinates, but now it gets clipped to WM installed parent window?
<pq>
Would the WM need to play catch-up the parent window position/size with the O-R window position/size?
hardening has quit [Ping timeout: 480 seconds]
<ofourdan>
mny x11 wm use reperenating even on O-R windows
<ofourdan>
*reparenting
<pq>
oh, alright
MrCooper_ is now known as MrCooper
<MrCooper>
ofourdan: what is a bug in xeyes?
<ofourdan>
iirc the x11 wm would not get the configureRequest for O-R window, only configureNotify
<ofourdan>
MrCooper: it does not clear/repaint the shaped areas when xshape is not available from the xserver
<MrCooper>
ah
<MrCooper>
maybe somebody should add support for xeyes to use an RGBA visual instead of a shape for output (probably still want to use shape for input though)
<ofourdan>
yeah, ala cairo-clock :)
kts has joined #wayland
<MrCooper>
yeah, that's a classic
kts has quit [Quit: Konversation terminated!]
MrCooper has quit [Quit: Leaving]
MrCooper has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
Leopold has quit []
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
kts has joined #wayland
Fxzxmic has joined #wayland
Company has joined #wayland
parazyd1 has joined #wayland
<ifreund>
I wish there was some meaningful way WAYLAND_DEBUG could show array contents...
<ifreund>
(I'm well aware that it can't really, just wanted to complain a bit)
<jadahl>
ifreund: you and me both
<ifreund>
I suppose we could add an optional element size attrible to the xml for array arguments
<ifreund>
and an optional enum attribute
<ifreund>
I'd certainly use those in my wayland scanner too if available to generate more type-safe code
parazyd has quit [Ping timeout: 480 seconds]
<pq>
what about int/unsigned/float?
<pq>
int/unsigned/float/enum/other + element size (0 for variable element size) could be doable
<pq>
assume CPU-endian, and forbid non-power-of-two sizes in bytes for everything except 'other'
<ifreund>
pq: I'd stick to the types already used by the protocol I think...
<emersion>
ifreund: linux-dmabuf only stores int64_t indexes in wl_array
<emersion>
the shm FD contains the structured data
<emersion>
err, int16_t
<ifreund>
ah, I read too quickly
<pq>
how do we get the printing hint from XML into libwayland?
<pq>
more magic into message signature strings? I'm not sure if they stretch even further.
Fxzx_mic has joined #wayland
<ifreund>
I think that's the only real option
Leopold has quit [Remote host closed the connection]
kasper93 has joined #wayland
<pq>
or extend the language binding ABI with a new marshalling function... oh but that works only for sending
<ifreund>
I wouldn't need any libwayland changes to make use of new xml attributes for type safety in my scanner
<pq>
I know.
<ifreund>
the only concern here wrt libwayland changes is pretty-printing as far as I see
<pq>
yes
Fxzxmic has quit [Ping timeout: 480 seconds]
kts has joined #wayland
<ifreund>
I think something like a[i] or a[u] would be fine for the type, getting the enum hint to the printer that way seems too ugly though
<pq>
and verify in the scanner that the annotations are valid
<ifreund>
yeah, that too
<ifreund>
maybe pretty printing enum names is too ambitious for libwayland, printing the values of the array would already be a huge help
Leopold has joined #wayland
<pq>
oh, nothing is generating enum value name tables for now
<pq>
yes
<jadahl>
maybe we can start putting that in the protocol code file exposing it via a _to_string() API
<jadahl>
could be useful in its own
<pq>
I've been dreaming of new Wayland bindings for C to ditch libffi, which means a new scanner, so we could even generate enum argument types if that's a good idea.
<pq>
jadahl, how do you get libwayland to call that?
<ifreund>
I'll put together a patch adding the xml annotations and printing values for int/uint.
<pq>
oh well, simply printing just 32-bit words could help a lot.
<ifreund>
I think that's pretty tightly scoped but would still be a meaningful improvement
<jadahl>
pq: we'd need to reference it from the interface some how
<emersion>
pq, do you know why we use libffi?
<pq>
jadahl, yeah, how? I don't think the structs are versioned in any way. :-)
<jadahl>
pq: I wouldn't be able to answer that without trying. my brain is not up to date about all those details
<pq>
emersion, I guess because it was a practical way to have the interface handler functions called with the right arguments and type safety, and not generating dispatcher code with scanner.
<pq>
emersion, the API use by all other lang bindings came much much later.
<pq>
emersion, many odd details in libwayland are probably because they were "cool tricks", like wl_fixed_to/from_double.
<ifreund>
what would the alternative look like in C? In zig I use compile-time metaprogramming to handle the dispatching and make it type safe
<ifreund>
would a C version using the non-ffi API generate a separate C dispatcher function for each protocol?
<ifreund>
s/protocol/interface/
<pq>
ifreund, we'd do the equivalent in C, too. Generate a dispatcher function for each message that unwraps the arguments to call a properly typed function pointer.
<pq>
When we have a build-time code generator and the signatures are fixed at build-time, there is no real need for libffi.
<ifreund>
I generate a tagged union for the message types and this function reflects on that generated tagged union type to do marshaling
<ifreund>
might be able to make it a bit cleaner, been a while since I've looked at it
<emersion>
i must say, comptime looked like a good way to do generics but i'm a bit disappointed that it's basically copy-paste
<emersion>
ie, i can write non-sensical code with comptime, and the non-sense only gets found out when a particular comptime call triggers it
<emersion>
sorry, this is off-topic
<emersion>
(so when do we rewrite libwayland in zig :P )
<ifreund>
once zig is stable :P
<emersion>
"you can't rush art"
<ifreund>
emersion: since comptime is also how zig does conditional compilation, the compiler needs to be lazy in at least some cases. That said, there are likely cases where we can make it less lazy than it is now without breaking things
<emersion>
hm, what i meant was that it
<emersion>
'd be nicer if the type constraints were clearly defined for a given comptime function
<ifreund>
yeah, I totally get that complaint. I think that road leads to haskell/ML style type classes though
<emersion>
which is clearly a trade-off, because type constraints make stuff more complicated as well
<ifreund>
and I'm not sure if that's the right road for zig to take
<emersion>
i was thinking rust but sure :P
<emersion>
yeah, it's a choice
<ifreund>
just gotta pick the right language for the job, I've found Zig to be fantastic for writing wayland compositor code :)
<emersion>
or so i've heard :)
Leopold has quit [Ping timeout: 480 seconds]
Leopold_ has joined #wayland
Fxzxmic has joined #wayland
Fxzx_mic has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
pochu has quit []
Leopold_ has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
Moprius has joined #wayland
Leopold_ has joined #wayland
Moprius has quit [Read error: Connection reset by peer]
Moprius has joined #wayland
kts has joined #wayland
Moprius has quit [Quit: bye]
Fxzxmic has quit [Quit: Konversation exit!]
Leopold_ has quit []
Leopold has joined #wayland
junaid has joined #wayland
Leopold has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
junaid has quit [Remote host closed the connection]
jmdaemon has quit [Ping timeout: 480 seconds]
Leopold has joined #wayland
robobub has quit []
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #wayland
jmdaemon has joined #wayland
Leopold_ has quit [Ping timeout: 480 seconds]
Leopold_ has joined #wayland
fmuellner has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
Leopold has quit [Ping timeout: 480 seconds]
* kchibisov
still hopes for a future without libwayland hard dep for any real wayland client side stuff.
tzimmermann has quit [Quit: Leaving]
gspbirel56 has quit [Read error: Connection reset by peer]
mvlad has quit [Remote host closed the connection]
dcz_ has quit [Ping timeout: 480 seconds]
Narrat has joined #wayland
ybogdano has joined #wayland
keir has quit [Quit: I've gone.]
___nick___ has joined #wayland
Moprius has joined #wayland
keir has joined #wayland
Moprius has quit [Quit: bye]
astlep4 has joined #wayland
rv1sr has quit []
<yshui`>
hi, i am here with a wl_buffer.release question again. i can think of 2 cases when a buffer is "no longer used by the compositor". one is when the client attached a new buffer to the surface, and this new state become the current state through a series of wl_surface.commit; the other is when the compositor has made a copy of the content of the buffer, and thus no longer needs to access the buffer.
<yshui`>
I assume the compositor will send wl_buffer.release in both cases?
<yshui`>
another question is, is a released buffer is detached from all surfaces, then attached to a surface again, would it receive a release event again in the future?
<bl4ckb0ne>
yes
kts has quit [Quit: Konversation terminated!]
<bl4ckb0ne>
when the surface is committed
<bl4ckb0ne>
about the first case iirc its a client error to attach two buffers to a surface before committing because only the last one will get a release event but ill have to check
<soreau>
you could probably check with WAYLAND_DEBUG to get a picture of what $compositor actually does