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]
grinja2 has left #wayland [...leaving]
sevz has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
carlos_ has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
carlos_ has quit [Ping timeout: 480 seconds]
crazybyte2 has joined #wayland
crazybyte has quit [Ping timeout: 480 seconds]
crazybyte2 is now known as crazybyte
gfxstrand has quit [Ping timeout: 480 seconds]
gfxstrand has joined #wayland
tzimmermann has joined #wayland
mblenc1 has joined #wayland
sewn has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
mblenc1 has quit [Ping timeout: 480 seconds]
mblenc1 has joined #wayland
sevz has quit [Ping timeout: 480 seconds]
mblenc has quit [Ping timeout: 480 seconds]
mblenc1 has quit [Ping timeout: 480 seconds]
junaid has joined #wayland
junaid has quit [Remote host closed the connection]
mbalmer has joined #wayland
rasterman has joined #wayland
iomari891 has joined #wayland
i509vcb has quit [Quit: Connection closed for inactivity]
Company has joined #wayland
carlos_ has joined #wayland
leon-anavi has joined #wayland
systwi has joined #wayland
systwi_ has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
systwi_ has joined #wayland
systwi has quit [Ping timeout: 480 seconds]
mvlad has joined #wayland
<pq> zamundaaa[m], RAOF, I totally agree with your opinions in the xdg-placement discussion, FWIW.
<pq> I don't intend to get more involved than I already have.
AnuthaDev has joined #wayland
<pq> we have so many wl_proxy_marshal_*() functions it's hard to tell which ones are the latest recommended ones
leon has joined #wayland
<zzag> The satellite window idea is interesting
Net147 has quit [Quit: Quit]
Net147 has joined #wayland
cmichael has joined #wayland
rv1sr has joined #wayland
fmuellner has joined #wayland
carlos_ has quit [Quit: carlos_]
carlos_ has joined #wayland
pounce has quit [Remote host closed the connection]
pounce has joined #wayland
Moprius has joined #wayland
Moprius has quit [Quit: bye]
nerdopolis has joined #wayland
sevz has joined #wayland
<JoshuaAshton> Has anyone considered adding 64-bit types to Wayland? It would obviously be a big change, and need a newer libwayland for newer protocols, but I think we use enough 64-bit types that it would be justified? Very often we are doing _lo and _hi for serials, timestamps, etc.
<soreau> what's the use case?
<soreau> seems like there would be twice the overhead on the socket for no real gain
<kennylevinsen> the wire protocol could just be 2x 32-bit
<JoshuaAshton> The usecase would be stuff we are already sending uint64_ts now but as separate hi and lo parts
<JoshuaAshton> The wire protocol already is that, but we do it often enough that it really should be first-class imo
<kennylevinsen> Main point is "what would be gained by the libwayland breakage that two 32-bit ints does not handle"
<ascent12> Basically, not worth the breakage just for that. Maybe worth sneaking in if there was a breakage for something else.
<JoshuaAshton> I mean, not really "breakage" if nothing existing breaks. It would only be an incompatibility with newer protocols.
<kennylevinsen> ABI breakage
<ascent12> ^
<ascent12> See 'union wl_argument'
<JoshuaAshton> I see, that would break ABI on 32-bit
<JoshuaAshton> bleh
<JoshuaAshton> Welp
<pq> unless the u64 is behind a pointer, which is also bleh
<pq> but wouldn't hurt the user facing generated API
<kennylevinsen> it's hard to justify breakage when it does not enable something new :(
<pq> well...
<pq> maybe it would be worth it, and not hurt anythin
<jadahl> maybe it can be 64 bit in the xml and generatec C API, with wayland-scanner hiding the hi/lo boilerplate. sounds complicatedt though
<pq> that's an alternative
<pq> or we can have union wl_argument { ... uint64_t *pu64; };
<jadahl> zamundaaa: thanks for arguing for sanity btw. i'm on pto so keeping to the sidelines until i actually have time
<pq> we already have a pointer in that union
sevz17 has joined #wayland
qyliss has quit [Remote host closed the connection]
<pq> negotiation for uint64 support would be really simple: a server just won't advertise and a client just won't bind a global that would use u64 if libwayland is too old.
sevz has quit [Ping timeout: 480 seconds]
qyliss has joined #wayland
vyivel has quit [Remote host closed the connection]
<pq> I don't see any technical problem adding a 64-bit wire datatype. Or float types.
i509vcb has joined #wayland
<JoshuaAshton> I didn't even realise wl_argument was ABI
<JoshuaAshton> I guess it is in wayland-util.h yeah
<pq> it's used by probably all other language bindings than wayland-scanner's
<JoshuaAshton> I recently did a VK_GOOGLE_display_timing impl for Gamescope and was like... hmmm... lots of _lo and _hi here :P
<JoshuaAshton> I imagine satisfying for VK_EXT_present_timing would be even more lo hi x)
vyivel has joined #wayland
<pq> I wouldn't nak the addition of uint64_t, float or double in wire types.
<JoshuaAshton> That's good to know. I think I'd want to use float types at some point for gamescope private protocol with Steam someday :)
<JoshuaAshton> Right now we are using properties on the root XWayland server window and just bitcasting floats there, which is kinda gross, but works
<JoshuaAshton> Wanting to move away from that... slowly
<pq> IIRC I'm already using floats, just wrapped in a wl_array...
<JoshuaAshton> Oh? How does that work, are you just bitcasting as some generic 32-bit type?
<JoshuaAshton> Never touched wl_array actually
<pq> wl_array on the wire is essentially a bag of bytes
<pq> wl_array C API kinda assume you have an array of <any C type>, but it could also literally be a bag of bytes
<pq> wl_array on the wire has a little bit of overhead: the size
<pq> since the size is variable
<pq> weston_touch_calibration_save() is a wayland-scanner generated request sender
<pq> ooh, I think I saw a bug
<Company> swick[m], robertmader[m]: re https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/441#note_2106725 - it would be convenient if that layering stuff wouldn't need to be managed by creating subsurfaces, but applications could just submit multiple buffers for the same surface
kts has joined #wayland
<Company> if you combine that with wp_viewporter's positioning, it's already good enough for video playback
<pq> Company, what would that do, and how is it different from sub-surfaces?
<Company> pq: it's different from subsurfaces in that I don't need to manage the subsurfaces and don't get into stacking and input games
<Company> pq: and it would just composite the N buffers on top of each other - with potential offloading to hardware and all that jazz
<pq> so how would you manage the multiple buffer on the same wl_surface?
<pq> what kind of protocol interface, and how would that differ from wl_subsurface?
<Company> dunno, something like surface_attach_with_z (int z_index, wl_buffer buffer)
<pq> how do you move/position them?
<pq> (hint: we are on the road to re-invent wl_subsurface here)
<Company> like wp_viewporter does, jsut again with a z-index
<pq> wp_viewporter ties to the wl_surface and has no z-index
<Company> right, you'd need a new function for that
<pq> why not use an actual protocol object instead of a z-index that could easily be lost track of?
vyivel has quit [Read error: Connection reset by peer]
<Company> could make it an actual object, too
<pq> why should that protocol object duplicate the attach and other requests from wl_surface when it could, well, tie to an actual wl_surface?
<Company> because a wl_surface does tons of other stuff
<pq> it doesn't, really
<pq> not much
kts has quit [Ping timeout: 480 seconds]
<Company> but you could try to do it with subsurfaces - or a new role - too
vyivel has joined #wayland
<pq> in the end, I think what the protocol looks like here is small peanuts, and the hard part is in the client to choose the scenegraph splitting points and render the different buffers.
<Company> there's just a bunch of things that need updating on the surface (like buffer scale and size) that would be bound to the actual surface if this was just about buffers
<pq> true
<pq> and hardcode input region to empty
<Company> yes and no - GTK manages surfaces in a different part of the code than rendering
<Company> and rendering would be the part that decides how to split, so would need to create the surfaces
<pq> oh, so you just wanted something that fits better your internal architecture
<Company> of course :)
<Company> I was actually wondering if this was a general thing
<Company> I have no idea how other toolkits or Firefox or compositors do this
vyivel has quit [Read error: Connection reset by peer]
<pq> me neither, but I wouldn't want to add protocol interfaces that are just sub-sets of already existing interfaces that would work just as well from protocol design point of view.
<daniels> yeah, especially when you attach HDR metadata to your YUV surface and now your RGB subtitles are unreadably bright
<Company> right, HDR metadata would need to be per-buffer
<pq> heh, somehow I didn't even think of that :-D
<pq> color metadata is per wl_surface for now
<Company> the Wayland protocol has struggled with per-buffer vs per-surface more than once
<Company> but yeah, you need to negotiate the color stuff in advance
<pq> is there actually any API (GL, Vulkan, ...) that would associate color metadata with buffers?
<pq> a Wayland WSI could always do it for you, but...
<Company> I think Vulkan only has color metadata in the swapchain
<Company> apart from the RGB texture formats
<pq> and EGL does not expose buffers at all
<Company> *sRGB
<Company> but I guess the sRGB texture formats count as per-buffer color metadata?
<pq> I suppose
<pq> given we have the wl_surface.commit mechanism, surface vs. buffer doesn't make that big a difference. But being on surface means that you can, if you want to, manually manage the color metadata EGL Wayland platform.
vyivel has joined #wayland
<Company> I mean, the end goal here is to create an app window with UI and an image that sits in a dmabuf
<Company> either video or from a VM
<Company> and being able to seamlessly transition back into compositing into a single surface
<Company> like when switching tabs in the app
<daniels> subsurfaces do let you do that
<Company> I'm just thinking
<Company> we could let widgets reserve surfaces with the renderer
<Company> and if the renderer determines that it can't use the surface - for example because the contents are rotated or otherwise not easily blendable - we skip the surface
<Company> just unset the surface's buffer
<Company> and composite onto the toplevel
kts has joined #wayland
tzimmermann has quit [Quit: Leaving]
<pq> Company, the decision to off-load an element as a (sub)surface to the compositor should not be "can I do it" but more of "how likely this could benefit from direct scanout".
<Company> sure
<Company> it's a combination of both really
<pq> naturally :-)
<Company> but just like with direct scanout, the "can I do it" part is something you need to determine automatically, and not via some app-level setting
<pq> what app-level setting?
<pq> I mean, indeed
leon has quit [Remote host closed the connection]
leon-anavi has quit [Read error: Connection reset by peer]
cphealy has joined #wayland
<wlb> wayland-protocols Issue #159 closed \o/ (Make inlined methods accessible for other compilers than gcc or clang. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/159)
Plagman has quit [Read error: Connection reset by peer]
Plagman has joined #wayland
stshine has joined #wayland
cmichael has quit [Quit: Leaving]
stshine has quit [Remote host closed the connection]
caveman has quit [Quit: caveman]
caveman has joined #wayland
opotin65 has quit [Remote host closed the connection]
opotin65 has joined #wayland
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
mblenc1 has quit [Ping timeout: 480 seconds]
Satan2 has quit [Remote host closed the connection]
<swick[m]> Company: I don't really get why it would be so hard to create subsurfaces on demand with gtk
nerdopolis has quit [Ping timeout: 480 seconds]
tent405 has quit [Quit: tent405]
ids1024 has quit [Quit: WeeChat 3.7.1]
ids1024 has joined #wayland
<lileo> > and if the renderer determines that it can't use the surface - for example because the contents are rotated or otherwise not easily blendable - we skip the surface
<lileo> That has to be a compositor decision, no? whether direct scanout can happen depends heavily on the display hardware
flom84 has joined #wayland
Cyrinux9474 has quit []
Cyrinux9474 has joined #wayland
<swick[m]> this is about gtk deciding to render the entire tree into a single surface or parts of the tree into subsurfaces
<lileo> ah
<lileo> the decision to make here sounds quite similar to what libliftoff does on the compositor side
kts has quit [Ping timeout: 480 seconds]
<swick[m]> not really. libliftoff is concerned with figuring out if you can put something on an overlay plane. a compositor still has to provide planes to libliftoff. for gtk the hard part is figuring out what parts of the render tree should become surfaces/planes.
iomari891 has quit [Ping timeout: 480 seconds]
ids1024 has quit [Quit: WeeChat 3.7.1]
ids1024 has joined #wayland
<lileo> right, libliftoff today just tries to maximize hw plane usage with whatever it's given. Though theoretically, it has kind of a similar problem
<lileo> compositors can create an arbitrary number of layers, while there are only a few hw planes available
<lileo> So it's important to select the most beneficial layers
<lileo> there's some code there that elevates a layer's offload priority if it's updating frequently
<lileo> but not used anywhere
ids1024 has quit [Quit: WeeChat 3.7.1]
Moprius has joined #wayland
<kennylevinsen> I wonder if it just boils down to a threshold for update rate for certain widget types, or even just always for those widget types in some contexts…
ids1024 has joined #wayland
haasn` has joined #wayland
mblenc has joined #wayland
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
tent405 has joined #wayland
soreau has quit [Remote host closed the connection]
soreau has joined #wayland
soreau has quit [Read error: Connection reset by peer]
soreau has joined #wayland
lbia has quit [Remote host closed the connection]
lbia has joined #wayland
kts has joined #wayland
kts has quit []
kts has joined #wayland
iomari891 has joined #wayland
<swick[m]> I think that's spot on. Some kind of update frequency estimate provided either by the user or by some widgets. E.g. a video widget can guess that subtitles update every few seconds and the video itself around 30 times.
<Company> swick[m]: I have no idea how expensive surface creation is
<swick[m]> shouldn't be expensive...
<Company> and how much work is involved there - like if setting sizes and such is just a bunch of commands or if roundtrips are required
<swick[m]> you probably know all the things you care about from the toplevel so it should just be a bunch of requests without roundtrip
<Company> and of course, there's the Vulkan/GL wsi
<Company> which isn't built around rendering to multiple surfaces at once
<swick[m]> don't use it :>
<Company> I will consider that once the dmabuf code is not a huge amount of magic
<swick[m]> nice
Moprius has quit [Quit: bye]
<Company> I've been wondering about using GTK without a display anyway
<Company> to be able to do rendering
<Company> so having generic GL would be neat
crazybyte4 has joined #wayland
<kennylevinsen> creating a surface is free, issue is allocating a buffer and rerendering - need to be a bit smart about it
<Company> true, if there's too many surfaces and we create swapchains for each, we might allocate a bit much memory
<swick[m]> thus, no wsi
<Company> well, even without wsi we run into that issue
<Company> the biggest benefit of avoiding wsi is that we can resize
<swick[m]> well, the buffers can be added to any surface instead of being bound to a specific one
<Company> that too
AnuthaDev has quit [Remote host closed the connection]
AnuthaDev has joined #wayland
AnuthaDev has quit [Remote host closed the connection]
<Company> we have to send one per surface to the compositor though
<swick[m]> and be lazy with allocating I think
<Company> doesn't GL do that?
<swick[m]> yes, but not vulkan
<Company> Vulkan doesn't I think
<swick[m]> iirc there was an extension to allow this
AnuthaDev has joined #wayland
<Company> I'm sure there was
crazybyte has quit [Ping timeout: 480 seconds]
crazybyte4 is now known as crazybyte
<Company> hrm, can you do a fade-in by keeping the buffer and changing the colorspace every frame?
<Company> I guess?
kts has quit [Ping timeout: 480 seconds]
<swick[m]> yes
<swick[m]> please don't
mbalmer has quit []
<Company> for (nits = 0; nits < 1000; nits += 1000/framerate) { ... }
AnuthaDev has quit [Quit: AnuthaDev]
<Company> I think that doesn't handle transparency properly anyway
crazybyte7 has joined #wayland
<swick[m]> creating image descriptions is probably much more expensive than creating surfaces
<kennylevinsen> There was a talk about an opacity protocol to not need rerender I think
crazybyte has quit [Ping timeout: 480 seconds]
crazybyte7 is now known as crazybyte
<Company> there's talk about many protocols
<Company> like reddit is talking about a window placement protocol
<Company> yup
mblenc has joined #wayland
mblenc1 has quit [Ping timeout: 480 seconds]
mblenc1 has joined #wayland
julio7359 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
julio7359 has quit [Remote host closed the connection]
leon-anavi has joined #wayland
mblenc has joined #wayland
mblenc1 has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
flom84 has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
cool110 is now known as Guest1699
Guest1542 has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
mblenc1 has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
mblenc has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
leon-anavi has quit [Quit: Leaving]
doraskayo has joined #wayland
i509vcb has quit [Quit: Connection closed for inactivity]
nerdopolis has quit [Ping timeout: 480 seconds]
doraskayo has quit [Quit: Reconnecting]
doraskayo has joined #wayland
doraskayo has quit []
doraskayo has joined #wayland
nerdopolis has joined #wayland
rv1sr has quit []
kts has joined #wayland
Company has quit [Remote host closed the connection]