16:46 <lordmzte> Hello! I have an external touch display connected to my laptop, but the touch inputs map to both my laptop's screen as well as the display, instead of just the display. Does river support correctly mapping touch input here?

16:48 <lordmzte> Oh, the display's name according to wlr-randr is also "DO NOT USE - RTK CX156A 0x00000001 (DP-1)", but that's probably just because nvidia, I assume.

16:49 <ifreund> lordmzte: no, not yet sadly but Ive already got an issue open for that in the 0.3.0 milestone

16:49 <lordmzte> Yea I thought so, saw that one.

16:50 <ifreund> wlroots has the API for that, should just be some glue code in river and a new riverctl command

16:50 <lordmzte> Oh neat! I might be able to contribute, although I've only wrtten (a decent amount of) client-side wayland code.

16:51 <lordmzte> Will we simply have a device -> output mapping, or will it work using a transformation matrix?

16:56 <vyivel> there's wlr_cursor_map_input_to_output()

16:56 <lordmzte> ah

16:57 <vyivel> also to_region() (though the name is a lie and it maps to a box instead)

19:28 <lordmzte> I haven't read any code yet, but I might give touch pad mapping a shot later on: one question: how would a hypothetical `map-input-to-output` command identify inputs? Outputs have names (I assume), but what about inputs (as in `wlr_input_device`)? Do they have names to identify them by, and is there a protocol river implements to query them?

19:29 <lordmzte> I think the command would, for example, be invoked as `riverctl map-input-to-output ??? DP-1`.

19:29 <leon-p> InputDevice.identifier

19:30 <leon-p> after also I think we can put this into the input command

19:30 <leon-p> riverctl input pointer-* map-to-output HDMI-A-1

19:30 <leon-p> InputConfig would need a new field

19:30 <lordmzte> Oh nice! Wasn't even aware of those commands!

19:31 <leon-p> note that you'll need to store the identifier as string in the InputConfig, since the output may not exist on command invocation

19:31 <leon-p> you'll probably want to base it on #959

19:34 <lordmzte> Oh right, I saw that PR. How close do you think it is to being merged? Does it make sense to start work before we get that in, or should big changes still be expected?

19:37 <lordmzte> leon-p: I assume I should store it as a string so that the mapping can be declared to an output that doesn't yet exist, and then be able to apply it once an output with the configured name is connected?

19:38 <leon-p> yeah, that was what I had in mind

19:38 <leon-p> the PR is finished as far as I am concerned

19:40 <lordmzte> I'd also have to undo the mapping then when the output is disconnected (unless wlr does everything already). What would be the function to "undo" a `wlr_cursor_map_input_to_output`? Doesn't seem like there's a function in wlr_cursor.

19:43 <leon-p> 🤷

19:43 <leon-p> not familiar with any of that

19:43 <leon-p> I actually it'll undo itself as far as wlroots internals are concerned

19:46 <lordmzte> Seems like `wlr_cursor_map_input_to_output` just sets a field in the input dev. I guess wlr clears it when the output disconnects

19:52 <lordmzte> The docs that `river --help` prints for the -c parameter kinda sucks, it doesn't mention that it runs that INSTEAD of the init exe

19:52 <leon-p> send a PR

19:52 <lordmzte> on it!

20:00 <lordmzte> PR is out; #990

20:02 <lordmzte> seems like CI is broken :P