ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
bodiccea has quit [Ping timeout: 480 seconds]
bodiccea has joined #wayland
m5zs7k_ has quit []
m5zs7k has joined #wayland
vincejv has quit [Remote host closed the connection]
vincejv has joined #wayland
hergertme has quit [Quit: Leaving]
Brainium has quit [Quit: Konversation terminated!]
glennk has joined #wayland
Moprius has quit [Remote host closed the connection]
* runxiyu_
going insane trying to learn and port an example application to hidpi
sqwishy has joined #wayland
<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
<jadahl>
make that wl_surface.preferred_buffer_scale, not .buffer_scale
<danieldg>
if you use INT_MAX for values where you mean "infinity", avoid multiplying that by scale
<runxiyu_>
Unfortunately, I am using fractional scaling in my compositor... also I'm using libwayland-client:
<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
<runxiyu_>
(Sorry if what I say doesn't make much sense, I'm very new to wayland and graphics in general)
<runxiyu_>
I'm also multiplying by the scale in shm_get_buffer
<runxiyu_>
(Perhaps to complicate things a bit, this involves pixman)
<danieldg>
that's the old way to do it; if your compositor supports wl-compositor v6 just listen for the preferred events
<danieldg>
no need to track outputs
<danieldg>
if you want to support pre-v6 then you track output scale too
<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
* runxiyu_
facepalms
<danieldg>
yes, you should commit both the new scale and the scaled buffer at the same time
<runxiyu_>
If I do these above, will my program look blurry in fractionally scaled compositors?
<danieldg>
a little, but not as bad as if you just did scale 1
<danieldg>
rendering at scale 2 and having the compositor scale down to 1.5 is sharper than scaling up
<runxiyu_>
oh :(
<runxiyu_>
i guess i need to implement actual fractional scaling
<danieldg>
yeah, annoying but if you care about perfection it's required
<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
<runxiyu_>
but yeah anyways
<danieldg>
that doesn't work as nicely if you have two screens at different scales
<runxiyu_>
i do use multiple monitors at different scales sometimes and i'd prefer things to be sized improperly than to be blurry :/
<runxiyu_>
but yeah having windows that span different screens would be kinda impossible
<danieldg>
also someday there will be a 'desktop zoom' feature that just works by telling windows to scale up
<danieldg>
maybe wayfire or someone has it already?
<runxiyu_>
i do that in sway by setting my scale factor (since all programs i use day to day support fractional scaling properly)
<danieldg>
multiple monitors with fractional scaling is basically guaranteed to be blurry unless you redesign wayland
<danieldg>
you'd have to tell the application multiple preferred scales for distinct regions of the window and have them lay out subsurfaces
<runxiyu_>
true
<danieldg>
sure you can shoehorn that in to the existing protocol, but that's really ugly
<runxiyu_>
i never have a window across multiple monitors, so it seems like I didn't experience that
<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
<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
<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
<danieldg>
hmm, yeah, that would be a nicer way to do it
<danieldg>
just make some kind of multi-attach request along with a framed version of preferred fractional scale
<danieldg>
the attach would need to specify the scale itself, instead of abusing viewporter
<runxiyu_>
that'd be insane for applications to implement properly
<runxiyu_>
(i'm not exactly sure about what viewporter does)
<danieldg>
if the application is scalable (think renders to SVG internally) then you just render each frame twice, once per scale
<danieldg>
viewporter is how you request the compositor scale your buffer
<danieldg>
fractional scale depends on it, instead of the buffer scale request
<danieldg>
so an app supporting fractional scale on a compositor supporting it will never call set_buffer_scale
<danieldg>
ah, you'd have to replace damage_buffer to support multiple attach too
<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)?
<runxiyu_>
hmm
<danieldg>
yes, you can do that basically
<danieldg>
in fact that's how you fractional scale in the first place
<runxiyu_>
oh, interesting
<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'
<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!
<runxiyu_>
hmmm
<runxiyu_>
i wonder how it'd behave on multiple displays...
<danieldg>
that's what jadahl and I were talking about. It's always blurry on one unless they match scale
<danieldg>
the monitor with the non-matching scale will actually have the viewporter-ed buffer in need of scaling
<runxiyu_>
:(
aelius has joined #wayland
<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?
<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"
<whot>
aelius: no plans to implement this in libnput
nerdopolis has quit [Ping timeout: 480 seconds]
<aelius>
If I wanted to make this happen- what routes are available? Preferrably something that works on top of libinput instead of replacing it
nerdopolis has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
<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
<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"
<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? :)
<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
<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
<aelius>
That's not how it works- you only need to know if the finger is present or not, the rest can be backcalculated
<aelius>
Either by finger coordinates or mouse coordinates over a short time period, to detect flicking
<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
<aelius>
hyprland can "warp" the cursor to the center of a window, so it appears moving the mouse isn't an xorg specific thing
<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
<aelius>
ok
<whot>
so the actual pointer movement is much easier in wayland than x, but it'll have to be in each composito
<aelius>
the compositor is usually wlroots, right? The thing many window managers seem to be based on
<whot>
fsvo "usually" :)
<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 :)
<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
<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)
<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
<aelius>
So it seems like I'd need to hack it into libinput and compile my patch locally
<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
<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)
<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 ;)
<whot>
cue the outrage that 0.3 is the wrong value and how dare you!
<aelius>
D:
<whot>
remember that for the first half of the conversation we were talking about two different features :)
<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
<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.
<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)
slattann has joined #wayland
<aelius>
stated another way- while touching the touchpad, it behaves conventionally- the inertial logic is only active when you're not touching it.
<aelius>
so, you know, like a physical trackball :)
slattann1 has quit [Ping timeout: 480 seconds]
<orowith2os[m]>
aelius: you can also get inertial information if you throw your mouse/laptop
<orowith2os[m]>
probably won't be useful for your computer though. But it'll get your frustrations out
<whot>
aelius: stopping the gesture is easier because we do have hold gestures (they work for stopping kinetic scrolling)
<whot>
what is missing is a finger up notification for pointer movement, we have that for scrolling which is why kinetic scrolling is possible
RAOF has quit [Remote host closed the connection]
kts has joined #wayland
RAOF has joined #wayland
sima has joined #wayland
tzimmermann has joined #wayland
rasterman has joined #wayland
kts has quit [Ping timeout: 480 seconds]
coldfeet has joined #wayland
coldfeet has quit []
coldfeet has joined #wayland
kts has joined #wayland
glennk has joined #wayland
JakeSays1 has joined #wayland
JakeSays has quit [Ping timeout: 480 seconds]
kenny has quit [Ping timeout: 480 seconds]
bindu has joined #wayland
bindu_ has quit [Ping timeout: 480 seconds]
kenny has joined #wayland
<aelius>
W
<aelius>
ell, kinetic scroll is implemented per program, right?
<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
<aelius>
if trackball emulation has to be /in/ libinput (and it probably does), exposing events externally isn't on the roadmap
bodiccea has quit [Remote host closed the connection]
bodiccea has joined #wayland
kts has quit [Ping timeout: 480 seconds]
leon-anavi has joined #wayland
iomari891 has quit [Quit: WeeChat 4.3.1]
iomari891 has joined #wayland
<kennylevinsen>
aelius: yes, wayland's wl_pointer just reports the actual scroll wheel movement
<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.
<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?
<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.
<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.
<swick[m]>
with it you can understand the intended behavior of sending the HDR Static Metadata and Colorimetry InfoFrames
<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
<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.
<swick[m]>
oh, yes, nice
<emersion>
feel free to bug me if such doc patches get stuck
<swick[m]>
ack
<swick[m]>
mahkoh: ah, CTA-861 defines the InfoFrames which carries a TF overwrite and the actual HDR metadata which is defined by SMPTE
<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.
zamundaaa[m] has joined #wayland
<zamundaaa[m]>
That is expected
<zamundaaa[m]>
Many displays go as far as completely ignoring all HDR metadata
<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?
<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.
<swick[m]>
practically, set it to 0
<JEEB>
yea, CTA itself adds that note that all-zero is "ignore"
<JEEB>
(which then IIRC is then noted in the SMPTE spec)
Brainium has joined #wayland
<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.
<mahkoh>
Do you have a reference for all-zero being ignored?
<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"