feat(input): apply input rules on tablet and touch devices

[sicelo]

Enable the use of global and per-device input rules on tablet, tablet pad, and touch devices.

Description

Allows applying input rules to the new device classes (tablet, pad, and touch), e.g. to disable a device or set other properties

Test Plan

Tested on-device, touch only. Tablet and pad NOT tested since I do not have access to such a device.

The following $HOME/.config/somewm/rc.lua snippet:

awesome.connect_signal("dpms::on", function(ev)
    awful.input.rules = { { rule = { name = "TSC2005 touchscreen" }, properties = { send_events_mode = "enabled" } }, }
end)

awesome.connect_signal("dpms::off", function(ev)
    awful.input.rules = { { rule = { name = "TSC2005 touchscreen" }, properties = { send_events_mode = "disabled" } }, }
end)

Result
The touchscreen is disabled while the display is off, so interacting with the touchscreen at that point does not wake the display

AI Usage

None

Checklist

• Lua libraries (lua/awful/, lua/gears/, lua/wibox/, lua/naughty/) are not modified — if a bug surfaces in Lua, the fix belongs in C
• Tests pass (make test-unit && make test-integration)

[sicelo]

@shuber2 your review/comment is also important for this one, since it's a follow-up to your tablet and touch patch series

[shuber2]

Ah, interesting. Yes, you address a real gap here. I only have a few seconds and then go for a short vacation trip until Monday, here are a few comments:

• The commit message should say something like current rules are only resolved during touch and tablet events, but apply_input_settings_to_device() was never called, and this function did not handle touch and tablet devices.
• Maybe a comment that tablet pens are not relevant here.
• The example above points to another thing, later relevant for documentation: Setting awful.input.rules is probably not the pattern we want in general, but we need a update-rule-by-name lua pattern.
• I am just thinking about the guard logic here. Is it possible that tracked_touches and friends contain non-libinput devices in the apply_input_settings_to_device() loops? Because the pointer loop has no wlr_libinput_get_device_handle().

Maybe you can look at this? I am back next week.

[sicelo]

Thanks for the review.

commit message should say something like current rules are only resolved during touch and tablet events, but apply_input_settings_to_device() was never called, and this function did not handle touch and tablet devices

As it stands (before this patch), I am quite sure all rules are not applied for the new class of devices. At least they do not take effect on my touchscreen, regardless of how I define them in the config file.

Having looked at the existing code further (after the review), it seems the assumption may have been made that resolve_<type>_settings() makes the settings take effect. It does not. It only evaluates what settings should be in effect when the function is called. Whether those are actually in effect is a different matter, as they only take effect once apply_input_settings_to_device() is called. This is why the rules never applied even though resolve_<type_settings() is called multiple times.

TLDR; I think the commit message is fine.

Maybe a comment that tablet pens are not relevant here

Will add this. I don't have access to tablet and accessories so I am not sure what capabilities really exist and how they could be supported

Relevant for documentation: Setting awful.input.rules is probably not the pattern we want in general, but we need a update-rule-by-name lua pattern

I think this would be better as its own standalone patch. The existing pattern does work and can be discovered intuitively based on the existing documentation, but I can agree that implementing named rules could shorten it.

the guard logic here. Is it possible that tracked_touches and friends contain non-libinput devices in the apply_input_settings_to_device() loops? Because the pointer loop has no wlr_libinput_get_device_handle()

Not very likely afaict, and I believe apply_input_settings_to_device() can handle a NULL device without issues. However, I can and will absolutely add wlr_input_device_is_libinput() safeguards to handle edge cases