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
mblenc1 has quit [Read error: Connection reset by peer]
nerdopolis has quit [Ping timeout: 480 seconds]
bodiccea_ has joined #wayland
bodiccea has quit [Ping timeout: 480 seconds]
mblenc1 has joined #wayland
mblenc has quit [Read error: Connection reset by peer]
noord has quit [Quit: bye]
noord has joined #wayland
noord has quit []
noord has joined #wayland
mblenc has joined #wayland
yrlf has quit [Ping timeout: 480 seconds]
mblenc1 has quit [Ping timeout: 480 seconds]
bodiccea has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
yrlf has joined #wayland
bodiccea_ has quit [Ping timeout: 480 seconds]
tlwoerner has joined #wayland
yrlf has quit [Ping timeout: 480 seconds]
yrlf has joined #wayland
mblenc has joined #wayland
leonanavi has joined #wayland
leon-anavi has quit [Ping timeout: 480 seconds]
mblenc has quit [Read error: Connection reset by peer]
mblenc has joined #wayland
mblenc1 has joined #wayland
mblenc has quit [Read error: Connection reset by peer]
mblenc has joined #wayland
mblenc1 has quit [Read error: Connection reset by peer]
mblenc has quit [Read error: Connection reset by peer]
mblenc has joined #wayland
mblenc1 has joined #wayland
mblenc has quit [Remote host closed the connection]
FreeFull_ has joined #wayland
mblenc has joined #wayland
FreeFull has quit [Ping timeout: 480 seconds]
mblenc1 has quit [Ping timeout: 480 seconds]
mblenc has quit [Read error: Connection reset by peer]
mblenc has joined #wayland
fossdd has quit [Remote host closed the connection]
fossdd has joined #wayland
pavlushka has quit [Ping timeout: 480 seconds]
leonanavi has quit [Quit: Leaving]
mblenc1 has joined #wayland
mblenc has quit [Read error: Connection reset by peer]
bodiccea_ has joined #wayland
bodiccea has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
d3x0r has joined #wayland
Decker has quit [Read error: Connection reset by peer]
d3x0r is now known as Decker
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
pavlushka has joined #wayland
FreeFull_ has quit []
mblenc has joined #wayland
mblenc1 has quit [Read error: Connection reset by peer]
sewn has quit [Ping timeout: 480 seconds]
Flat_ has joined #wayland
yrlf has quit [Ping timeout: 480 seconds]
sewn has joined #wayland
Flat has quit [Ping timeout: 480 seconds]
yrlf has joined #wayland
iomari891 has joined #wayland
ezzieyguywuf has joined #wayland
<ezzieyguywuf>
I'm trying to play games on wayland - sway is my compositor, and I'm playing the game in proton via steam with dxvk. the game launches, but the framerate is abysmal, e.g. 5 fps or less. how can I go about figuring out what's causing this and hopefully improve it?
mblenc1 has joined #wayland
mblenc has quit [Read error: Connection reset by peer]
<llyyr>
ezzieyguywuf: first of all use the right channel. try another compositor if you think it's sway's fault and ask in #sway if the bug only exists on sway
<llyyr>
this channel is for wayland protocol development, not for specific implementations
iomari891 has quit [Ping timeout: 480 seconds]
<ezzieyguywuf>
I see
yshui_ is now known as yshui
iomari891 has joined #wayland
pavlushka has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
mblenc1 has quit [Read error: Connection reset by peer]
<ezzieyguywuf>
(was there a second of all?)
Brainium has joined #wayland
mblenc1 has joined #wayland
mblenc has quit [Read error: Connection reset by peer]
mblenc1 has quit [Read error: Connection reset by peer]
rasterman has quit [Quit: Gettin' stinky!]
Net147 has quit [Quit: Quit]
Net147 has joined #wayland
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #wayland
mvlad has quit [Remote host closed the connection]
yshui has quit [Remote host closed the connection]
yshui has joined #wayland
sima has quit [Ping timeout: 480 seconds]
<riteo>
Ok, update on the previous discussion on proxying: I still think that it's a very cool idea but I'd need to make yet another thread and that sounds... not exactly ideal, given that the wayland backend already runs in its own thread
<riteo>
the reason for that is that one requirement I forgot about is that it has to be all a single executable and to intercept stuff you have to obviously be in the middle. `poll`ing everything all at once does not work either due to wl_display_roundtrip being its own mini event loop
<riteo>
so let's try with wlroots now. It will be way easier to integrate than a protocol sniffer working around libwayland hopefully.
nerdopolis has joined #wayland
Drakulix has quit [Remote host closed the connection]
Drakulix has joined #wayland
mblenc1 has joined #wayland
mblenc has quit [Read error: Connection reset by peer]