ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
sally has quit [Remote host closed the connection]
glennk has quit [Ping timeout: 480 seconds]
sally has joined #wayland
<jadahl>
daniels: I saw, will make one tonight
nerdopolis has quit [Read error: Connection reset by peer]
nerdopolis has joined #wayland
bindu_ has quit [Ping timeout: 480 seconds]
bindu has joined #wayland
Moprius_ has joined #wayland
Moprius has quit [Read error: Connection reset by peer]
ramblurr_ has joined #wayland
ramblurr has quit [Ping timeout: 480 seconds]
ramblurr_ is now known as ramblurr
Brainium has quit [Quit: Konversation terminated!]
Moprius_ has quit []
<soreau>
I wanted to make a backdrop display using a background app and some app that displays time and weather with weather icon. Background apps are plenty.. does anyone have suggestions on possibly existing implementations for an app with transparent background featuring time/temp/weather-icon that is configurable?
karenw has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
juwain has joined #wayland
azerov has joined #wayland
pavlushka has joined #wayland
kts has joined #wayland
pavlushka has quit [Ping timeout: 480 seconds]
pavlushka has joined #wayland
andymandias has quit [Remote host closed the connection]
<pq>
emersion, right. Mastering Display Color Volume (MDCV) is defined for image content that has been graded/mastered on a display.
kts has quit [Ping timeout: 480 seconds]
<pq>
emersion, the description of a (compositor's) display is not mastered, it's a display and not content, so using MDCV for it sounds weird. Hence we use "target color volume".
<pq>
emersion, content targets a color volume (the MDCV), and a display has a target color volume (what it can actually display).
kts has joined #wayland
<pq>
ezzieyguywuf, pkgdatadir variable from wayland-protocols.pc
<pq>
If you have sRGB content but PQ display, you decode the content with gamma22 (the "exactly once" thing"), do the conversion to HDR and encode for PQ
<emersion>
all makes sense, thank you!
<emersion>
sorry about all of the questions!
<pq>
If you have PQ content and sRGB display; decode with PQ, tone-map down to SDR (assuming tone-mapping algorithm was defined in optical spaces), and encode with gamma22 so that when display decodes with gamma22 it produces what you encoded.
<emersion>
yup, encoding with srgb tf doesn't make sense in that case
<pq>
emersion, oh, no, not at all. If you want to give back on the same topic, you can suggest stuff to color-and-hdr. :-)
rgallaispou has quit [Read error: Connection reset by peer]
rgallaispou has joined #wayland
<WhyNotHugo>
Protocol definitions don't specify whether a given interface is an singleton or not. Is there any way to determine this, or should clients/libraries just keep a hardcoded list?
<kennylevinsen>
The protocol doesn't support singletons - that would require being able to return a newid *or* an old object ID
<emersion>
i think you mean "global"
<emersion>
there is an issue about this
<emersion>
i don't think clients need any kind of database like this - you need code to bind to a global anyways
<pq>
The singleton terminology tends to only apply to interfaces that are advertised via wl_registry, a.k.a "globals". The protocol XML codifies neither singleton'ess nor globals.
<pq>
Nor does the protocol codify whether a global can dynamically appear or disappear.
<pq>
WhyNotHugo, why would you need this information?
<kennylevinsen>
I guess it wouldn't hurt to formally codify even if no program will depend on it
<zamundaaa[m]>
pq: if xdg shell can appear twice, you'd need code guarding against that case to avoid leaks
<WhyNotHugo>
Client libraries sometimes special-case binding to single-instance globals. But trying to bind to a non-single-instance global (e.g.: a seat) is left as undefined behaviour.
<pq>
How would the protocol codifying globals and singletons help?
<davidre>
I wonder if people would start today if wl_output would not be a global but a wl_output manager
<davidre>
(disregarding the question if wl_output should exist or not)
<pq>
I would probably need to see the code to undertand problem well, but it's too late today for me.
riteo has joined #wayland
<emersion>
davidre: yeah, i think that's the way i would do it (but would also think avoir a better way to deal with server-side created object races)
rasterman has quit [Quit: Gettin' stinky!]
<WhyNotHugo>
pq: codifying that objects are singletons would enable generated client libraries to prohibit using non-singletones in APIs for singletons (e.g.: detecting them at compile time)
<WhyNotHugo>
(this is mostly the case in helpers which wrap around wl_registry).
<WhyNotHugo>
davidre: ya, output_manager is obvious in hindsight
<pq>
I guessed this was about a Rust abstraction :-)
<pq>
WhyNotHugo, is this a convenience function so that the caller does not need to shuffle thought a list of one global?
<pq>
and you want the app to fail to build if it tries to bind a non-singleton as a singleton?
<pq>
WhyNotHugo, are things like struct WlCompositor generated from XML?
<pq>
yeah, seems like it would be nice to codify globals and singletons in XML.
iomari891 has quit [Ping timeout: 480 seconds]
<WhyNotHugo>
Yes, it's a convenience function
<pq>
something like interface attribute generic-factory="wl_registry"
<WhyNotHugo>
All clients and stuff are auto-generated at compile-time from the XML files.
iomari891 has joined #wayland
<DemiMarie>
pq: Would it make sense for the XML to specify the error one gets when trying to use a nonexistent enum value?
<ezzieyguywuf>
pq: thank you!
<pq>
DemiMarie, usually that's is documented.
<ezzieyguywuf>
I've been toying around with wayland and vulkan, and one thing I'm a bit confused about is the difference/relationship between a wl_surface and a VK_KHR_surface - it seems I can use vkCreateWaylandSurfaceKHR to create a VK_KHR_surface FROM a wl_surface, but it's unclear to me if I even need to do this
<DemiMarie>
pq: I'd like to autogenerate the validation code.
<pq>
DemiMarie, that would need to be an attribute of the request that uses the enum, since there may be multiple such requests in different interfaces without a common error code.
<DemiMarie>
pq: that is what I was thinking, yes
<pq>
in the arg tag, actually, since a request might have multiple enum args
<DemiMarie>
Also, mind reviewing my PR for busy-loops in the server?
<pq>
sounds doable, but I can't judge if it's worth it
<pq>
no, sorry
<DemiMarie>
Who should I ping for that?
<pq>
I have to prioritize harsly nowadays what I do
<DemiMarie>
Is it just a case of "be awake morning EU time"?
<pq>
I dunno, I don't track much who's active on libwayland anymore
<pq>
I should have stopped for the day already, I'll be back on Monday. \o.
bindu_ has quit [Ping timeout: 480 seconds]
bindu has joined #wayland
neverthelessmaniac has joined #wayland
sewn has quit [Remote host closed the connection]
sewn has joined #wayland
TheCaptain82970403198578471379 has joined #wayland
neverthelessmaniac has quit [Ping timeout: 480 seconds]
pavlushka has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
Narrat has joined #wayland
ohogb has joined #wayland
pavlushka has quit [Ping timeout: 480 seconds]
feaneron has quit [Remote host closed the connection]
feaneron has joined #wayland
<riteo>
Hi, no idea if this is the right place. Can somebody please clear me up on whether the xkb_state from libxkbcommon is supposed to be per-window or per-seat? It looks like everybody is doing it per-window but looking in the documentation I see no reason as of why; we only have a wl_keyboard per seat.
<riteo>
well a seat is going to have a single keyboard focus anyways
<riteo>
like, I already have a xkb_state per seat
<riteo>
but I got told years ago that I should not do that for multiple windows but now that I'm actually doing that I don't know why I should.
<orowith2os[m]>
Maybe not? You could have several windows running that receive input events
<orowith2os[m]>
Either through automation or weird compositor setups
<riteo>
isn't the keyboard event sent from the wl_keyboard
<riteo>
like, currently I do wl_keyboard::key -> get seat state for that kb -> look at focused window id -> build "toolkit" input key event with the right id
<riteo>
(I say toolkit for clarity but it's still godot, as usual)
sima has quit [Ping timeout: 480 seconds]
<orowith2os[m]>
I'm trying to make sense of the wl_seat stuff to see if it would cause problems, I'm not seeing anything about several seats not being allowed
<orowith2os[m]>
So you could, I guess, have two different wl_surfaces getting wl_keyboards from two different wl_seats
<riteo>
yes but doesn't it work, like, backwards
<riteo>
as in, wl_seats track keyboard focus?
<riteo>
wait a sec
<riteo>
ye wl_pointers and wl_keyboards get enter events
<riteo>
so like it should be fine to track everything per seat, it should be unnecessary to have a whole xkb state per window
<riteo>
but everybody's doing it different and I'm not sure why
<riteo>
like, my mental model seems to allow multiple seats per window fine
<riteo>
it's the seat that tracks the window after all
karenw has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
riteo: your mental model is correct
<zamundaaa[m]>
You could have two seats that have the same window focused, and keyboard state should be per seat
<riteo>
yay!
<riteo>
thank you zamundaaa for clarifying :DDDDDDDDDDDDDDDDDDD
iomari891 has joined #wayland
ohogb has quit []
ohogb has joined #wayland
ohogb has quit []
ohogb has joined #wayland
dviola has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
paulk-bis has joined #wayland
paulk has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
mvlad has quit [Remote host closed the connection]
iomari891 has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
Calandracas has quit [Remote host closed the connection]