01:33 wlb: wayland Merge request !430 opened by () debug: print time mod 1000 seconds, not mod 2^32 µs https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/430
07:54 colinmarc: I realized (after commenting unfortunately) that I don't 100% understand backwards compatibility as defined by wayland. when xdg_shell added `suspended` as a state, that's considered backwards compatible, even though sending `suspended` crashes a client with an older version? because you can check the version?
07:55 colinmarc: (I do check the version, but that seems like a backwards incompatible change to me, if I have to check the version)
08:04 soreau: AFAIK, if everything works out, you shouldn't have to check the version in the client
08:07 soreau: in the compositor, you probably want to do something like std::min(wl_resource_get_version(shell_resource), max_supported_version) and the client does std::min(version, max_supported_version)
08:07 soreau: and the compositor has to do any special casing to support <= max_supported_version
08:08 d_ed[m]: you still have to guard sending stuff that isn't supported if your client/server supports something newer than the other end
08:08 soreau: that's what I mean by special casing
08:10 colinmarc: yeah, I'm not talking about how it works in practice, I'm talking about the definition of the term. It's defined (without a written definition anywhere that I can find?) in a way contrary to how most of the engineering world thinks of backwards compatibility
08:10 d_ed[m]: It clearly doesn't match the definition you have in your head
08:10 colinmarc: yeah, maybe I should start with that :)
08:11 d_ed[m]: but the important part if you don't have to re-implement set_title twice, like you did for XdgShellV5 vs XdgShellV6
08:11 d_ed[m]: The phrase I would maybe use is "binary compatiable" rather than backwards compatiable
08:15 colinmarc: Okay, I guess if makes more sense if you think about it as ABI compatibility. I think that tripped me up because it's a wire protocol
08:15 colinmarc: and might be worth defining somewhere
08:26 daniels: colinmarc: yeah, so a key invariant of any protocol is: don't send clients things they don't know about
08:27 daniels: a server sending a v2 client an event that only exists in v3 is completely erroneous, because the client may not even know how to decode that event
08:27 emersion: ^
08:28 daniels: even if that were changed to have self-describing protocol so the client could decode and discard, the client would still need to know what actions to take, e.g. would it be receiving a fd it has to close, or an object it's expected to destroy, or?
08:29 daniels: it would be nice if the interface carried the 'since' version so we could throw an error in libwayland-server when it tried to send such an event, but it doesn't and it's not ABI we can extend, so the fix is just to read the protocol carefully when you implement it, and not do it
08:38 colinmarc: I'm not trying to be prescriptive, just saying that most people would consider that to be backwards incompatibility in the sense that you need to make changes to specifically support older versions of your peers speaking the protocol. In order to avoid confusion in the future, maybe it should defined somewhere what exactly backwards incompatability means for wayland
08:38 colinmarc: I come from a web infra background, so maybe I'm the outlier, but I'm used to protobuf/thrift/json/etc which have different semantics
08:40 colinmarc: If you tell me where to make the MR and where the documentation should go, I could try and draft something today (it would also help me understand it 100%)
08:45 colinmarc: I just found this in the wayland book:
08:45 colinmarc: > To make a backwards-compatible change, you may only add new events or requests to the end of an interface, or new members to the end of an enum. Additionally, each implementation must limit itself to using only the messages supported by the other end of the connection. We'll discuss in chapter 5 how we establish which versions of each interface are in use by each party.
08:45 colinmarc: So maybe that's enough actually
09:36 daniels: yeah, we've (taking the group of people involved in Wayland, who often have a winsys/GPU/kernel/toolkit background rather than web) always understood backwards compatible as exactly that: additive only, and don't send anyone with an older version anything from a newer version, because they don't know what to do with it, and just dropping it on the floor is a) often not the right response, and b) deeply confusing
10:19 wlb: weston Merge request !1618 opened by () libweston: Send seat name before announcing devices https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1618
11:32 katatonic1911: Hello, I'm currently exploring Wayland libraries in C, and I'm looking for manipulate rendered colors of each pixel provided by the compositor, let's say Sway for example.
11:33 katatonic1911: Which C function in Wayland API should provide manipulations like this?
11:34 pq: colinmarc, about clients automatically ignoring events they do not implement; this may cause a state mismatch that can be prevented if the compositor knows the client does not implement it. E.g. some extra state for a configure burst which the client then acks.
11:35 wlb: wayland Merge request !431 opened by () protocol: Clarify sending of wl_seat.capabilities https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/431
11:44 soreau: katatonic1911: you probably want to modify the code in the compositor to do this
11:46 soreau: libwayland is more about facilitating the communication on the socket between client and compositor, but the compositor drives the output(s)
11:50 katatonic1911: soreau, no, I should be able to do this independent from the compositor, so modifying the compositor code won't appropriate for this. I'm thinking this function like a screen filter. It should manipulate output colors.
11:50 soreau: you'd have to probably look at some fd and somehow guess the format.. do other stuff and pass it along? not sure
11:52 katatonic1911: What the "fd" stands for actually?
11:52 katatonic1911: I saw few usages about it, but still I'm not sure.
11:53 soreau: file descriptor
11:55 soreau: the way it usually works is, the fd is passed on the socket, and things keep getting passed around until the bits make it to the display; the pixel data is never sent on the wire
11:56 soreau: and depending on what client type it is, you'd have to handle it differently
12:00 pq: katatonic1911, Wayland interfaces do not let you do anything like that. You would have to invent a new protocol extension, and then get compositors to implement it before you could make use of it.
12:00 pq: katatonic1911, libwayland does not concern itself with pixels or screen driving at all.
12:01 pq: Wayland is really just messages being passed between a compositor and a client.
12:02 katatonic1911: soreau, I will check it out, thanks.
12:05 pq: Compositors do not send such fd over the socket until you modify a compositor to do it. There is no way around changing each compositor you want to work with.
12:05 katatonic1911: pq, I'm looking for something like how wlsunset tool does. It uses Wayland's gamma control. Works as a bluelight filter, and I'm wondering if someone can do other screen filter methods. https://github.com/kennylevinsen/wlsunset
12:06 pq: katatonic1911, looks like wlsunset uses the wlr-gamma-control-unstable-v1.xml protocol extension to tell the compositor to alter the pixels. It does not alter pixels itself.
12:06 LaserEyess: wlsunset works via https://wayland.app/protocols/wlr-gamma-control-unstable-v1 but it's very limited
12:06 katatonic1911: If nothing like that exists, so the only way is the modifying my compositor's code, which is Sway in my scenario.
12:08 LaserEyess: sway, by design, has no real support for shaders or filters, and they do not plan on adding any functionality for that
12:08 LaserEyess: also try #sway on libera for help there, or #sway-devel if you want to fork it and add that functionality
12:19 soreau: FWIW, wayfire has this functionality via filters plugin github.com/soreau/filters
12:20 soreau: it can apply a fullscreen shader for an output from a fragment shader file
12:22 soreau: (or use the same shader files for a specific surface)
13:25 wlb: weston/main: EatingSumo * libweston/screenshooter: Fix build when __builtin_clz is not available https://gitlab.freedesktop.org/wayland/weston/commit/312c8bea6607 libweston/screenshooter.c
13:25 wlb: weston Merge request !1615 merged \o/ (libweston/screenshooter: Fix build when __builtin_clz is not available https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1615)
13:37 wlb: weston/main: David Edmundson * libweston: Send seat name before announcing devices https://gitlab.freedesktop.org/wayland/weston/commit/fe64eee3aec2 libweston/input.c
13:37 wlb: weston Merge request !1618 merged \o/ (libweston: Send seat name before announcing devices https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1618)
14:34 DemiMarie: Is the opaque region purely an optimization hint? Are compositors allowed to ignore it?
14:35 ifreund: yes
14:36 DemiMarie: Darn it!
14:38 wlb: weston Issue #952 closed \o/ (Segfault while using layer-add-surfaces https://gitlab.freedesktop.org/wayland/weston/-/issues/952)
14:38 kennylevinsen: DemiMarie: what's your concern?
14:38 kennylevinsen: if the client specifies an opaque region, it tells you that the client guarantees that *it* won't do anything transparent in that region
14:39 kennylevinsen: which is useful if you need *some* transparency and therefore are using an alpha format - otherwise - XRGB formats imply no transparency for the entire surface
14:41 mclasen: kennylevinsen: I don't think the client guarantees anything. But setting an opaque region and then rendering translucent content there is just a silly thing to do
14:42 kennylevinsen: > Setting an opaque region is not required for correct behaviour, but marking transparent content as opaque will result in repaint artifacts.
14:42 DemiMarie: kennylevinsen: I'm writing a proxy and want to ensure that toplevels become opaque.
14:42 DemiMarie: Qubes OS intentionally does not support transparent toplevels.
14:43 daniels: so translate the format from ARGB from XRGB if required
14:43 kennylevinsen: mclasen: I would interpret it as being a client bug to set opaque region on transparent content at least
14:44 kennylevinsen: but opaque region is a bit of an oddball thing :/
14:44 DemiMarie: daniels: translating the format breaks transparent subsurfaces
14:44 kennylevinsen: DemiMarie: paint a black rect under the toplevel?
14:45 DemiMarie: kennylevinsen: does that get the luma wrong?
14:45 kennylevinsen: but converting the toplevel buffer and cutting off subsurfaces extending past the toplevel would do the same thing
14:45 kennylevinsen: you don't need to convert the subsurface buffers to XRGB - only the toplevel
14:46 kennylevinsen: DemiMarie: Neither a black rect nor XRGB will get the luma wrong
14:46 DemiMarie: kennylevinsen: Do I need to undo premultiplied alpha?
14:47 kennylevinsen: nope, it's premultiplied exactly so that interpreting as XRGB still yields the right color :)
14:47 kennylevinsen: and for blending, putting a black rect behind the toplevel is just the same as having a black background image on your desktop
14:48 mclasen:not expecting a compositor without transparency to work very well
14:50 kennylevinsen: there's definitely going to be some things that don't work, but not blending to background wouldn't be the end of the world...
14:51 kennylevinsen: there's definitely some layer shell tools that would be terrible without transparency
14:52 kennylevinsen: DemiMarie: even if you don't mess with XRGB/ARGB/black rect, your host compositor can just render the toplevel buffer without blending - plenty of options
15:24 mclasen: wayland compositors have had transparency support for 15 years, a bit late now to introduce lesser visuals and expect clients to handle them...
15:51 JoshuaAshton: a compositor can just do whatever it wants with the alpha channel...
15:52 JoshuaAshton: no need to filter anything out
15:59 daniels: it's also free to swap the red and blue channels, but we traditionally try to avoid that
16:11 kennylevinsen: That would not be a great accessibility feature
16:15 wlb: wayland-protocols Merge request !340 opened by () Clarify what 'member' means, and how to add/remove them https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/340 [governance], [In 30 day discussion period]
16:16 any1: kennylevinsen: Or maybe it would? People with red-green colour blindness might find it useful to be able to swap them momentarily.
16:35 colinmarc: I think @demi:invisiblethingslab.com 's thing is not the compositor, it's a proxy
16:54 kennylevinsen: any1: depends, a dichromat would probably just see it as a change in luminosity/saturation
16:56 kennylevinsen: But maybe for others
18:08 karolherbst: on that topic I was actually wondering if at some point it makes sense to have a protocl/whatever for developers to change colors in a way to be able to simulate all sorts of color blindness. But that might be very well be a compositor/toolkit/whatever feature for those who really care.
18:09 karolherbst: but would be an interesting idea to have it widely available
18:09 emersion: maybe ICC profiles
18:10 kennylevinsen: yeah, that would be a nicely portable approach
18:10 emersion: hey https://www.color.org/resources/cvd.xalter
18:11 karolherbst: maybe. I know that there are hardware solutions, maybe it makes sense to ask an expert in that field for input on that
18:12 karolherbst: the thing is, ICC profiles might be good, but maybe there are better ideas, but anyway... some topic to think about to maybe lower the barriers for app developers to test those things
18:13 mclasen: it doesn't have much to do with icc profiles at all
18:13 wlb: wayland-protocols Merge request !341 opened by () governance: update NACK usage/restrictions https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/341 [governance], [In 30 day discussion period]
18:14 emersion: mclasen: wdym?
18:14 mclasen: simulating vision deficiencies can be done in the compositor using shaders
18:14 mclasen: you don't need a protocol or icc profile for that
18:14 emersion: but that's not portable
18:14 mclasen: right. and ?
18:15 emersion: many compositors already support ICC profiles, it's standard
18:15 kennylevinsen: ICC profiles are just a platform independent, industry standard way to describe the transform
18:15 kennylevinsen: ... often implemented in compositors using shaders already
18:15 emersion: if we have an ICC profile to simulate deficiencies, compositors don't have to implement anything
18:15 kennylevinsen: and you'd be able to test on windows and mac with it too
18:16 karolherbst: my point was more that we should ask an expert in that field, because they probably know better what's a suitable solution here and could talk about the pro/cons of each solution
18:16 karolherbst: no point in discussing specifics if people have no real knowledge in that field
18:17 karolherbst: or maybe somebody here has
18:17 karolherbst: would be good to know :)
18:17 mclasen: as far as I know, only weston currently supports the icc part of the color management protocol
18:18 mclasen: there's just no need to tie these two things together
18:18 emersion: kwin and wlroots support ICC profiles
18:18 emersion: probably more
18:18 emersion: not in the protocol, as a user setting
18:18 soreau: wlroots with vulkan only?
18:18 kennylevinsen: karolherbst: you only need color science simulation of color blindness - that's fairly well understood. Now, if you want to improve color discrimination for the color blind, or know more about the biology behind in, then yeah we'd need someone in the field. :)
18:18 emersion: yes
18:19 karolherbst: kennylevinsen: yeah.. so my thinking was maybe wayland/us/the community could help with making it easier for app developers know if their would run into any issues with certain forms of color blindness
18:19 emersion: anyways, feel free to implement in a shader or w/e -- i'd rather not in my compositor
18:19 karolherbst: I don't know enough, just something I was thinking about recently
18:20 kennylevinsen: mclasen: to be clear, I was suggestion a monitor calibration ICC profile that intentionally applied a dichromacy effect
18:22 mclasen: I have no problem at all if you find icc profiles that you can load into your compositor as a user setting to help improve a11y. Go for it
18:22 jadahl: mclasen: if one can get color deficiency functionality via a icc profile, it'd just be about supporting icc profiles. doesn't mean it can also be a built in compositor feature elsewhere
18:22 jadahl: *can't also..
18:23 DemiMarie: mclasen: In what ways do clients depend on transparency support for toplevels and popups (not subsurfaces)?
18:23 jadahl: i.e. doesn't need more w-p protocol than the icc part of color management
18:23 kennylevinsen: DemiMarie: rounded corners for one
18:23 DemiMarie: Shadows can be clipped.
18:23 emersion: for popups, quite heavily for rounded corners and shadows
18:23 mclasen: rounded corners and shadows, pointy arrows on popovers
18:23 soreau:wonders if there's a wlroots function for compositors to pass in icc profile and get back a lut
18:24 emersion: soreau: not everything can be translated to a LUT. but you can use littlecms
18:24 DemiMarie: emersion: does that mean that even tiling compositors have to deal with transparency?
18:24 emersion: yes
18:25 DemiMarie: Darn
18:25 mclasen: if people file issues about large black areas around popovers, we tell them to get a better compositor or use a theme without shadows
18:25 DemiMarie: And popups don't have a geometry that can be conveniently used for clipping.
18:25 jadahl: mclasen: a shadowless themes doesn't help arrow-popovers
18:25 mclasen: no, but that is under theme control as well
18:26 mclasen: just as rounded corners
18:26 jadahl: oh, til
18:26 DemiMarie: Ugh, I had no idea arrow popups existed.
18:26 DemiMarie: Will those generally be within the geometry of their parent toplevel?
18:26 jadahl: the arrow will, but not the popup and its shadow
18:26 jadahl: the arrow tends to point to a widget in the parent
18:27 jadahl: but the arrow might point to a widget sitting in a popup that is outside of the toplevel
18:27 soreau: if you don't want transparency, maybe just render/clear the fb behind it based on input region
18:27 soreau: :P
18:27 DemiMarie: mclasen: Can there be some way for tiling compositors to say, "please don't waste power on shadows, they will just be clipped"?
18:28 DemiMarie: emersion: does Sway clip shadows on toplevels?
18:28 jadahl: DemiMarie: there is a tiling state in xdg-shell that tells clients to not draw shadow. doesn't apply to popovers though
18:29 mclasen: yeah, window state should do the trick
18:29 emersion: we do clip iirc, but yeah doesn't make a difference in general
18:30 DemiMarie: soreau: Would anything break if I composited a popup within its parent onto its parent and just gave the host compositor a single surface?
18:30 DemiMarie: mclasen: how bad would it be for a stacking compositor to pretend it is a tiling one?
18:30 kennylevinsen: popups could be constrained to toplevel geometry, but the UX might be a bit weird
18:31 kennylevinsen: according to the positioner constraints of course
18:31 DemiMarie: kennylevinsen: weird in what way?
18:31 jadahl: kennylevinsen: it can only be constrained if the client asks for it. if it does, the proxy compositor can constrain to the parent toplevel
18:33 DemiMarie:wonders if Qubes OS's UX needs to be changed to rely on something other than colored borders
18:33 mclasen: DemiMarie: you can play all sorts of games, but it doesn't sound like a promising direction to pursue
18:33 kennylevinsen: jadahl: well, without constraints a popover could always end up being clipped from being near an output boundary, so clipping it at toplevel boundary wouldn't be illegal, just... really ugly
18:34 kennylevinsen: DemiMarie: supporting floating popups with transparency would probably be good for UX in general
18:34 jadahl: kennylevinsen: indeed, ideally clients asks to be constrained
18:34 jadahl: but they can also ask not to
18:34 jadahl: for better or worse
18:34 DemiMarie: kennylevinsen: the problem is providing an unspoofable indication of trust for these popups
18:35 DemiMarie: Right now, the X11 daemon uses X11 drawing routines to draw a border over the edge of the popup, which works surprisingly well in practice
18:41 kennylevinsen: well, xdg_popups are very explicit, tied to a parent surface with relative positioning, and dismissable by the compositor. That's quite a different risk to X11 popup windows
18:42 kennylevinsen: so I don't really see them as having much in way of risk in the wayland model - an unfocused window does not have a way of placing a popup near your cursor
18:53 mclasen: kennylevinsen: newly proposed protocols will make it possible
22:17 wlb: wayland Issue #500 opened by () a wl_display cannot be intergrated into another event loop using wl_event_loop_get_fd https://gitlab.freedesktop.org/wayland/wayland/-/issues/500
22:36 Ermine: 500th issue!
23:49 DemiMarie: mclasen: which ones so I know to not support them?