02:45 DemiMarie: DodoGTA: Firefox should be processing messages from the Wayland socket even if the window is stuck in the debugger.
08:49 pq: emersion, libliftoff mentioned: https://lists.freedesktop.org/archives/dri-devel/2023-February/391762.html
08:50 pq: emersion, re: libdisplay-info version, I don't know really. I haven't read the semver specification well enough to answer that. I just had a feeling it might require 0.2.0.
08:50 emersion: yeah, we've talked about this at last XDC
08:52 pq: OTOH, since it's basically changing the name of display-info to libdisplay-info in pkg-config, that already accounts for the... "break".
08:53 pq: emersion, so, like in many comments I make, just asking due diligence
09:07 jadahl: pq: libliftoff helping offloading color management pipelines was something discussed in the conference call we had about that last fall. but it's hard to come up with an api that fits every type of hw
09:09 pq: jadahl, right, and yes, I can totally see that problem.
09:10 pq: jadahl, in Weston I'm approaching that same problem from the opposite direction: what do applications and the compositor need, rather than how to enable all existing hardware.
09:14 jadahl: pq: figuring that out seems crucial to then figure out how to best interact with kms
09:15 pq: yes, which is why I am not at all in a hurry with asking for more KMS color features.
09:16 pq: or even using the existing KMS properties
09:17 jadahl: understandable
09:19 pq: but I do want to be able to drive a HDR monitor in a known way with KMS :-)
09:19 pq: hence the "Colorspace" property discussion is is interesting to me right now
09:21 jadahl: yea, have to have support to get event the most basic thing working, but the harder part with libliftoff etc is offloading to planes
09:23 JEEB: pq: I've been laughing at how ad-hoc it seems like HDR vs colorspace property implementation was
09:24 JEEB: so I could f.ex. on AMD say my transfer is PQ
09:24 JEEB: but not say my primaries are BT.2020
09:24 JEEB: while to properly signal BT.2020+PQ in output you need both
09:24 JEEB: of course monitors seem to interpret that if you say PQ it's BT.2020 probably (or then the AMD driver is doing stuff behind your back)
09:25 JEEB: meanwhile my old x230 can do colorspace, but not HDR
09:25 pq: JEEB, I know :-D
09:27 JEEB: :)
09:27 pq: it's almost like "what's the minimum we need to fool the monitors to do what we want for one use case" - I can understand how people get there, it's purely practical for the one immediate need.
09:40 JEEB: yup
09:40 JEEB: also since x11 and wayland didn't and still don't support it -> no need. vulkan extension can go completely around KMS after all in the graphics driver
09:51 pq: only in proprietary drivers
09:55 JEEB: oh and the vulkan extension I found also kinda weird. it says HDR metadata, but then apparently sets colorspace and transfer as well?
09:55 JEEB: a lot of implicit stuff going rounds :D
09:56 JEEB: while on d3d11 I set my swap chain colorspace to BT.2020+PQ, and then if I have HDR metadata I set that separately as well.
09:56 pq: but it works, right? Industry standards, right? right?
09:57 pq: oh, your monitor only does HLG, hmm... nah, no-one makes such monitors. right? Oh but HLG also is de facto BT.2020. No problem!
10:00 JEEB: on macOS that can also be done, but I think they prefer linear fp16 scRGB now. windows also supports this, but since they haven't voiced a preference and the BT.2020 + PQ setting allows for seeming passthrough of PQ values that's what I default to atm
10:00 JEEB: :)
11:10 pq: emersion, did you intend to not cc dri-devel and linux-media lists with the libdisplay-info 0.1.1 annoucement?
11:10 pq: or are all announcements only on wayland-devel from now on?
11:13 emersion: the release template and docs don't cc these lists
11:14 pq: is that intentional?
11:15 emersion: i don't want to spam these other lists, but i also see why subscribers to these other lists would be interested
11:16 pq: yeah, maybe it's fine, but linux-media could use just the first announcement :-)
11:17 emersion: i will forward the 0.1.0 announcement then
11:17 pq: sounds good, and maybe also mention that further announcements are only on wayland-devel and that 0.1.1 is out already
11:18 pq: who knows, maybe someone would ask to cc linux-media in the future too
11:22 naveenk2: HI All, how do I run tests which are under weston/tests/* ? I want to run few tests such as color-icc-output-test.c
11:22 pq: naveenk2, 'meson test' runs them all. Or you can simply run any single binary itself. Each binary also has --help.
11:23 naveenk2: great!
12:15 swick[m]: the problem is that for hardware people HDR support is their fancy scanout hardware being able to offload the conversions so they want to expose that stuff right now
12:15 swick[m]: and then they just add it in a way that user space can't use it or only works on their hardware or whatever
12:16 pq: yeah
12:18 pq: Maybe they need to expose driver-specific UAPI and then the public API is some userspace library a la OpenGL and Vulkan. But that's also throwing all the existing KMS out the window.
12:18 swick[m]: I also don't know yet which exact transformations we will end up with in user space but pushing a new model where we can properly define the expectations from both user space and kernel would help a lot
12:18 daniels: tbf, whilst we don't want to compromise the long-term plan by having a random mish-mash of unusable stuff, having people actually be able to watch HDR movies or play HDR games in the interim would be a very good thing
12:19 swick[m]: yeah, that's why I want a Colorspace propert which does more magic in the kernel even though that's completely against my long term plans
12:20 pq: ah, Colorspace, yes
12:21 swick[m]: but that's why im advocating for a strict devision between the old and new stuff with a KMS cap
12:21 daniels: swick[m]: are you saying that I'm in favour of bad ideas, or that any interim solution is objectively bad, or are you just being snarky for the hell of it?
12:22 pq: the color pipeline off-loading is somewhat different though, we don't need it to make HDR videos and games work. It's for battery life instead.
12:22 swick[m]: daniels: neither? I think I agreed with you
12:23 swick[m]: pq: sure, but all the magic properties which we need to make HDR right now will make the offloading much worse to impossible
12:23 pq: that's fine :-)
12:26 daniels: yeah, making the old/coarse-grained and new/fine-grained property worlds mutually exclusive does sound sensible - I suspect it would probably be better as a CM_EPOCH property which the client sets though, because otherwise with caps you'd end up having to have the kernel sanitise the CM props in order to handle transitions between clients? e.g. if you change from Kodi doing current-HDR to a compositor doing no CM, the kernel would
12:26 daniels: need to know to clean up the props that Kodi set and set them back to 'normal'
12:26 vsyrjala: i don't see why the old prop really matters at all. if you don't want to use it then don't
12:27 vsyrjala: we can postpone the decision whether to fully remove it or not
12:29 pq: what does "not use it" mean for a property that cannot be without a value?
12:30 vsyrjala: it'll be left with the default, which lets the driver do whatever
12:32 pq: ok. And switching between different KMS clients is so niche that it can continue to be completely ignored like it has been.
12:32 emersion: i'd be in favor of disabling the old props when the cap is enabled
12:32 emersion: like DPMS
12:33 emersion: otherwise it's just more edge cases to think about
12:33 emersion: ie. the client can ask for non-sensical and self-contradictory configurations
12:34 pq: and that becomes a real problem when it accidentally does something the client relies on :-)
12:35 vsyrjala: i don't consider it much different than eg. providing bogus hdr metadata. the kernel won't save you from that footgun
12:35 emersion: providing bogus HDR metadata is less of an issue, since the kernel just passes it through
12:35 pq: vsyrjala, it's not about the client shooting its foot. It's about the client *aiming* its foot and hitting a bullseye instead.
12:35 vsyrjala: the kernel also just passes through the colorspace prop
12:36 emersion: why build a footgunny api on purpose?
12:36 emersion: is there a use-case where it's useful to have both old and new?
12:37 vsyrjala: we already have it. seems to me people are needlessly stuck on this point when they should be writing patches for the new prop
12:37 emersion: i mean this stuff is already complicated enough, i don't see why we need the api to be even more complicated to think about just for fun
12:38 swick[m]: I also really don't see what the benefit is for keeping everything around
12:38 swick[m]: its just more complexity for the sake of it
12:38 vsyrjala: not sure adding yet anorher cap in the mix is going to simplify anythging. but if someone wants to write a patch for that then i guess at least we'd have something real to talk about
12:39 swick[m]: the problem with that is that I'm not a kernel developer and certainly don't have the time to become one right now
12:40 swick[m]: the reason why I'm involved here at all is because the kernel developers manage to create interfaces which are literally unsable
12:41 swick[m]: and a few more properties which kernel developers wanted to add were also going to be unsable
12:42 vsyrjala: my take is to 1) add the new prop 2) ignore the other mess for now, so that we can at least make *some* progress
12:42 vsyrjala: designing the new prop doesn't depend on solving the mess
12:43 swick[m]: true. i think we can all agree to that
12:43 emersion: yup
12:57 swick[m]: daniels: with the CM_EPOCH approach at least the kernel knows when a client needs all the magic properties to do their thing and it can reset everything to reasonable values whereas a combination of new and old properties will result in conflicting magic properties (old) and explicit properties (new) being set...
12:58 swick[m]: I really don't want to think about the semantics in that case
13:00 pq: What's the difference between CM_EPOCH property and a client cap again? Except clients who don't understand CM_EPOCH would never reset it, while the client cap is tied to the client.
13:01 swick[m]: mh, good point. I think I really want a cap then...
13:03 emersion: yes, client cap
14:06 ukiran: Hello
14:08 ukiran: Am seeing an visual artifact issue on the ubuntu-22.04.1 version when maximizing/minimizing the window with the bottom-right corner using mouse
14:08 ukiran: looks to be window decoration issue.
14:11 ukiran: does anyone seeing this issue ?
14:23 DodoGTA: DemiMarie: Then why does it still error out with that "error in client communication" thing when hovering over some elements in the Inspector (which causes a freeze) and moving around the mouse a bit?
14:39 kennylevinsen: They're probably accidentally blocking their main thread. They do have a bunch of things that end up running on the main thread for architecture and "web" reasons...
14:41 kennylevinsen: All proposals in this area effectively extend the time until the connection dies, but do not change the fact that blocking will eventually lead to terminated connections
15:23 DemiMarie: DodoGTA: The correct thing for Firefox to do would be to either handle the Wayland socket in a separate thread or run a separate message loop that only handles Wayland events. Please report this as a Firefox bug.
15:35 kennylevinsen: Well, to run whatever blocks in a different thread. You usually call the event loop handling the Wayland display for the main thread
15:38 kennylevinsen: but one cannot blame Firefox entirely if high-resolution input (gamer mice) is involved: then you have Firefox doing something bad by blocking, but the compositor is also spamming the process at very high rates making even a short pause in reading overflow the buffer... So, improvements needed on both sides.
15:39 kennylevinsen: blocking very momentarily needs to be possible - one has to dispatch the queue after reading after all
15:54 parazyd: Hey
15:54 parazyd: I got a graphics tablet and I'm trying to get it working with libinput (on X11)
15:55 parazyd: After battling with my kernel I think I finally got all the right drivers, and the device seems to be recognised
15:55 parazyd: But now I'm struggling with libinput understanding it
15:56 parazyd: It gives me the following error when I connect my tablet: HUION Huion Tablet_H580X: libinput bug: missing tablet capabilities: resolution
15:56 parazyd: I've tried adding _something_ to evdev.hwdb to no avail
15:56 parazyd: Any clues?
16:00 emersion: parazyd: maybe ask whot in #wayland on OFTC
16:00 emersion: oh
16:00 emersion: we are in #wayland on OFTC, it turns out :P
16:01 parazyd: haha
16:01 parazyd: Yeah the /topic on libera pointed me here
16:01 emersion: so used to having these questions in #sway
16:01 parazyd: oh so there are ppl with this problem?
16:01 emersion: no, i mean this kind of question, not this specific one, sorry!
16:01 parazyd: ah
16:02 soreau: parazyd: Did you read through https://wayland.freedesktop.org/libinput/doc/1.12.0/tablet-debugging.html ?
16:03 parazyd: Yeah I tried stuff with the hwdb file but I'm not exactly sure how to work with it
16:04 parazyd: I see the events in libinput record
16:06 soreau: it looks like this bug report has some info https://github.com/Evidlo/remarkable_mouse/issues/18
16:08 parazyd: cat /sys/devices/virtual/input/input34/modalias
16:09 parazyd: input:b0005v0000p0000e0000-e0,...
16:09 parazyd: Would "evdev:input:b0005v0000p0000e0000*" be a valid hwdb entry?
16:14 parazyd: oh I was using the wrong one
16:15 parazyd: hah nice
16:15 parazyd: 1) Disconnect tablet, 2) find /sys | sort > first , 3) Connect tablet, 4) find /sys | sort > second , 5) diff -up first second | grep modalias
16:17 parazyd: ok, semi-related. Is there a way I could use it specifically as a tablet input but _not_ a mouse pointer?
21:53 DemiMarie: kennylevinsen: “whatever blocks” is likely JavaScript. Moving Wayland to a separate thread is probably a much smaller change.
21:56 bl4ckb0ne: i did that in my compositor, with a lock it goes pretty well
22:06 kennylevinsen: DemiMarie: Firefox does not own the Wayland connection as it piggybacks off Gtk, so non-trivial to move things around
22:09 whot: parazyd: you need a resolution for ABS_X and ABS_Y, that's usually a kernel driver issue and should be set there but you can override it with a hwdb entry. but given that your VID/PID are all zeroes, looks like your kernel driver isn't quite up to scratch yet