01:28 yura: hello
01:29 yura: Is there anyone alive?
07:47 ifreund: that was me that tried the the 1 px squares of different colors + viewporter hack
07:48 ifreund: it made some nice looking gradients but yeah, kinda made useless in practice due to the undefined and inconsistent filtering
07:53 pq: emersion, zamundaaa[m], FWIW, I wrote https://gitlab.freedesktop.org/wayland/weston/-/blob/main/clients/scaler.c?ref_type=heads to verify the viewporter behavior on splitting source pixels. It contains comments and help text explaining the expectations.
07:54 pq: but since filtering is implementation specific, it only applies to Weston
08:01 pq: One of the two intentions of wp_viewport is source cropping. Indeed, if the source rectangle was taken in the most strict sense of "no accessing pixels outside of it", it would cause glitches when the source rectangle smoothly slides over the buffer.
08:05 pq: I think there is also the question: is the top-left corner of a buffer at position 0,0 pixels or -0.5,-0.5 pixels? I.e., is the center of a pixel at x.0, y.0 or x.5, y.5? I don't remember the answer.
08:07 pq: given that src_x,src_y cannot be negative, I guess the pixele middle is at x.5, y.5.
09:09 mclasen:wonders how alpha multipliers interact with cursor shapes
09:10 pq: What's the question?
09:10 mclasen: cursor shape lets you specify surface content compositor-side
09:11 mclasen: alpha modifier lets you tell the compositor to tweak buffer contents
09:11 pq: ok, so you wonder if alpha multiplier should be ignored or applied. Or maybe an error?
09:11 mclasen: I just wondered because as usual alpha modifier spec pretends that you can apply this to an arbitrary wl_surface
09:11 pq: we certainly can
09:11 pq: should we, that's the question
09:12 mclasen: all these protocols interact in unknown ways and create dozens of cornercases. such fun
09:12 pq: at least we can look at those corner cases and decide the best resolution for the combination
09:14 mclasen: I was disappointed the other day that mutter doesn't let me use a viewporter on a cursor
09:15 mclasen: the protocol pretends that should be a-ok to do
09:15 pq: Thanks to protocol being more descriptive than prescriptive. Prescriptive parts tend to cause the most problems, it seems.
09:15 mclasen: if you want to be interoperable...
09:15 pq: it certainly is ok to do
09:15 pq: also sub-surfaces on cursor surfaces are ok
09:16 pq: or did that get amended, I forget
09:16 pq: you can also use a dmabuf, wl_shm buffer, or a single-pixel buffer on a cursor surface
09:16 pq: you will be able to set a color profile on a cursor
09:16 pq: etc.
09:16 mclasen: I can, but whether it works depends on how my compositor decided to apply common sense
09:17 pq: yes, that goes with all software
09:19 davidre: mclasen How would you apply alpha-multiplier to cursor-shape
09:19 emersion: cursor-shape has no surface
09:19 davidre: You do not have a surface handle with cursor-shape
09:20 pq: ooh, that's good
09:20 davidre: the viewpointer issue, sounds like a mutter issue if it's actually allowed
09:21 davidre: Although I have no other idea if other compositors handle it properly
09:21 mclasen: ah, right. I had the wrong mental model of how cursor shape operates
09:21 MrCooper: mclasen: it's just a mutter bug which needs to be fixed
09:22 pq: There are no restrictions whatsoever on what kind of wl_surface a wp_viewport can be applied to.
09:24 pq: mclasen, btw. what roles/hats do you wear nowadays? I've been under the impression you had some significant role at Red Hat and/or GNOME? Or GTK?
09:24 mclasen: I manage some people and I write some code. Not sure if either of those are very significant
09:26 pq: ok, thanks
10:47 Company: pq: mclasen and me are the 2 main GTK developers atm who (try to) keep track of everything going on - though certain parts of the code have their own experts, like jadahl knows a bunch about the Wayland backend and garnacho knows about input
10:48 Company: that's more or less the relevant people for GTK / Wayland interactions I think
10:52 garnacho: we talked in the past about splitting gtk/mutter in terms of governance, perhaps next meeting might be a good first
10:53 pq: Company, cool, thanks
10:53 Company: technically that might make sense because the POV of the toolkits/apps is often different than the one of compositors
10:54 Company: but practically I don't know if anyone wants to do that job
10:54 kennylevinsen: it of course doesn't make extra staff appear out of thin air, but yeah it makes sense
10:55 Company: like, I try to stay out of the whole protocol mess, because the issue tracker discussions require way too much time
10:55 Company: and I'd probably get annoyed at the level of bikeshedding
12:46 zzag: davidre: mclasen: fwiw kwin allows using a viewporter on a cursor surface
12:46 mclasen: excellent
13:12 pq: weston does too btw - not that I've tried, but the architecture is completely oblivious whether something a cursor surface or not.
13:12 pq: *something is
13:19 ifreund: pretty sure wlroots does as well
14:23 wlb: wayland Merge request !379 opened by Sebastian Wick (swick) protocol: define content updates and their internal queue https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/379
14:25 leecommamichael: Hello, I was curious about the wayland.xml used to generate the client-protocol. Why? Is this done to make the protocol more language-agnostic? When should I re-generate the protocol? Should this be done on the user's machine if possible?
14:26 leecommamichael: (This is with respect to writing a client)
14:43 kennylevinsen: leecommamichael: yes, the protocol specification is meant to be human readable and to generate implementations
14:44 kennylevinsen: libwayland has its own code generator (wayland-scanner), but equivalent ones exist for other languages and libraries
14:45 kennylevinsen: think of Wayland like HTTP, with many implementations of servers and clients all speaking a common language defined in a spec.
14:46 kennylevinsen: When writing a client in C for example, you usually get the core protocol through libwayland itself, while you might have a meson rule to generate other chosen protocols at compile-time
14:56 leecommamichael: kennylevinsen: Right, I was just following wayland-book.com, and it didn't mention what considerations to make for breaking versions. Like, I can try to keep my libwayland-dev ahead of a user's, and re-generate my headers frequently. I read something about the protocol being fairly backwards compatible.
14:56 kennylevinsen: The protocol is versioned, and so a newer client can speak to an older server and vice-versa, as long as both respect the negotiated version number
14:57 wlb: weston Issue #899 opened by Marius Vlad (mvlad) X11/Wayland backends should disconnect heads for frontends to clean-up https://gitlab.freedesktop.org/wayland/weston/-/issues/899 [Nested X11 backend], [Nested Wayland backend]
14:58 leecommamichael: So all servers support all previous versions of the protocol.
14:58 leecommamichael: a difficult task, glad I'm not the one doing it.
14:58 kennylevinsen: yes, as the advertised version is a maximum
14:59 leecommamichael: Excellent. Thank you!
14:59 kennylevinsen: it's made a lot easier maintenance wise by the protocols being written with this in mind
14:59 kennylevinsen: so new versions tend to mainly add new requests and events, rather than massively redefine existing ones
15:54 wlb: weston Merge request !1483 opened by Derek Foreman (derekf) Fix up primary plane use after free https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1483 [Core compositor], [libweston API]
16:21 wlb: wayland-protocols Merge request !273 closed (presentation-time: Clarify what a content update is)
19:24 Sid127: hmm what's going on with the xdg-toplevel-icon protocol? would be cool to see it merged soon :3