ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<orowith2os[m]>
is this an okay place to ask about libinput stuff?
<orowith2os[m]>
I'm investigating custom accel profiles in mutter
<vyivel>
yes
<orowith2os[m]>
okay. Are there any good references for adding custom accel profiles to a compositor? how it's expected to get the curves?
<orowith2os[m]>
or is it expected that the compositor sees "custom" and calls a script or something?
<vyivel>
libinput_config_accel_set_points()?
<vyivel>
so a compositor would take a list of numbers
<orowith2os[m]>
hm, like a [double, double]?
<orowith2os[m]>
where the first is a point, and the second is a speed for that point and up, until the next point?
<vyivel>
afaiu yes
<orowith2os[m]>
hm, okay
<vyivel>
well the first double is computed as i * step
<vyivel>
so you provide a list of speeds
<vyivel>
and step to compute points
<orowith2os[m]>
I'm uh. a fair bit outside of my comfort zone here. so trying my best to understand
<vyivel>
…which is kinda strange api tbh
<orowith2os[m]>
I'm trying to think of it like, [(0.0, 1), (1.0, 1.5), (2.0, 3.0)] or something
<vyivel>
you have a step and a list of speeds, so the resulting points are (0 * step, speeds[0]), (1 * step, speeds[1]), (2 * step, speeds[2]), …
<orowith2os[m]>
hm
<vyivel>
okay huh seems like xf86-input-libinput calls that function so maybe could check what user configuration interface it provides
<orowith2os[m]>
my brain had the idea of [n].0 is the physical device speed, [n].1 is the speed in software
<vyivel>
yep, "The x-axis represents the device-speed in device units per millisecond. The y-axis represents the pointer-speed."
<orowith2os[m]>
so would having that as the configuration API in GNOME be okay?
<orowith2os[m]>
just an array of tuples containing two doubles?
<vyivel>
the first doubles are in steps so they can't be arbitrary
<vyivel>
you could like
<vyivel>
allow the user to set the step and take a list of pointer-speeds
<vyivel>
and then show them the result (which would be a list of tuples)
<orowith2os[m]>
this is all in gsettings/dconf right now, so it just needs to be doable with gvariants
* vyivel
has no idea what those are
<vyivel>
well you would just have two fields
<vyivel>
step (double) and pointer-speeds (list of doubles)
<orowith2os[m]>
hm. I'm reading the libinput docs and trying to make more sense of it
<orowith2os[m]>
so step is at what point to look for a new value, and the pointer speed would be the element in there that contains the pointer speed
slim has quit [Quit: slim]
<vyivel>
if i understand correctly what you mean then yes
<orowith2os[m]>
with steps [0.0, 1.0, 2.0], and pointer speeds [1.0, 2.0, 3.0], if the physical speed is at one unit/ms, it'll be a speed of 2.0 - and anything less would be 1.0
<orowith2os[m]>
(and if I want more fine-grained control there, it would have to specify things like a step at 0.5 to be a speed of 1.5 units/ms
<vyivel>
okay i'm looking at the libinput source
<vyivel>
(while somewhat sleepy so excuse me possibly incorrect analysis)
<vyivel>
it uses linear interpolation
<vyivel>
so in your example 1.0 device would map to 2.0 pointer
<vyivel>
and say 0.5 device would be 1.5 pointer
<orowith2os[m]>
oh, so I only need to specify the more specific points if I want more of curve, or I can specify less for a straight line
<vyivel>
yep
<orowith2os[m]>
amazing
<orowith2os[m]>
thanks
<vyivel>
yw
glennk has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
<orowith2os[m]>
I understand it even more now. cool
<orowith2os[m]>
libinput_config_accel_set_points(), with the step being physical device units. I can set a smaller step, and more points, for a more precise curve
<orowith2os[m]>
and once it reaches the last one, it straightens out
<orowith2os[m]>
this seems like it'll be super easy to knock out
<orowith2os[m]>
just a bit of duplicated work across different input types