01:56 runxiyu_: wl_shm#4: error 1: Invalid size (-1673527296)
01:56 runxiyu_:going insane trying to learn and port an example application to hidpi
02:04 jadahl: runxiyu_: the tl;dr for non-fractional scaling: multiply buffer size with hidpi scale, but not the input region/window geometry/opaque region. the scale you get from wl_output+wl_surface.enter or wl_surface.buffer_scale
02:05 jadahl: make that wl_surface.preferred_buffer_scale, not .buffer_scale
02:07 danieldg: if you use INT_MAX for values where you mean "infinity", avoid multiplying that by scale
02:19 runxiyu_: Unfortunately, I am using fractional scaling in my compositor... also I'm using libwayland-client:
02:19 runxiyu_: I'm responding to scale in wl_output_listener.scale, then putting it right into wl_surface_set_buffer_scale and comitting the surface
02:19 runxiyu_: (Sorry if what I say doesn't make much sense, I'm very new to wayland and graphics in general)
02:20 runxiyu_: I'm also multiplying by the scale in shm_get_buffer
02:20 runxiyu_: (Perhaps to complicate things a bit, this involves pixman)
02:20 danieldg: that's the old way to do it; if your compositor supports wl-compositor v6 just listen for the preferred events
02:21 danieldg: no need to track outputs
02:21 danieldg: if you want to support pre-v6 then you track output scale too
02:21 jadahl: if you just commit the new buffer scale, you are likely to have your client get disconnected because the surface size isn't possible
02:21 runxiyu_:facepalms
02:22 danieldg: yes, you should commit both the new scale and the scaled buffer at the same time
02:25 runxiyu_: If I do these above, will my program look blurry in fractionally scaled compositors?
02:26 danieldg: a little, but not as bad as if you just did scale 1
02:26 danieldg: rendering at scale 2 and having the compositor scale down to 1.5 is sharper than scaling up
02:27 runxiyu_: oh :(
02:27 runxiyu_: i guess i need to implement actual fractional scaling
02:27 danieldg: yeah, annoying but if you care about perfection it's required
02:29 runxiyu_: for my purposes i'd prefer the compositor to report the preferred factor to the client, and then just let the client handle it how it wants and the compositor never scales it artificially
02:29 runxiyu_: but yeah anyways
02:30 danieldg: that doesn't work as nicely if you have two screens at different scales
02:33 runxiyu_: i do use multiple monitors at different scales sometimes and i'd prefer things to be sized improperly than to be blurry :/
02:33 runxiyu_: but yeah having windows that span different screens would be kinda impossible
02:33 danieldg: also someday there will be a 'desktop zoom' feature that just works by telling windows to scale up
02:34 danieldg: maybe wayfire or someone has it already?
02:35 runxiyu_: i do that in sway by setting my scale factor (since all programs i use day to day support fractional scaling properly)
02:35 danieldg: multiple monitors with fractional scaling is basically guaranteed to be blurry unless you redesign wayland
02:36 danieldg: you'd have to tell the application multiple preferred scales for distinct regions of the window and have them lay out subsurfaces
02:36 runxiyu_: true
02:36 danieldg: sure you can shoehorn that in to the existing protocol, but that's really ugly
02:37 runxiyu_: i never have a window across multiple monitors, so it seems like I didn't experience that
02:38 danieldg: right, if you don't do that (or don't do it much) then it'll just send the new preferred-scale event and the window gets fixed
02:54 whot: orowith2os[m]: fwiw, the reason MAX isn't exposed anywhere is because it's implementation defined, we used 64 as "good enough" but might update to any other value (or allocated arrays) in which case max changes or becomes obsolete
02:54 jadahl: danieldg: per region scale / split buffer will still result in blurry-ness when you move things around. the only way to fix it is to have multiple buffers for the same surface with different scales
02:58 danieldg: hmm, yeah, that would be a nicer way to do it
02:59 danieldg: just make some kind of multi-attach request along with a framed version of preferred fractional scale
03:00 danieldg: the attach would need to specify the scale itself, instead of abusing viewporter
03:00 runxiyu_: that'd be insane for applications to implement properly
03:00 runxiyu_: (i'm not exactly sure about what viewporter does)
03:00 danieldg: if the application is scalable (think renders to SVG internally) then you just render each frame twice, once per scale
03:01 danieldg: viewporter is how you request the compositor scale your buffer
03:01 danieldg: fractional scale depends on it, instead of the buffer scale request
03:02 danieldg: so an app supporting fractional scale on a compositor supporting it will never call set_buffer_scale
03:03 danieldg: ah, you'd have to replace damage_buffer to support multiple attach too
03:03 runxiyu_: oh, so if i have a compositor that supports viewporter and i could tell a compositor 'don't scale my stuff at all' (if the compositor would otherwise apply fractional scaling to my surface)?
03:03 runxiyu_: hmm
03:03 danieldg: yes, you can do that basically
03:03 danieldg: in fact that's how you fractional scale in the first place
03:04 runxiyu_: oh, interesting
03:04 danieldg: you figure out the real size of the window, make a buffer that size, and then tell the compositor 'scale me down to the size you are pretending I am at'
03:05 danieldg: and the compositor does the final buffer composition and figures out that oh, looks like I need to do 1.5*0.6667 scaling on this... no-op!
03:06 runxiyu_: hmmm
03:06 runxiyu_: i wonder how it'd behave on multiple displays...
03:07 danieldg: that's what jadahl and I were talking about. It's always blurry on one unless they match scale
03:08 danieldg: the monitor with the non-matching scale will actually have the viewporter-ed buffer in need of scaling
03:09 runxiyu_: :(
03:17 aelius: Hey all- decades ago I loved 'synaptics momentum'. Is there any plan to support such a thing in libinput? Or, is there any existing project that would allow me to hack in the feature to wayland in some way?
03:19 aelius: If you're not familiar- the idea has gone by many names. Steam calls it "trackball emulation" for use on the steam deck's touchpads. Googling around, I see a lot of results asking for "inertial pointing" (as opposed to inertial scroll) or "coasting but for the pointer not just scrolling"
03:43 whot: aelius: no plans to implement this in libnput
03:47 aelius: If I wanted to make this happen- what routes are available? Preferrably something that works on top of libinput instead of replacing it
05:22 whot: aelius: on top of libinput is difficult due to how libinput is integrated into the stack, there's no simple way of wedging things in
05:23 whot: aelius: the main reason it doesn't exist is because it's quite a niche feature and it's unlikely to work the way some people want it which then results in an endless cycle of "can we have a configuration option for this"
05:24 aelius: whot: It looks like windowmanagers can arbitrarily set the location of the cursor... how performant would that be if done 60 times per second? :)
05:25 whot: that's only true for xorg, not wayland and while you *could* do this in wayland it's unlikely any specific compositor will want to implement this
05:25 whot: but really, neither the WM nor the comp have the information to know *when* to do this, "edge of touchpad" is not rally known to anything but libinput
05:26 aelius: That's not how it works- you only need to know if the finger is present or not, the rest can be backcalculated
05:27 aelius: Either by finger coordinates or mouse coordinates over a short time period, to detect flicking
05:27 whot: i guess you want a different feature than what I saw a few days ago where the request was to keep moving when the finger reaches the edge
05:27 aelius: hyprland can "warp" the cursor to the center of a window, so it appears moving the mouse isn't an xorg specific thing
05:29 whot: the compositor sits between libinput and the cursor so it can do what it wants, libinput can say "move by 10 pixels" and then the comp can do that or not. on Xorg it's different where the WM is on the side and needs to warp the pointer
05:30 aelius: ok
05:30 whot: so the actual pointer movement is much easier in wayland than x, but it'll have to be in each composito
05:30 aelius: the compositor is usually wlroots, right? The thing many window managers seem to be based on
05:31 whot: fsvo "usually" :)
05:31 whot: in the same way as users "usually" use xorg or wayland, there's a rather large number of users that use neither because they use win/mac :)
05:31 aelius: and yes, the feature very different from continue-at-edge. Think of inertial scrolling, but for the pointer. You can flick and stop touching entirely, but it keeps scrolling- determined by the initial speed of the flick and some friction value
05:32 whot: wlroots is the same, there is a large number of compositors that use it but the two biggest ones (by user count) don't (kwin, mutter)
05:33 whot: problem is the compositor doesn't know when a finger is on the touchpad, libinput doesn't really export that information. the compositor *barely* knows it's a touchpad
05:33 aelius: So it seems like I'd need to hack it into libinput and compile my patch locally
05:33 whot: so any logic would have to be reverse-engineered on top of whatever events you do get (gestures, movement, etc.) and those heuristics are going to fail
05:34 whot: yeah, libinput is really the only way right now, unless we open up some raw mode into libinput (was an idea years ago for allowing things like drawing glyphs on the touchpad, but never got anywhere)
05:35 aelius: It's possible to do it jankily by observing the cursor alone, but yeah, it'd be more ideal if libinput had "inertial_pointer = true; inertial_pointer_friction = 0.3" as settings ;)
05:36 whot: cue the outrage that 0.3 is the wrong value and how dare you!
05:36 aelius: D:
05:36 whot: remember that for the first half of the conversation we were talking about two different features :)
05:37 aelius: Yeah. When this was a thing in the mid 2000s it seemed to be targeting very small touchpads. And now it seems that it's assumed unnecessary with our needlessly enormous touchpads. But dammit, it was just better all around
05:39 aelius: It allows for slow, precise, linear pointing- but you can still rapidly shoot the cursor large distances... and all while moving your finger less distance than normal touchpad use.
05:41 aelius: The unstated second part to "flick the cursor like inertial scrolling" is that touching the touchpad again will stop the cursor. You aim, fire- cursor reaches desired region, touch to stop (and start tracking normally)
05:45 aelius: stated another way- while touching the touchpad, it behaves conventionally- the inertial logic is only active when you're not touching it.
05:46 aelius: so, you know, like a physical trackball :)
05:52 orowith2os[m]: aelius: you can also get inertial information if you throw your mouse/laptop
05:53 orowith2os[m]: probably won't be useful for your computer though. But it'll get your frustrations out
06:10 whot: aelius: stopping the gesture is easier because we do have hold gestures (they work for stopping kinetic scrolling)
06:10 whot: what is missing is a finger up notification for pointer movement, we have that for scrolling which is why kinetic scrolling is possible
08:23 aelius: W
08:23 aelius: ell, kinetic scroll is implemented per program, right?
08:27 aelius: On windows it very much isn't, which results in the rather silly situation where the "scroll" is invisibly ticking away- but any program you mouse-over will start scrolling
08:29 aelius: if trackball emulation has to be /in/ libinput (and it probably does), exposing events externally isn't on the roadmap
09:26 kennylevinsen: aelius: yes, wayland's wl_pointer just reports the actual scroll wheel movement
11:57 pq: fwiw, this is the diff between xx-color-management-v4 and staging v1: https://gitlab.freedesktop.org/pq/color-and-hdr/-/snippets/7829
11:59 swick[m]: I went through the commits one by one instead
12:00 swick[m]: one thing that was annoying is that power TFs use another multiplier than chromaticity coordinates
12:01 pq: Didn't we have some back-and-forth in the commits? I guess not too much.
12:01 swick[m]: the naming on some things changed twice but that was all
19:45 mahkoh: Are there any easy-to-understand resources explaining the behavior of the Colorspace and HDR_STATIC_METADATA DRM properties and also how they interact? In my tests, over display port, the HDR metadata has no effect if the Colorspace property is set to 0, except that the eotf function takes effect.
19:46 mahkoh: Assuming that I set the Colorspace to something meaningful, how does this interact with the primaries that are being set in the HDR metadata? Doesn't the Colorspace already determine the primaries?
19:47 mahkoh: With display port, the colorspace property seems to flow into a so-called VSC (video stream configuration) packet which has support for such things since DP 1.3.
19:48 mahkoh: But the DisplayPort specifications for anything later than 1.2 seem to have been scrubbed from the internet. At least HDMI 2.0 can be found on archive.org.
19:49 mahkoh: s/HDR_STATIC_METADATA/HDR_OUTPUT_METADATA/
20:03 swick[m]: it's all in CTA-861
20:04 swick[m]: with it you can understand the intended behavior of sending the HDR Static Metadata and Colorimetry InfoFrames
20:04 sqwishy: Hey I'm just curious about wayland's design for IPC stuff between clients and compositors and I am wondering, in os-compatibility.c, why isn't shm_open used as a fallback when memfd_create is not supported? I don't know much about this kind of thing and am just trying to understand and learn from the decisions that were made
20:06 swick[m]: mahkoh: but the KMS props cannot work the way they are documented, hence https://lists.freedesktop.org/archives/dri-devel/2024-March/444707.html
20:06 swick[m]: but that never got merged
20:10 mahkoh: I feel like I've read the contents of your patch before in the kernel sources while researching this.
20:11 mahkoh: It's the documentation of the drm_mode_create_colorspace_property function.
20:13 emersion: swick[m]: i think your patch is merged?
20:13 swick[m]: huh, was it?
20:13 emersion: i see it here https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#standard-connector-properties
20:14 emersion: the formatting isn't great sadly
20:14 mahkoh: Anyway, I still don't understand how this property and the primaries from the HDR_OUTPUT_METADATA interact. If that is defined in CTA-861, do you have more detailed references (document, page number)? I've read a few of them and I still have no idea how this maps to the kernel constructs.
20:14 swick[m]: oh, yes, nice
20:15 emersion: feel free to bug me if such doc patches get stuck
20:15 swick[m]: ack
20:15 swick[m]: mahkoh: ah, CTA-861 defines the InfoFrames which carries a TF overwrite and the actual HDR metadata which is defined by SMPTE
20:16 swick[m]: https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/mastering_display_metadata.md
20:18 mahkoh: I have "HDR Static Metadata Extensions - CTA-861.3-A" in front of me which defines what seems to map directly to HDR_OUTPUT_METADATA. However, regardless of what I set the Colorspace property to, the primaries from the HDR_OUTPUT_METADATA don't change the display output at all.
20:20 zamundaaa[m]: That is expected
20:20 zamundaaa[m]: Many displays go as far as completely ignoring all HDR metadata
20:20 mahkoh: I see. But this is not guaranteed? If I only want to change the EOTF for example, do I still have to set the other fields to sensible values because some displays use them?
20:21 swick[m]: > The Mastering Display Metadata is optional. When no metadata is given, everything is still well-defined. The only consequence is a possible loss in image quality due to the greater mapping distances.
20:21 swick[m]: practically, set it to 0
20:26 JEEB: yea, CTA itself adds that note that all-zero is "ignore"
20:26 JEEB: (which then IIRC is then noted in the SMPTE spec)
20:32 mahkoh: The document I mentioned above does say "The SMPTE ST 2086 [3] metadata contained in Bytes 3-22 of Table 5 __may__ be used by the Source" but I haven't yet found how the source indicates that it does not use those bytes.
20:33 mahkoh: Do you have a reference for all-zero being ignored?
20:34 mahkoh: Ah, I think this is it: "The data in Data Bytes 3 – 26 are arranged into groups, as indicated in Table 5 above. When all of the Data Bytes in a group are set to zero, then the Sink shall interpret the data for that group as unknown"
20:36 JEEB: yup