00:25 orowith2os[m]: is this an okay place to ask about libinput stuff?
00:25 orowith2os[m]: I'm investigating custom accel profiles in mutter
00:27 vyivel: yes
00:28 orowith2os[m]: okay. Are there any good references for adding custom accel profiles to a compositor? how it's expected to get the curves?
00:28 orowith2os[m]: or is it expected that the compositor sees "custom" and calls a script or something?
00:31 vyivel: libinput_config_accel_set_points()?
00:32 vyivel: so a compositor would take a list of numbers
00:33 orowith2os[m]: hm, like a [double, double]?
00:34 orowith2os[m]: where the first is a point, and the second is a speed for that point and up, until the next point?
00:34 vyivel: afaiu yes
00:34 orowith2os[m]: hm, okay
00:35 vyivel: well the first double is computed as i * step
00:35 vyivel: so you provide a list of speeds
00:35 vyivel: and step to compute points
00:35 orowith2os[m]: I'm uh. a fair bit outside of my comfort zone here. so trying my best to understand
00:35 vyivel: …which is kinda strange api tbh
00:36 orowith2os[m]: I'm trying to think of it like, [(0.0, 1), (1.0, 1.5), (2.0, 3.0)] or something
00:37 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]), …
00:39 orowith2os[m]: hm
00:40 vyivel: okay huh seems like xf86-input-libinput calls that function so maybe could check what user configuration interface it provides
00:41 orowith2os[m]: my brain had the idea of [n].0 is the physical device speed, [n].1 is the speed in software
00:42 vyivel: yep, "The x-axis represents the device-speed in device units per millisecond. The y-axis represents the pointer-speed."
00:42 orowith2os[m]: so would having that as the configuration API in GNOME be okay?
00:42 orowith2os[m]: just an array of tuples containing two doubles?
00:43 vyivel: the first doubles are in steps so they can't be arbitrary
00:44 vyivel: you could like
00:44 vyivel: allow the user to set the step and take a list of pointer-speeds
00:45 vyivel: and then show them the result (which would be a list of tuples)
00:45 orowith2os[m]: this is all in gsettings/dconf right now, so it just needs to be doable with gvariants
00:45 vyivel:has no idea what those are
00:45 vyivel: well you would just have two fields
00:46 vyivel: step (double) and pointer-speeds (list of doubles)
00:52 orowith2os[m]: hm. I'm reading the libinput docs and trying to make more sense of it
00:53 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
00:54 vyivel: if i understand correctly what you mean then yes
00:55 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
00:56 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
00:57 vyivel: okay i'm looking at the libinput source
00:57 vyivel: (while somewhat sleepy so excuse me possibly incorrect analysis)
00:57 vyivel: it uses linear interpolation
00:58 vyivel: so in your example 1.0 device would map to 2.0 pointer
00:58 vyivel: and say 0.5 device would be 1.5 pointer
00:59 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
00:59 vyivel: yep
00:59 orowith2os[m]: amazing
00:59 orowith2os[m]: thanks
01:00 vyivel: yw
01:48 orowith2os[m]: I understand it even more now. cool
01:48 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
01:48 orowith2os[m]: and once it reaches the last one, it straightens out
01:49 orowith2os[m]: this seems like it'll be super easy to knock out
01:49 orowith2os[m]: just a bit of duplicated work across different input types
02:42 orowith2os[m]:sent a code block: https://matrix.org/oftc/media/v1/media/download/Adn5wYhbZlu7YD5-Lsg3WWdJqD_2H_yWI4Njr9-Oi0M6J351ehdoGH5YlKe4cRhaLGYLZKDIIN1fhCcpkqnuWE5CeVbns7dgAG1hdHJpeC5vcmcvUEpMcXJ5ZlV2YllEQXVkY05QeE5vb3Jz
02:42 orowith2os[m]: vyivel: did I describe it well?
03:32 orowith2os[m]: Alright. Some minor wording changes, pushed to gitlab. https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/99
03:32 orowith2os[m]: will do Mutter stuff tomorrow
05:14 wlb: weston Merge request !1694 opened by SophiaG (sophia) desktop-shell: enable app-ids for output https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1694
07:01 wlb: weston/main: Marius Vlad * 5 commits https://gitlab.freedesktop.org/wayland/weston/compare/de6f0b870a95f04836af144bc772f9b3f3b08f56...bfb2dfae6313f2f0adbe8707266444c4633ff17d
07:01 wlb: weston Merge request !1684 merged \o/ (Add experimental VRR support https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1684)
07:18 wlb: weston/main: Théo Maillart * gl-renderer: clip subimage dimensions to its buffer ones https://gitlab.freedesktop.org/wayland/weston/commit/2b69bc08112b libweston/renderer-gl/gl-renderer.c
07:18 wlb: weston Merge request !1692 merged \o/ (gl-renderer: clip subimage dimensions to its buffer ones https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1692)
07:45 vyivel: orowith2os[m]: yeah looks good
09:37 wlb: weston/main: LI Qingwu * ivi-shell: Add desktop surface ping timeout notification https://gitlab.freedesktop.org/wayland/weston/commit/7e941cf6f1cf ivi-shell/ ivi-layout-export.h ivi-layout-private.h ivi-layout-shell.h ivi-layout.c ivi-shell.c
09:37 wlb: weston/main: LI Qingwu * ivi-shell: re-align ivi_layout_interface structure https://gitlab.freedesktop.org/wayland/weston/commit/6d9c42a7d294 ivi-shell/ivi-layout.c
09:37 wlb: weston Merge request !1693 merged \o/ (ivi-shell: Add desktop surface ping timeout notification https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1693)
13:08 wlb: weston Merge request !1695 opened by Marius Vlad (mvlad) terminal: Restore SIGPIPE to default https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1695
13:24 wlb: wayland-protocols/main: Nick Diego Yamane * governance: Add chromium as a member project https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/d5aed4e4903a MEMBERS.md
13:24 wlb: wayland-protocols Merge request !366 merged \o/ (governance: Add chromium as a member project https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/366)
18:31 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?
18:40 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
18:41 llyyr: this channel is for wayland protocol development, not for specific implementations
18:55 ezzieyguywuf: I see
19:49 ezzieyguywuf: (was there a second of all?)
20:48 wlb: wayland Issue #525 closed \o/ (Crash realizing cursor with KDE Plasma after upgrading to wayland-1.23.0 / xwayland-24.1.4 https://gitlab.freedesktop.org/wayland/wayland/-/issues/525)
22:21 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
22:22 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
22:25 riteo: so let's try with wlroots now. It will be way easier to integrate than a protocol sniffer working around libwayland hopefully.