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
bindu has quit [Quit: leaving]
bindu has joined #wayland
Moprius has joined #wayland
busheling has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 483 seconds]
Moprius has quit [Remote host closed the connection]
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
molinari has quit [Ping timeout: 480 seconds]
julio7359 has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
AJ_Z0 has quit [Read error: Connection reset by peer]
AJ_Z0 has joined #wayland
naveenk2 has joined #wayland
ppascher has joined #wayland
naveenk2 has quit [Ping timeout: 480 seconds]
naveenk2 has joined #wayland
naveenk2 has quit [Ping timeout: 480 seconds]
naveenk2 has joined #wayland
<manuels>
Is portals spec bound to flatpak? Or can i consider it to be a desktop standard (like eg basedirs and icon lookup)
molinari has joined #wayland
ngortheone has quit [Remote host closed the connection]
dcz_ has joined #wayland
ppascher has quit [Quit: Gateway shutdown]
tzimmermann has joined #wayland
hardening has joined #wayland
busheling has quit [Remote host closed the connection]
busheling has joined #wayland
danvet has joined #wayland
<MrCooper>
manuels: the latter
<MrCooper>
portals are also window system agnostic, they can work the same in a Wayland or X session
<pq>
perhaps the success of portals is the reason why a Wayland extension didn't get attention
manuel1985 has joined #wayland
SystemXProc has left #wayland [#wayland]
<emersion>
some people were interested iirc
<emersion>
but ended up just doing their own custom proto in the end
<pq>
oh well
<emersion>
one downside of w-p is that ext requires acks from two members
<emersion>
and wlroots is just a single member
<emersion>
so if two wlroots compositors are interested in a protocol, we still cannot land it
<emersion>
also people are just scared about w-p in general
<emersion>
(i am too)
<pq>
because I might end up reviewing something, and I'm just insane in that?
<emersion>
lol
<emersion>
no, it's just that it's well-known for its MRs stuck forever
<emersion>
i am considering re-opening wlr-protocols, sadly
<pq>
I thought that has been running forward all the time
<emersion>
it's been frozen once w-p governance has been merged
<pq>
I hadn't realized that.
<pq>
I have nothing against compositor specific extensions. I see it as a good way to experiment with extensions, they won't accidentally clash with wayland-protocols if someone rushes an implementation release out.
<emersion>
our stance has been to push for ext- protocols, but that hasn't really worked out
<pq>
With wayland-protocols I'm always on my toes about someone taking an unmerged extension and releasing an implementation of it.
<ifreund>
it's already happening with hyprland, waybar and ext-workspaces apparently
<emersion>
yeah :/
<emersion>
there's also the famous virtual-keyboard and input-method fiasco
<SardemFF7>
I’m so sad I’m not famous enough that the reason the action binder protocol wasn’t merged is not that my name is on it :'(
<emersion>
i am not sure how to parse that sentence
<emersion>
ah, so: if you were famous enough, you'd have an excuse for the proto not being merged?
<emersion>
too many negatives, sorry :o
<SardemFF7>
yeah, because just having my name on it would be a hard veto from wlroots :-P
<emersion>
eh
<emersion>
not really
<emersion>
i like your proposal
<emersion>
my concerns with your previous protocols were only about the protocols themselves
<qyliss>
(I understand it still needs acks, but there should be enough implementations now, right?)
<emersion>
qyliss: ah, is there a way you can update your impl for the latest protocol version?
<SardemFF7>
emersion: technically, since I wrote them, I may still be the problem :-D
<qyliss>
emersion: I can put it on my list
<emersion>
cool!
<qyliss>
realistically it might be a month or two before i can get to it
manuel1985 has quit [Ping timeout: 480 seconds]
<emersion>
ack
<qyliss>
cc puck_
<jadahl>
I don't think it's a problem with governance when it comes to ext_ in w-p, since it'd just need a wlroots impl and some user of the protocol. it more seems to be a problem of trying to make an initial version cover every concievable use case and discussions about details related to that going on for month after month after month
<emersion>
jadahl: the ACKs need to be wlroots plus… someone else
<emersion>
the impls aren't the issue
<emersion>
but yeah, it seems like there's always someone (sometimes me) coming in with new comments…
<jadahl>
maybe one app ack shouldn't need to be a "member" then?
<emersion>
so, for ext, an ack from a third-party would be okay? sounds sensible
<jadahl>
sounds sensible
<qyliss>
Is there any reason to not just for for ext, when trying to standardise a protocol?
<qyliss>
If I were proposing a new protocol, why would I push it harder for wp or xdg, when I could more easily get it into ext?
<jadahl>
wp_ and xdg_ are typically meant to be protocols used by a more wide range of applications, not just DE components, so it makes sense to have some more "strict" control
<pq>
also more wide range of compositors
<jadahl>
and for wp_, not only application, but e.g. OpenGL/Vulkan drivers too
<ifreund>
> it more seems to be a problem of trying to make an initial version cover every concievable use case and discussions about details related to that going on for month after month after month
<ifreund>
I also see this as the main problem
<ifreund>
allowing a non-member implementor to ACK ext protocols seems reasonable to me though
naveenk2 has quit [Ping timeout: 480 seconds]
sozuba has joined #wayland
<qyliss>
but like, if I'm proposing a protocol, why do I care about getting into wp_?
<qyliss>
it seems like I'd get to pick between going through a hard process or a slightly easier process, with very little incentive to choose the hard process
<qyliss>
or am I misunderstanding ext? would somebody ever say "this protocol would be used by too wide a range of applications and compositors, so ext isn't the right place for it and you need to target wp_"?
<jadahl>
whether something is "plumbing" (wp), "window management" (xdg), or the rest depends on what the protocol is, not your willingness to adhere to level quality control procedures
<qyliss>
got it
<qyliss>
that makes more sense
<zzag>
"not just DE components" I'm personally not sure whether it's a good idea to push DE protocols upstream because even though DEs provides similar features, they still differ, and those differences are reflected in the protocols, which other communities may not be fond of and actually block the attempts to upstream them
<zzag>
there are cases, such as layer-shell, that do make sense to be upstream
<emersion>
do you have examples of differences?
<jadahl>
zzag: sometimes it does indeed make no sense. currently looking into adding one to gnome that is just meant to map wayland xdg_toplevel's on top of X11 windows, and it's special and "unique" enough to have no urge to put that upstream
<jadahl>
also because its stupidly tiny
<zzag>
emersion: well, one example is the output order thing
<emersion>
output order?
<zzag>
plasma sorts outputs as primary, secondary, tertiary, etc
<emersion>
ah, yes
<jadahl>
for things like input_method it's a different story
<zzag>
++ it would be nice to clean input method and text input protocols. kwin has three text input protocol implementations because there are apps and toolkits that refuse to stick with one particular version of the protocol for various reasons :/
<pq>
emersion, FYI, KMS enum property with values as blob ids or array indices into a blob are being baked in the 3D LUT property patches.
<emersion>
is the blob attached to planes?
<pq>
The blob is read-only, the enum is a CRTC or plane property that userspace writes.
<emersion>
so each plane has a blob and an enum?
<emersion>
or is the blob a more global thing?
<pq>
so the blob only explains what the enum values mean
<emersion>
ouch
<emersion>
that sounds painful
<pq>
the blob is just a much more flexible and bigger data structure than the value name string
<pq>
otherwise the usage is roughly the same
<emersion>
it would be less painful if the blob was per-device
<emersion>
or even per-CRTC
<emersion>
rather than per-plane
<pq>
I *think* the current idea is that the enum property lists the possible values, each value is actually a blob id, and you need to fetch and parse that blob to understand what value would do.
<emersion>
oh
<emersion>
so one blob per enum entry?
<emersion>
that doesn't sound bad
<emersion>
if it was an index/offset to a per-plane blob it'd be more annoying
<pq>
yeah, but who's to say the blobs are per-enum-value, per-device or something else
<pq>
you just get a blob id, and the same id could appear elsewhere too
<emersion>
i'm just describing the level of annoyance for my user-space projects
<pq>
sure
<emersion>
okay, if it's a blob ID it's perfectly fine
<emersion>
the thing i'd struggle with is… a uint64 prop value which changes its meaning depending on the plane
<pq>
I did first think that maybe the enum value is an index into a blob containing an array of descriptions, and you get the blob from some other property, but maybe that was not it.
<pq>
blob ids are not global, are they? They are local to the device (driver instance), right?
<emersion>
yes
<emersion>
per-plane scope vs. per-device scope
<emersion>
former makes me unhappy, latter makes me happy :P
<pq>
so they are not hardcodable like the old uAPI enums
<emersion>
yea
<pq>
and not even transferrable from device to another on the same run
<emersion>
right, and you need to introspect the prop to be able to tell what the choices are even
<emersion>
but if that complexity is justified, that's completely fine
<pq>
yes, well, that you need to do always. I don't think any enum prop guarantees that all defined values are always possible.
<emersion>
i'm not a fan of arbitrarily making things more complex, e.g. when it's just a simple enum and one still needs to introspect
<emersion>
well, the kernel will EINVAL you anyways if the enum entry is not available
<pq>
right, but that's annoying to handle, isn't it?
<emersion>
no, libliftoff just tries something else
<emersion>
the kernel will EINVAL you for any other hw-specific reason as well
<pq>
if you're happy brute-forcing things that would have been known before-hand...
<emersion>
libliftoff can check that the enum is advertised, that's a detail
<emersion>
the core of the issue is that libliftoff exposes "layers", virtual planes where the lib user sets arbitrary KMS props
<emersion>
so for instance the user creates a layer with "COLOR_ENCODING" set to 42
<emersion>
and then libliftoff does its own magic to pick a plane for this layer
<emersion>
if the meaning of "COLOR_ENCODING" = 42 changes between planes, that's painful
<emersion>
maybe it would be nice to have KMS device props
<emersion>
could supersede the caps
<emersion>
i guess one could expose a cap which references a blob ID...
<emersion>
( it would not supersede client caps ofc)
<daniels>
yeah, having a per-device blob definitely sounds more sensible than various per-plane blobs tbh
rtjure has quit [Ping timeout: 480 seconds]
cool110 has quit [Quit: ZNC 1.8.2+deb2build6 - https://znc.in]
cool110 has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
<emersion>
jadahl: do you want me to clarify something in w-p!190?
naveenk2 has quit [Ping timeout: 480 seconds]
<pq>
emersion, I'd probably try to pass some 3D LUT description to libliftoff, and then libliftoff can figure out if, how and where it can realize that or not. Yes, it's very complicated, but if libliftoff's point is that it automatically figures out the best way to map to KMS if possible, then I can't imagine how else it would do that.
<pq>
different KMS planes and CRTCs might have different pieces of the KMS color pipeline, and those piece have different flavors like support 1D and 3D LUT sizes and modes.
<pq>
*supported
<pq>
for example, 1D LUTs (previously known as GAMMA and DEGAMMA) will likely grow non-linear tap positioning modes
<pq>
they may also grow enumerated modes, where you can say "this LUT performs PQ EOTF" without actually loading a blob of data.
fmuellner has joined #wayland
<pq>
an API resembling something like that is what I have been growing in Weston between the color manager plugin and GL-renderer, while keeping in mind I also want to match it to KMS one day.
<pq>
It's not complete yet, it's pretty bare-bones for now.
<pq>
Most importantly it is missing all enumerated operations, like standard transfer functions.
<pq>
Once it gets e.g. enumerated transfer functions, it also needs lowering implementations, so that a named TF can be converted into a 1D LUT for example, if KMS or GL-renderer does not directly implement the named TF.
fmuellner has quit [Ping timeout: 480 seconds]
adia4 has quit []
adia4 has joined #wayland
kts has quit [Quit: Leaving]
kts has joined #wayland
kts has quit [Remote host closed the connection]
tent405 has quit [Read error: No route to host]
tent405 has joined #wayland
<jadahl>
emersion: "might provide" is just not the case for 'logical_size'. can't remember why logical_position got introduced when there is a x/y in geometry though
<jadahl>
perhaps it was to make sending geometry optional..
fmuellner has joined #wayland
molinari has quit [Ping timeout: 480 seconds]
[m]peeweep[m] has joined #wayland
<emersion>
jadahl: wlroots sends always 0,0 for the wl_output position, to prevent clients from, trying to do heuristics with them
<emersion>
jadahl: hm so do you want me to change the text or?
<jadahl>
does wlroots send 0,0 as logical_position too?
<emersion>
no
<jadahl>
due to xwayland needing them?
<emersion>
the rationale is:
<emersion>
if a client really needs accurate output layout description, they need xdg-output
<emersion>
if a client doesn't need that, then don't use the protocol, and core doesn't provide any info
<jadahl>
fair enough
<ifreund>
is there any client that does need accurate output layout description that we intend to use this protocol other than Xwayland?
<emersion>
… grim does…
<emersion>
but yeah i've considered hiding this protocol from other clients
<emersion>
in 50 years when security-context lands maybe
<qyliss>
thanks a lot for your persistence with security-context…
<emersion>
<3
<jadahl>
ifreund: the use case I've thought of is e.g. for a game to select where to be fullscreen or something, in order to illustrate the monitor setup
<ifreund>
jadahl: It seems to me more user-friendly to just let the user choose where the game should be fullscreen, using the same window manager specific controls they use for everything else
<jadahl>
perhaps
<emersion>
there isn't a very good way to mvoe a toplevel between outputs anyways
<ifreund>
yeah, it's totally up to the compositor/window manager how to do that, exactly as it should be IMO
<jadahl>
emersion: *click* -> *drag*
<emersion>
sure, but then the WM moves the toplevel, not the client itself
<jadahl>
I think that is what ifreund meant as better
<davidre>
emersion in jadahl's game case it would be just xdg_toplevel:set_fullscreen(other_output)
<emersion>
hm
<ifreund>
which I've never really understood the point of
<emersion>
i would've assumed that to be a no-op if the app is already fullscreen
<emersion>
but yeah, you're correct
<ifreund>
anyone have an example of when the compositor honoring client requested fullscreen outputs would be better UX? I just ignore them...
<jadahl>
emersion: one point was to some how let e.g. libreoffice fullscreen a presentation on the "presentation output"
<jadahl>
in the X11 era there was ideas to mark outputs as "presentation outputs" for such things
<jadahl>
using atoms, ofcourse
<emersion>
i see
jmdaemon has joined #wayland
<jadahl>
but there is no way to tag things that way, and I guess it didn't really gather enough interest because I haven't seen it being asked for
<davidre>
I remember a conference where the presentation kept on fullscreening to the laptop screen
<jadahl>
see!
<jadahl>
:P
<ifreund>
that's what you get when something tries to make the decision for the user and fails
<ifreund>
in my case my presenter client opens 2 windows, one for the presentation and one for speaker notes. I move the first to the presentation output and fullscreen it there, done
<davidre>
ifreund: that's strictly worse then me clicking a button "start presentation" and the other window opens and is fullscreen on the "correct" output
<davidre>
as in more steps for the user
<ifreund>
but how is the thing supposed to know what output is "correct"
<davidre>
Because the app has a setting on which output to present to
<davidre>
as d_ed mentioned
<ifreund>
I can't see any messages from d_ed, I'd guess they're not identified with services
<ifreund>
oftc really should support SASL...
<davidre>
It also has an "exchange" function to quickly switch notes and presentation screen
<davidre>
So you don't need to go to settings if it's the wrong way around
<davidre>
d_ed: You are still not authed
hardening has quit [Ping timeout: 480 seconds]
naveenk2 has joined #wayland
d_ed[m] has quit []
d_ed[m] has joined #wayland
naveenk2 has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Ping timeout: 480 seconds]
agd5f_ has joined #wayland
<vsyrjala>
what it the user wants presentations to span multiple outputs (some tiled display setup etc)?
<vsyrjala>
wouldn't it be better if the client can just tag the thing as "this is a presentation" and the compositor then knows what to do with it based on user configuration
<emersion>
yes
agd5f has quit [Ping timeout: 480 seconds]
Leopold_ has joined #wayland
molinari has joined #wayland
<zzag>
speaking of tiled outputs, how do they need to be exposed protocol-wise? wl_output would represent physical monitors, but there's nothing to represent the "logical output" i.e. an output representing united physical outputs afaict
<zzag>
one such usecase is creating desktop windows that span all the physical outputs
Leopold__ has joined #wayland
<jadahl>
zzag: you mean "tiled" as in multi-panel single monitors, or the user logically "gluing" physical monitors as if they were one?
<zzag>
"you mean "tiled" as in multi-panel single monitors" these ones
MajorBiscuit has quit [Ping timeout: 480 seconds]
<jadahl>
in mutter these are exposed as single wl_output's
Leopold_ has quit [Ping timeout: 480 seconds]
Coelacanthus[m] has joined #wayland
agd5f_ has quit []
agd5f has joined #wayland
marler8997 has quit [Remote host closed the connection]
sozuba has quit [Ping timeout: 480 seconds]
mooff has joined #wayland
julio7359 has quit [Ping timeout: 480 seconds]
mooff has quit [Remote host closed the connection]
mooff has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
junaid has joined #wayland
_DOOM_ 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
jmdaemon has joined #wayland
_DOOM_ has left #wayland [#wayland]
Brainium has joined #wayland
_DOOM_ has joined #wayland
Leopold__ has quit [Ping timeout: 480 seconds]
<_DOOM_>
I apologize if this is a stupid question. Is is possible for a compositor to create a client? Like, can a compositor create graphics and if the user clicks on these graphics can we then change and manage state?
molinari has quit [Ping timeout: 480 seconds]
<jadahl>
_DOOM_: yes, a compositor can spawn a client, e.g. by launching a new executable that connects either to the default socket, or e.g. a custom file descriptor. most compositors do this, with the most common client that creates this graphics that can be clicked on being Xwayland
Leopold_ has joined #wayland
<_DOOM_>
jadahl: I'm new to wayland and c programming how would the client talk back to the compositor about changing state?
Szadek has quit [Quit: WeeChat 3.8]
smallville7123 has quit [Read error: Connection reset by peer]
Szadek has joined #wayland
ppascher has joined #wayland
<jadahl>
_DOOM_: one example is the weston desktop shell; the compositor launches a client and exposes a wayland client specific to the client that draws the panel. other examples include using standardized protocols doing the same. if it's just about changing arbitrary state and not about graphics that should end up on the screen, any IPC will work