08:42 <pkap> Has anybody else problems with Firefox freezing when clicking on buttons that pop up those small windows?

08:43 <pkap> e.g. clicking on ublock origin or the Downloads button. Latest firefox on Arch Linux.

08:57 <leon-p> works fine on my workstation, FF 98.0.2, river 0.1.3

09:02 <pkap> I'm already on Firefox 99.01. I can't remember if this started after the upgrade though. I'm gonna downgrade Firefox to check

12:46 <novakane> I had some crash with Firefox 99.0 recently but since it was at the same time that I switched to musl from glibc I thought I could have fucked up something

12:47 <novakane> I don't know how to reproduce thm though

15:12 <pkap> Do we want to use the current `riverctl input` command also for keyboard stuff? I implemented `input numlock enabled/disabled` yesterday.

15:12 <pkap> But other keyboard stuff like repeat/delay is a global config.

15:25 <ifreund> pkap: yes, we do but repeat/delay should stay global I think

15:26 <ifreund> each wl_seat only has a single wl_keyboard in the protocol, but we can map multiple physical keyboards to the same logical wl_keyboard exposed to clients

15:26 <pkap> ifreund: What if we would have a wildcard or `all` option to set something for all keyboards?

15:27 <ifreund> repeat/delay is something we send to clients, so I think it's fine to leave that global

15:27 <ifreund> pkap: we probably need a wildcard option yes

15:27 <ifreund> my point was more that you can't configure repeat/delay separately for different physical keyboards on the same seat

15:28 <ifreund> since those are implemented client side and the client only sees a single keyboard

15:28 <pkap> Ah I see! Didn't know that

15:34 <pkap> The current input options are all pointer stuff. These are all configured through libinput directly. The keyboard stuff however would all be configured with libxkbcommon or is abstracted by wlroots I think. Wouldn't it make sense to separate the two somehow?

15:36 <pkap> It wasn't difficult to combine keyboard in the current InputConfig, but still felt a bit awkward?

15:40 <ifreund> no need for abstraction unless there's a concrete benefit too it IMO

15:40 <ifreund> s/too/to

15:41 <ifreund> that said, I haven't looked at the patch yet :D

15:45 <pkap> I just made a PR,  the patch is quite simple actually :)

16:05 <leon-p> hmm... I don't think numlock state fits into the InputConfig abstraction...

16:06 <leon-p> for one, InputConfig was designed for libinput configuration, where "not configured and has arbitrary default" is a valid state (that's what the null is for)

16:06 <leon-p> that doesn't make sense for numlock though, as it's always either on or off and we definitely know the state

16:08 <leon-p> also I personally don't consider numlock state an input device configuration; Changing numlock state is a normal operation during keyboard usage; Just as Shift or Control aren't really configurations.

21:49 <lofilobxik> hi guys!

21:51 <leon-p> hi

21:56 <lofilobxik> sorry to bother, i'm new to wayland and river, but how do you configure libinput devices?

21:56 <lofilobxik> i know in sway there is sway-input, but i cannot find a tool for river

21:56 <leon-p> in riverctl(1) you'll find a section on that

21:57 <leon-p> should be "input configuration"

21:57 <lofilobxik> thanks! i'll check it now