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
<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]
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?