05:34 manuels: Is portals spec bound to flatpak? Or can i consider it to be a desktop standard (like eg basedirs and icon lookup)
08:07 MrCooper: manuels: the latter
08:08 MrCooper: portals are also window system agnostic, they can work the same in a Wayland or X session
09:56 pq: manuels, Wayland does not support global hotkeys, because no-one has pushed a protocol extension for that strong enough. For a draft, see https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/56 - I don't know if or how portals have solved this.
09:56 pq: perhaps the success of portals is the reason why a Wayland extension didn't get attention
10:02 emersion: some people were interested iirc
10:02 emersion: but ended up just doing their own custom proto in the end
10:04 pq: oh well
10:05 emersion: one downside of w-p is that ext requires acks from two members
10:05 emersion: and wlroots is just a single member
10:05 emersion: so if two wlroots compositors are interested in a protocol, we still cannot land it
10:05 emersion: also people are just scared about w-p in general
10:06 emersion: (i am too)
10:07 pq: because I might end up reviewing something, and I'm just insane in that?
10:09 emersion: lol
10:09 emersion: no, it's just that it's well-known for its MRs stuck forever
10:10 emersion: i am considering re-opening wlr-protocols, sadly
10:11 pq: I thought that has been running forward all the time
10:12 emersion: it's been frozen once w-p governance has been merged
10:13 pq: I hadn't realized that.
10:14 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.
10:15 emersion: our stance has been to push for ext- protocols, but that hasn't really worked out
10:15 pq: With wayland-protocols I'm always on my toes about someone taking an unmerged extension and releasing an implementation of it.
10:16 ifreund: it's already happening with hyprland, waybar and ext-workspaces apparently
10:16 emersion: yeah :/
10:16 emersion: there's also the famous virtual-keyboard and input-method fiasco
10:18 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 :'(
10:18 emersion: i am not sure how to parse that sentence
10:19 emersion: ah, so: if you were famous enough, you'd have an excuse for the proto not being merged?
10:20 emersion: too many negatives, sorry :o
10:20 SardemFF7: yeah, because just having my name on it would be a hard veto from wlroots :-P
10:21 emersion: eh
10:21 emersion: not really
10:21 emersion: i like your proposal
10:21 emersion: my concerns with your previous protocols were only about the protocols themselves
10:22 emersion: not the person behind them
10:26 qyliss: emersion: does anything else need to happen for to get past "Needs implementations" for https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/68?
10:27 qyliss: (I understand it still needs acks, but there should be enough implementations now, right?)
10:27 emersion: qyliss: ah, is there a way you can update your impl for the latest protocol version?
10:28 SardemFF7: emersion: technically, since I wrote them, I may still be the problem :-D
10:30 qyliss: emersion: I can put it on my list
10:30 emersion: cool!
10:30 qyliss: realistically it might be a month or two before i can get to it
10:30 emersion: ack
10:30 qyliss: cc puck_
10:37 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
10:37 emersion: jadahl: the ACKs need to be wlroots plus… someone else
10:38 emersion: the impls aren't the issue
10:38 emersion: but yeah, it seems like there's always someone (sometimes me) coming in with new comments…
10:39 jadahl: maybe one app ack shouldn't need to be a "member" then?
10:39 emersion: so, for ext, an ack from a third-party would be okay? sounds sensible
10:40 jadahl: sounds sensible
10:44 qyliss: Is there any reason to not just for for ext, when trying to standardise a protocol?
10:44 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?
10:45 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
10:46 pq: also more wide range of compositors
10:46 jadahl: and for wp_, not only application, but e.g. OpenGL/Vulkan drivers too
10:49 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
10:49 ifreund: I also see this as the main problem
10:50 ifreund: allowing a non-member implementor to ACK ext protocols seems reasonable to me though
10:55 qyliss: but like, if I'm proposing a protocol, why do I care about getting into wp_?
10:55 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
10:57 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_"?
10:57 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
10:58 qyliss: got it
10:58 qyliss: that makes more sense
10:58 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
10:59 zzag: there are cases, such as layer-shell, that do make sense to be upstream
11:00 emersion: do you have examples of differences?
11:00 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
11:01 jadahl: also because its stupidly tiny
11:01 zzag: emersion: well, one example is the output order thing
11:02 emersion: output order?
11:02 zzag: plasma sorts outputs as primary, secondary, tertiary, etc
11:02 emersion: ah, yes
11:05 jadahl: for things like input_method it's a different story
11:07 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 :/
11:08 emersion: yeah…
11:14 ifreund: yeah, it's a pretty big mess
11:16 daniels: yeah, widening acks sounds good to me
11:18 emersion: jadahl: can i get an ack for this? https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/189
11:18 daniels: input-method is really sad, especially given that cros has its own input-method fork ...
11:18 emersion: jadahl: ideally also this https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/190
11:18 wlb: wayland-protocols Merge request !186 merged \o/ (ext-session-lock-v1: clarify to fix race https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/186)
11:19 wlb: wayland-protocols/main: Isaac Freund * ext-session-lock-v1: use RFC 2119 key words https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/5dc6efded0cf staging/ext-session-lock/ext-session-lock-v1.xml
11:19 wlb: wayland-protocols/main: Isaac Freund * ext-session-lock-v1: clarify to fix race https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/2e1e07e34c1f staging/ext-session-lock/ext-session-lock-v1.xml
11:26 wlb: wayland-protocols Merge request !191 opened by Isaac Freund (ifreund) ext-session-lock-v1: relicense to MIT https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/191
11:33 wlb: wayland-protocols Merge request !192 opened by Simon Ser (emersion) governance: relax ACK requirements for the ext namespace https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/192 [In 30 day discussion period], [Needs acks]
11:35 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.
11:35 emersion: is the blob attached to planes?
11:36 pq: The blob is read-only, the enum is a CRTC or plane property that userspace writes.
11:36 emersion: so each plane has a blob and an enum?
11:36 emersion: or is the blob a more global thing?
11:36 pq: so the blob only explains what the enum values mean
11:36 emersion: ouch
11:36 emersion: that sounds painful
11:37 pq: the blob is just a much more flexible and bigger data structure than the value name string
11:37 pq: otherwise the usage is roughly the same
11:37 emersion: it would be less painful if the blob was per-device
11:38 emersion: or even per-CRTC
11:38 emersion: rather than per-plane
11:38 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.
11:39 emersion: oh
11:39 emersion: so one blob per enum entry?
11:39 emersion: that doesn't sound bad
11:39 emersion: if it was an index/offset to a per-plane blob it'd be more annoying
11:39 pq: yeah, but who's to say the blobs are per-enum-value, per-device or something else
11:40 pq: you just get a blob id, and the same id could appear elsewhere too
11:40 emersion: i'm just describing the level of annoyance for my user-space projects
11:40 pq: sure
11:40 emersion: okay, if it's a blob ID it's perfectly fine
11:41 emersion: the thing i'd struggle with is… a uint64 prop value which changes its meaning depending on the plane
11:41 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.
11:43 pq: blob ids are not global, are they? They are local to the device (driver instance), right?
11:43 emersion: yes
11:43 emersion: per-plane scope vs. per-device scope
11:43 emersion: former makes me unhappy, latter makes me happy :P
11:43 pq: so they are not hardcodable like the old uAPI enums
11:44 emersion: yea
11:44 pq: and not even transferrable from device to another on the same run
11:45 emersion: right, and you need to introspect the prop to be able to tell what the choices are even
11:45 emersion: but if that complexity is justified, that's completely fine
11:45 pq: yes, well, that you need to do always. I don't think any enum prop guarantees that all defined values are always possible.
11:45 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
11:46 wlb: wayland-protocols Merge request !191 merged \o/ (ext-session-lock-v1: relicense to MIT https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/191)
11:46 wlb: wayland-protocols/main: Isaac Freund * ext-session-lock-v1: relicense to MIT https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/a9fbc224cc3a staging/ext-session-lock/ext-session-lock-v1.xml
11:46 emersion: well, the kernel will EINVAL you anyways if the enum entry is not available
11:46 pq: right, but that's annoying to handle, isn't it?
11:47 emersion: no, libliftoff just tries something else
11:47 emersion: the kernel will EINVAL you for any other hw-specific reason as well
11:48 pq: if you're happy brute-forcing things that would have been known before-hand...
11:48 emersion: libliftoff can check that the enum is advertised, that's a detail
11:49 emersion: the core of the issue is that libliftoff exposes "layers", virtual planes where the lib user sets arbitrary KMS props
11:49 emersion: so for instance the user creates a layer with "COLOR_ENCODING" set to 42
11:50 emersion: and then libliftoff does its own magic to pick a plane for this layer
11:50 emersion: if the meaning of "COLOR_ENCODING" = 42 changes between planes, that's painful
11:52 emersion: maybe it would be nice to have KMS device props
11:52 emersion: could supersede the caps
11:52 emersion: i guess one could expose a cap which references a blob ID...
11:53 emersion: ( it would not supersede client caps ofc)
11:54 daniels: yeah, having a per-device blob definitely sounds more sensible than various per-plane blobs tbh
12:29 emersion: jadahl: do you want me to clarify something in w-p!190?
12:52 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.
12:53 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.
12:53 pq: *supported
12:54 pq: for example, 1D LUTs (previously known as GAMMA and DEGAMMA) will likely grow non-linear tap positioning modes
12:55 pq: they may also grow enumerated modes, where you can say "this LUT performs PQ EOTF" without actually loading a blob of data.
12:57 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.
12:59 pq: That's https://gitlab.freedesktop.org/wayland/weston/-/blob/main/libweston/color.h#L186-216 .
13:00 pq: It's not complete yet, it's pretty bare-bones for now.
13:01 pq: Most importantly it is missing all enumerated operations, like standard transfer functions.
13:03 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.
14:20 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
14:21 jadahl: perhaps it was to make sending geometry optional..
15:17 emersion: jadahl: wlroots sends always 0,0 for the wl_output position, to prevent clients from, trying to do heuristics with them
15:18 emersion: jadahl: hm so do you want me to change the text or?
15:18 jadahl: does wlroots send 0,0 as logical_position too?
15:18 emersion: no
15:18 jadahl: due to xwayland needing them?
15:19 emersion: the rationale is:
15:19 emersion: if a client really needs accurate output layout description, they need xdg-output
15:19 emersion: if a client doesn't need that, then don't use the protocol, and core doesn't provide any info
15:20 jadahl: fair enough
15:20 ifreund: is there any client that does need accurate output layout description that we intend to use this protocol other than Xwayland?
15:20 emersion: … grim does…
15:21 emersion: but yeah i've considered hiding this protocol from other clients
15:21 emersion: in 50 years when security-context lands maybe
15:22 qyliss: thanks a lot for your persistence with security-context…
15:22 emersion: <3
15:28 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
15:29 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
15:31 jadahl: perhaps
15:31 emersion: there isn't a very good way to mvoe a toplevel between outputs anyways
15:33 ifreund: yeah, it's totally up to the compositor/window manager how to do that, exactly as it should be IMO
15:33 jadahl: emersion: *click* -> *drag*
15:34 emersion: sure, but then the WM moves the toplevel, not the client itself
15:34 jadahl: I think that is what ifreund meant as better
15:35 davidre: emersion in jadahl's game case it would be just xdg_toplevel:set_fullscreen(other_output)
15:35 emersion: hm
15:35 ifreund: which I've never really understood the point of
15:35 emersion: i would've assumed that to be a no-op if the app is already fullscreen
15:35 emersion: but yeah, you're correct
15:35 ifreund: anyone have an example of when the compositor honoring client requested fullscreen outputs would be better UX? I just ignore them...
15:35 jadahl: emersion: one point was to some how let e.g. libreoffice fullscreen a presentation on the "presentation output"
15:36 jadahl: in the X11 era there was ideas to mark outputs as "presentation outputs" for such things
15:36 jadahl: using atoms, ofcourse
15:36 emersion: i see
15:37 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
15:37 davidre: I remember a conference where the presentation kept on fullscreening to the laptop screen
15:37 jadahl: see!
15:37 jadahl: :P
15:37 ifreund: that's what you get when something tries to make the decision for the user and fails
15:38 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
15:39 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
15:39 davidre: as in more steps for the user
15:40 ifreund: but how is the thing supposed to know what output is "correct"
15:40 davidre: Because the app has a setting on which output to present to
15:40 davidre: as d_ed mentioned
15:41 ifreund: I can't see any messages from d_ed, I'd guess they're not identified with services
15:42 ifreund: oftc really should support SASL...
15:43 davidre: It also has an "exchange" function to quickly switch notes and presentation screen
15:44 davidre: So you don't need to go to settings if it's the wrong way around
15:45 davidre: d_ed: You are still not authed
16:41 vsyrjala: what it the user wants presentations to span multiple outputs (some tiled display setup etc)?
16:42 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
16:43 emersion: yes
16:58 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
16:59 zzag: one such usecase is creating desktop windows that span all the physical outputs
17:02 jadahl: zzag: you mean "tiled" as in multi-panel single monitors, or the user logically "gluing" physical monitors as if they were one?
17:02 zzag: "you mean "tiled" as in multi-panel single monitors" these ones
17:02 jadahl: in mutter these are exposed as single wl_output's
18:41 _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?
18:46 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
19:01 _DOOM_: jadahl: I'm new to wayland and c programming how would the client talk back to the compositor about changing state?
19:19 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