04:49 <leon-p> I wonder if perhaps LibinputDevice in zig-wlroots should be exported and public

04:49 <leon-p> that way I can have functions expect it as a parameter and do the pointer cast only when passing it to c functions.

04:52 <leon-p> although on second though I prefer to @ptrCast only once

05:00 <novakane> ifreund: no more problem in firefox with the last commit :)

05:15 <leon-p> the input configuration thing compiles, now I only need to make it work :P

05:16 <novakane> nah, compiling is enough :P

05:16 <leon-p> I am pretty sure most of it will work already, just some scrolling things are missing and it will only apply to new devices, not already present ones

05:17 <leon-p> oh, and everything keyboard related as well as calibration matrices are not there yet either, but that can be added later.

05:17 <novakane> well if you're just implement tap-to-click that's enough for me :D

05:18 <novakane> can't wait to remove libinput-config hack

05:19 <leon-p> tap is implemented.

05:19 <leon-p> command will be `riverctl input <input-device-identifier> tap enable`

05:20 <novakane> nice!

05:21 <ifreund> I should try writing an input-config-v1 protocol

05:22 <ifreund> the structure can probably mirror wlr-output-management pretty closely

05:22 <ifreund> not input-config-v1, ext-input-management-v1

05:23 <ifreund> leon-p: yeah, the single @ptrCast() approach makes the most sense to me

05:23 <leon-p> would be the nicer solution, but I am not sure if that protocol would gain a lot of traction

05:24 <ifreund> I haven't looked at libinput's API much, would manual bindings be worth it?

05:24 <leon-p> no idea

05:25 <ifreund> why wouldn't it gain traction? I imagine most wlroots-based compositors would support it if I do a good implementation in wlroots

05:25 <leon-p> I think they have something weird going on with having multiple different libinput_device_{type} structs that AFAIAW are never used anywhere, but other than that it's straight forward

05:26 <leon-p> ifreund: because whenever that idea was brought up, the general reaction was "why?"

05:28 <leon-p> do you intent the protocol to just do libinput stuff or also keyboard configuration?

05:28 <ifreund> haven't looked into this in enough detail to be able to answer that

05:31 <leon-p> well I still think the protocol is the better approach, but I'd ask over in #sway-devel if there is any interest in it before starting to work on that

07:08 <leon-p> ifreund: https://paste.rs/nDS

07:08 <leon-p> that is how I would do it

07:09 <leon-p> instead of separating input devices into distinct types, just advertise what capabilities they have

07:10 <leon-p> it should support both clients similar to kanshi as well as graphical configuration things

07:14 <leon-p> damn, was I tricked into designing another protocol? :D

07:19 <novakane> yep you fell right into the trap, time to work on having a commit on wayland :P

19:54 <ifreund> \o/

19:55 <ifreund> I have a lot of university work I'm supposed to get done today, I'll take a look sometime early this week though

22:52 <jaafarrc> Hey, guys.

22:59 <ifreund> o7

22:59 <jaafarrc> How is the freezing issue?

22:59 <ifreund> gone, we have basic damage tracking now

23:01 <jaafarrc> Oh, cool.

23:01 <jaafarrc> But, I've kinda learned to love Sway now.

23:02 <jaafarrc> I don't know how to use Swaybar separately, and Waybar is shit.

23:13 <jaafarrc> Well, it's fine.

23:13 <jaafarrc> I gotta go, now. Cy'all.