12:45 zamundaaa[m]: pq: the color MR turns 5 years old tomorrow
12:45 zamundaaa[m]: A good day to merge it?
13:47 MrCooper: would be a neat coincidence, shouldn't rush anything for that though
14:54 wlb: weston Issue #989 opened by Derek Foreman (derekf) Follow-up from "Add perfetto instrumentation to weston" with debug annotations https://gitlab.freedesktop.org/wayland/weston/-/issues/989 [Core compositor], [Debug]
17:37 karenw: Hi. So trying to implement touch support in my example client. Am I right in thinking there is not a single 'focus' for the whole seat like wl_pointer and wl_keyboard, but each touchpoint has it's own wl_surface?
17:39 vyivel: karenw: yes
17:40 karenw: Excellent. Glad I understand ;)
17:45 karenw: This makes me think my pointer tracking of focus is a bit nobbled. Since there can be a frame() event after leave(). I guess I should only forget or change the focus in frame(). Urgh.
17:59 wlb: wayland-protocols Merge request !263 closed (Make pointer warping required behavior)
18:12 swick[m]: zamundaaa: given that we still have API breaking MRs open that feels a bit rushed
18:27 zamundaaa[m]: It's hard to call anything "rushed" when talking about a protocol that's been in development for over a decide, a MR that's 5 years old and has many implementations in compositors and clients
18:28 zamundaaa[m]: That one MR should be decided on before merging the protocol of course, but that should be done in a reasonable time frame
18:29 orowith2os[m]: I noticed that https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/294 hasn't had too much activity, and there's not really much pushback against it. It looks like there's desire from GNOME for it to land (then they'll add cursor-shape-v2 to mutter and gtk), Jay has a MR for it, wlroots has a MR for it, and zzag is fine with it. Is there anything that needs to be done there?
18:30 wlb: weston Merge request !1676 opened by Loïc Molinari (molinari) Improve read-back: Texture swizzles (3/4) https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1676 [Clients], [GL renderer], [Testing]
18:42 karenw: What should happen if I get the following touch events? Down Frame Up Cancel. Is the touchpoint still valid?
18:43 karenw: I assume not, because of the 'up'. But then what happens if I get "Up Down Frame" with the same id? That's a new touchpoint inside the same frame?
19:55 karenw: Interesting, mutter increments the touchpoint id every touch, but kwin/weston/sway all reuse low numbers.
19:55 karenw: Both are within spec though, right?
19:56 vyivel: yes
20:51 orowith2os[m]: swick: random question, how does color-management-v1 deal with black-and-white displays?
20:51 orowith2os[m]: granted I'm not sure if it's dealt with literally anywhere else within Linux
20:52 orowith2os[m]: I know you mentioned communicating color deficiencies to applications on xdp, maybe this would help?
20:52 orowith2os[m]: or do you want something else for that?
20:59 swick[m]: If you don't have colors, you wouldn't implement it
21:00 swick[m]: technically you still could but it would be almost pointless
21:00 swick[m]: s/implement/expose
21:00 orowith2os[m]: gotcha
21:00 orowith2os[m]: so it would need to be exposed some other way
21:01 swick[m]: the protocol is about content and displays, not about the observer, so color deficiencies are not well suited there
21:02 orowith2os[m]: I guess so. I'll have to take a closer look at the protocol to see if it can't be reasonably added to that
21:03 orowith2os[m]: primaries wouldn't work?
21:03 swick[m]: CVD don't just change some "primaries"
21:04 orowith2os[m]: hmm
21:05 swick[m]: CVDs are often the result of changes in the responsiveness of the photo cells
21:05 orowith2os[m]: what would communicating the fact that the display is grayscale look like, in your ideal world?
21:05 swick[m]: not sure
21:07 swick[m]: the only grayscale displays that I'd think would be reasonable to run a full wayland compositor on are probably eink displays, and they come with a whole bunch of unsolved issues
21:07 emersion: yeah, need a whole lot more than just "the display is black-and-white/grayscale"
21:09 orowith2os[m]: I guess if a hardware platform is using eink in general, wayland just wouldn't be useful, considering part of their use cases is low power draw (and using normal desktop software might not get that)
21:09 orowith2os[m]: but this issue is still kind of there with desktop-oriented eink displays
21:10 karenw: Isn't it currently baked into the wl_compositor protocol that argb8888 and xrgb8888 are ubuquitous?
21:10 orowith2os[m]: and maybe statistics on embedded systems, like an rpi....
21:12 wlb: weston Merge request !1677 opened by gpotter2 (gpotter2) Move shell structures of desktop-shell to the header https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1677
21:14 orowith2os[m]: whew, $700 for an eink display to use with a normal desktop..... glad we don't have to deal with that just yet.
21:14 Arnavion: <orowith2os[m]> I guess if a hardware platform is using eink in general, wayland just wouldn't be useful < Users of the PineNote (e-ink tablet) were running Sway and GNOME Wayland on it I believe. There might've been some patches or custom themes involved
21:15 emersion: karenw: the compositor can convert to grayscale as a fallback. that's what some KMS drivers do for instance