00:02 whot: bl4ckb0ne: I don't think it's a good fit tbh
00:03 whot: bl4ckb0ne: whatever joysticks need is probably something else (in addition to?) libinput, but I don't have enough experience with the details to really scope that
00:08 bl4ckb0ne: ill start a new project and see how it goes
00:19 whot: bl4ckb0ne: what's the specific issue you're trying to address with that, that's the main question. because there are a few issues around joysticks that are all related but also somewhat orthogonal (fd forwarding, identification, conversion of events, etc.)
00:20 whot: bl4ckb0ne: and unlike libinput where we were mostly guaranteed to be useful immediately a potential libjoystick suffers from the drawback that nothing will use it and the backwards compat pieces already in place will be used for approximately forever
00:21 whot: bl4ckb0ne: and adding joystick support to libinput to move the pointer around was enough of a niche case that I never wanted it, plus it would then also require the negotation of when to ignore the device (because a game currently uses it)
00:23 whot: kennylevinsen: luckily I'm in the wrong TZ so there are few buses around when I'm awake :)
00:41 bl4ckb0ne: my goal is some boilerplate for the joystick protocol im working on
00:46 bl4ckb0ne: what are the backward compat pieces you're talking about?
00:46 whot: SDL basically
00:50 bl4ckb0ne: yeah thats a big piece
02:15 riteo: hi!
02:15 riteo: I'm implementing fractional scaling in godot and the specs says that sizes must be half rounded away from 0
02:16 riteo: that sounds nice and all, but what about converting from a scaled to a logical size?
02:16 riteo: like, do I do round(scaled_size / scale_factor) or do I just blindly divide and truncate the result?
02:17 riteo: from some dumb experimentation using the python REPL as a calculator it looks like that the decimal result is always under 5 when this happens, but I have no hard proofs about that
04:20 riteo: well I'll go for now but as usual I'll read the logs if someone wants to help me, byeeeee!
07:34 orowith2os[m]: It has been attempted https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3205
08:01 kennylevinsen: riteo: The "primary" dimensions are the logical one, so you should generally only need to go logical -> "physical".
08:01 kennylevinsen: IIRC, it was found that it is possible to convert back assuming proper rounding is applied in both direction
13:30 ShapeShifter499: hi
13:34 ShapeShifter499: it's been a while since I last posted any PRs. libinput still requires tablet files from libwacom for proper device support correct?
13:35 ShapeShifter499: I'm just now realizing I should make and test a '.tablet' file to see if palm rejection occurs properly
13:35 ShapeShifter499: for my device
16:39 ShapeShifter499: I'll wait for more help, the tablet file did not help solve the hand rejection
17:04 riteo: kennylevinsen: regarding the monodirectionality of conversion, that's not doable with godot as due to the way that it works we must convert the user-facing windowing requests from "godot-space" to "wayland-space", where the former is pretty much local to the buffer and the latter to the surface
17:10 riteo: uh so I should round both for scaling and unscaling
17:20 riteo: I'm not actually that sure about rounding both ways
17:20 riteo: I mean it should in theory have the same result
17:25 kennylevinsen: riteo: well the "wayland-space" is the primary space, and must dictate the window dimensions. You cannot take arbitrary scaled dimensions and assume they will convert back.
17:28 riteo: I see
17:28 kennylevinsen: E.g. at scales between 1.25 and 1.5 you can have 1 or 3 pixel wide buffer, never 2 pixel wide
17:28 riteo: The conversion isn't used for window size though
17:29 kennylevinsen: You will get incorrect representation (stretched or squeezed) if you convert such "wrong" dimensions
17:29 kennylevinsen: What then?
17:29 riteo: instead for stuff like "pointer_set_hint"
17:29 riteo: and actually... Only that? I'm currently looking in the code and it's the only instance of `/=` lol
17:30 kennylevinsen: I mean if it's just for an offset into your buffer, whatever
17:30 riteo: lmao it indeed looks like it's the only scaled->logical conversion done in the entire wayland thread helper
17:31 riteo: soooo... I shouldn't even bother?
17:31 kennylevinsen: If it is taking input from a Wayland pointer, then the original source is logical pixels
17:32 riteo: it isn't, it's just a way to let the godot part ask to set the pointer hint for when it's hidden
17:32 kennylevinsen: But yeah not the end of the world, just make sure it's calculated as doubles and rounded to not make things too bad
17:32 riteo: oh I should calculate as doubles? I think that I did everything in floats for some reason
17:34 riteo: I didn't think this stuff required that much precision
17:53 kennylevinsen: it's rather that floats have terrible precision
17:59 immibis: floats have 24-bit precision which is not terrible
17:59 immibis: doubles have 53-bit precision
17:59 immibis: if your screen is 4096 pixels wide (12 bits) then floats are accurate to 1/4096 of a pixel (another 12 bits)
18:18 riteo: so, should I switch my logic to doubles?
18:18 riteo: (sorry for the delay)
18:27 riteo: eh, I suppose it wouldn't hurt
18:49 riteo: well, I think I'll go. I'll round that one silly conversion and switch to doubles because it doesn't hurt. As usual, thanks a lot folks!
18:49 riteo: Byeeeeeeeeeee!
18:52 kennylevinsen: immibis: float is bad once you start doing fractional math that depend on correct rounding
18:53 kennylevinsen: On an absolute scale they are of course extremel close to the real value, but being infinitesimally off can mean rounding in the wrong direction
22:39 orowith2os[m]: emersion: do you have a minute to update and address https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18268 ?