ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Guest4591 has quit [Remote host closed the connection]
shider has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
Psi-Jack has quit [Quit: Do you type on your PS1 or play on your PS1?]
Psi-Jack has joined #wayland
feaneron has quit [Ping timeout: 480 seconds]
kts has joined #wayland
kts has quit [Quit: Leaving]
leon-anavi has joined #wayland
rv1sr has joined #wayland
tzimmermann has joined #wayland
glennk has joined #wayland
sima has joined #wayland
rasterman has joined #wayland
<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?
<colinmarc>
(I do check the version, but that seems like a backwards incompatible change to me, if I have to check the version)
<soreau>
AFAIK, if everything works out, you shouldn't have to check the version in the client
<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)
<soreau>
and the compositor has to do any special casing to support <= max_supported_version
<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
<soreau>
that's what I mean by special casing
<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
<d_ed[m]>
It clearly doesn't match the definition you have in your head
<colinmarc>
yeah, maybe I should start with that :)
<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
<d_ed[m]>
The phrase I would maybe use is "binary compatiable" rather than backwards compatiable
<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
<colinmarc>
and might be worth defining somewhere
glennk has quit [Read error: Connection reset by peer]
<daniels>
colinmarc: yeah, so a key invariant of any protocol is: don't send clients things they don't know about
<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
<emersion>
^
<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?
<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
___nick___ has joined #wayland
<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
<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
<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%)
coldfeet has joined #wayland
<colinmarc>
I just found this in the wayland book:
<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.
<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
yshui_ has quit [Read error: Connection reset by peer]
yshui has joined #wayland
mripard has joined #wayland
kts has quit [Quit: Leaving]
katatonic1911 has joined #wayland
coldfeet has quit [Quit: leaving]
<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.
<katatonic1911>
Which C function in Wayland API should provide manipulations like this?
<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.
<soreau>
katatonic1911: you probably want to modify the code in the compositor to do this
<soreau>
libwayland is more about facilitating the communication on the socket between client and compositor, but the compositor drives the output(s)
<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.
<soreau>
you'd have to probably look at some fd and somehow guess the format.. do other stuff and pass it along? not sure
Moprius has joined #wayland
<katatonic1911>
What the "fd" stands for actually?
<katatonic1911>
I saw few usages about it, but still I'm not sure.
<soreau>
file descriptor
nerdopolis has joined #wayland
<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
<soreau>
and depending on what client type it is, you'd have to handle it differently
Moprius has quit [Remote host closed the connection]
mclasen has joined #wayland
<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.
<pq>
katatonic1911, libwayland does not concern itself with pixels or screen driving at all.
<pq>
Wayland is really just messages being passed between a compositor and a client.
<katatonic1911>
soreau, I will check it out, thanks.
<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.
<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
<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.
<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
<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
<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
<kennylevinsen>
> Setting an opaque region is not required for correct behaviour, but marking transparent content as opaque will result in repaint artifacts.
<DemiMarie>
kennylevinsen: I'm writing a proxy and want to ensure that toplevels become opaque.
<DemiMarie>
Qubes OS intentionally does not support transparent toplevels.
<daniels>
so translate the format from ARGB from XRGB if required
<kennylevinsen>
mclasen: I would interpret it as being a client bug to set opaque region on transparent content at least
<kennylevinsen>
but opaque region is a bit of an oddball thing :/
<DemiMarie>
daniels: translating the format breaks transparent subsurfaces
<kennylevinsen>
DemiMarie: paint a black rect under the toplevel?
<DemiMarie>
kennylevinsen: does that get the luma wrong?
<kennylevinsen>
but converting the toplevel buffer and cutting off subsurfaces extending past the toplevel would do the same thing
<kennylevinsen>
you don't need to convert the subsurface buffers to XRGB - only the toplevel
<kennylevinsen>
DemiMarie: Neither a black rect nor XRGB will get the luma wrong
<DemiMarie>
kennylevinsen: Do I need to undo premultiplied alpha?
<kennylevinsen>
nope, it's premultiplied exactly so that interpreting as XRGB still yields the right color :)
<kennylevinsen>
and for blending, putting a black rect behind the toplevel is just the same as having a black background image on your desktop
* mclasen
not expecting a compositor without transparency to work very well
<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...
<kennylevinsen>
there's definitely some layer shell tools that would be terrible without transparency
<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
Guest4620 has quit [Remote host closed the connection]
paulk has joined #wayland
kts has joined #wayland
tzimmermann has quit [Quit: Leaving]
<mclasen>
wayland compositors have had transparency support for 15 years, a bit late now to introduce lesser visuals and expect clients to handle them...
leon-anavi has quit [Quit: Leaving]
<JoshuaAshton>
a compositor can just do whatever it wants with the alpha channel...
<JoshuaAshton>
no need to filter anything out
<daniels>
it's also free to swap the red and blue channels, but we traditionally try to avoid that
Company has quit [Quit: Leaving]
Company has joined #wayland
<kennylevinsen>
That would not be a great accessibility feature
<any1>
kennylevinsen: Or maybe it would? People with red-green colour blindness might find it useful to be able to swap them momentarily.
<colinmarc>
I think @demi:invisiblethingslab.com 's thing is not the compositor, it's a proxy
kts has quit [Quit: Leaving]
mclasen is now known as mclasen_afk
iomari891 has quit [Ping timeout: 480 seconds]
<kennylevinsen>
any1: depends, a dichromat would probably just see it as a change in luminosity/saturation
___nick___ has quit [Ping timeout: 480 seconds]
<kennylevinsen>
But maybe for others
plutunion has quit [Remote host closed the connection]
abhimanyu has quit [Read error: No route to host]
abhimanyu has joined #wayland
latex_ has joined #wayland
___nick___ has joined #wayland
iomari891 has joined #wayland
mripard has quit [Remote host closed the connection]
mclasen_afk is now known as mclasen
<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.
<karolherbst>
but would be an interesting idea to have it widely available
<emersion>
maybe ICC profiles
<kennylevinsen>
yeah, that would be a nicely portable approach
<karolherbst>
maybe. I know that there are hardware solutions, maybe it makes sense to ask an expert in that field for input on that
<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
<mclasen>
it doesn't have much to do with icc profiles at all
<mclasen>
simulating vision deficiencies can be done in the compositor using shaders
<mclasen>
you don't need a protocol or icc profile for that
<emersion>
but that's not portable
<mclasen>
right. and ?
<emersion>
many compositors already support ICC profiles, it's standard
<kennylevinsen>
ICC profiles are just a platform independent, industry standard way to describe the transform
<kennylevinsen>
... often implemented in compositors using shaders already
<emersion>
if we have an ICC profile to simulate deficiencies, compositors don't have to implement anything
<kennylevinsen>
and you'd be able to test on windows and mac with it too
<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
<karolherbst>
no point in discussing specifics if people have no real knowledge in that field
<karolherbst>
or maybe somebody here has
<karolherbst>
would be good to know :)
<mclasen>
as far as I know, only weston currently supports the icc part of the color management protocol
<mclasen>
there's just no need to tie these two things together
<emersion>
kwin and wlroots support ICC profiles
<emersion>
probably more
<emersion>
not in the protocol, as a user setting
<soreau>
wlroots with vulkan only?
<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. :)
<emersion>
yes
<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
<emersion>
anyways, feel free to implement in a shader or w/e -- i'd rather not in my compositor
<karolherbst>
I don't know enough, just something I was thinking about recently
<kennylevinsen>
mclasen: to be clear, I was suggestion a monitor calibration ICC profile that intentionally applied a dichromacy effect
<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
<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
<jadahl>
*can't also..
<DemiMarie>
mclasen: In what ways do clients depend on transparency support for toplevels and popups (not subsurfaces)?
<jadahl>
i.e. doesn't need more w-p protocol than the icc part of color management
<kennylevinsen>
DemiMarie: rounded corners for one
<DemiMarie>
Shadows can be clipped.
<emersion>
for popups, quite heavily for rounded corners and shadows
<mclasen>
rounded corners and shadows, pointy arrows on popovers
* soreau
wonders if there's a wlroots function for compositors to pass in icc profile and get back a lut
<emersion>
soreau: not everything can be translated to a LUT. but you can use littlecms
<DemiMarie>
emersion: does that mean that even tiling compositors have to deal with transparency?
<emersion>
yes
<DemiMarie>
Darn
<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
<DemiMarie>
And popups don't have a geometry that can be conveniently used for clipping.
<jadahl>
mclasen: a shadowless themes doesn't help arrow-popovers
<mclasen>
no, but that is under theme control as well
<mclasen>
just as rounded corners
<jadahl>
oh, til
<DemiMarie>
Ugh, I had no idea arrow popups existed.
<DemiMarie>
Will those generally be within the geometry of their parent toplevel?
<jadahl>
the arrow will, but not the popup and its shadow
<jadahl>
the arrow tends to point to a widget in the parent
<jadahl>
but the arrow might point to a widget sitting in a popup that is outside of the toplevel
<soreau>
if you don't want transparency, maybe just render/clear the fb behind it based on input region
<soreau>
:P
<DemiMarie>
mclasen: Can there be some way for tiling compositors to say, "please don't waste power on shadows, they will just be clipped"?
<DemiMarie>
emersion: does Sway clip shadows on toplevels?
<jadahl>
DemiMarie: there is a tiling state in xdg-shell that tells clients to not draw shadow. doesn't apply to popovers though
<mclasen>
yeah, window state should do the trick
<emersion>
we do clip iirc, but yeah doesn't make a difference in general
<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?
<DemiMarie>
mclasen: how bad would it be for a stacking compositor to pretend it is a tiling one?
<kennylevinsen>
popups could be constrained to toplevel geometry, but the UX might be a bit weird
<kennylevinsen>
according to the positioner constraints of course
<DemiMarie>
kennylevinsen: weird in what way?
<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
* DemiMarie
wonders if Qubes OS's UX needs to be changed to rely on something other than colored borders
<mclasen>
DemiMarie: you can play all sorts of games, but it doesn't sound like a promising direction to pursue
<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
<kennylevinsen>
DemiMarie: supporting floating popups with transparency would probably be good for UX in general
<jadahl>
kennylevinsen: indeed, ideally clients asks to be constrained
<jadahl>
but they can also ask not to
<jadahl>
for better or worse
<DemiMarie>
kennylevinsen: the problem is providing an unspoofable indication of trust for these popups
<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
<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
<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
iomari891 has quit [Ping timeout: 480 seconds]
plutoniun has joined #wayland
<mclasen>
kennylevinsen: newly proposed protocols will make it possible