Touch input

[zharsing]

Description

Basic implementation of touch and pen support (wlr_touch, wlr_tablet, wlr_tablet_tool)

Test Plan

Manual testing

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

❯ git diff lua/awful/input.lua
diff --git a/lua/awful/input.lua b/lua/awful/input.lua
index cc851bf..3a87478 100644
--- a/lua/awful/input.lua
+++ b/lua/awful/input.lua
@@ -37,6 +37,7 @@ local state = {
     accel_profile = nil,            -- "flat", "adaptive"
     accel_speed = 0.0,              -- -1.0 to 1.0
     tap_button_map = nil,           -- "lrm", "lmr"
+    output = nil,           -- "lrm", "lmr"
 
     -- Keyboard settings
     keyboard_repeat_rate = 25,      -- repeats per second
@@ -67,6 +68,7 @@ local property_types = {
     send_events_mode = "string",
     accel_profile = "string",
     accel_speed = "number",
+    output = "string",
     tap_button_map = "string",
     keyboard_repeat_rate = "int",
     keyboard_repeat_delay = "int",
@@ -97,6 +99,7 @@ local pointer_settings = {
     accel_profile = true,
     accel_speed = true,
     tap_button_map = true,
+    output = true,
 }

• Tests pass (make test-unit && make test-integration)

--- FAIL: test-floating-layout.lua (0.62s)
    Log output:
    [nested-inhibitor] outer compositor did not advertise the shortcut inhibitor protocol; host will intercept Mod4 combos
    W: ./lua/awful/mouse/init.lua:379: invalid cursor left_ptr
    2026-06-11 23:58:27 W: awesome: `awful.layout.layouts` was set before `request::default_layouts` could be called. Please use `awful.layout.append_default_layouts` to  avoid this problem
    [0.043] Failed to set locale with LANG: en_GB.UTF-8
    [0.043] Failed to set locale with LANG: en_GB.UTF-8
    [0.042] Failed to set locale with LANG: en_GB.UTF-8
    [0.134] [0.132] Could not move child process into a systemd scope: [Errno 5] Failed to call StartTransientUnit: org.freedesktop.DBus.Error.SpawnCould not move child process into a systemd scope: [Errno 5] Failed to call StartTransientUnit: org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1
    .ChildExited: Process org.freedesktop.systemd1 exited with status 1
    [0.130] Could not move child process into a systemd scope: [Errno 5] Failed to call StartTransientUnit: org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1
    [0.050] Failed to set locale with LANG: en_GB.UTF-8
    [0.123] Could not move child process into a systemd scope: [Errno 5] Failed to call StartTransientUnit: org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1
    Error: running function for step 4/7 (@3): ...ng/projects/github/somewm/tests/test-floating-layout.lua:90: BUG: new client in floating layout was forced to workarea size 1282x722 (workarea 1280x720)
    stack traceback:
    	[C]: in function 'assert'
    	...ng/projects/github/somewm/tests/test-floating-layout.lua:90: in function <...ng/projects/github/somewm/tests/test-floating-layout.lua:81>
    	[C]: in function 'xpcall'
    	/home/zharsing/projects/github/somewm/tests/_runner.lua:160: in function </home/zharsing/projects/github/somewm/tests/_runner.lua:151>
    	[C]: in function 'xpcall'
    	./lua/gears/protected_call.lua:41: in function 'protected_call'
    	./lua/gears/timer.lua:286: in function <./lua/gears/timer.lua:284>!
    NOTE: there were 4 clients left after the test.
    [0.308] [0.311] Could not move child process into a systemd scope: [Errno 5] Failed to call StartTransientUnit: org.freedesktop.DBus.Error.SpawnCould not move child process into a systemd scope: [Errno 5] Failed to call StartTransientUnit: org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1
    .ChildExited: Process org.freedesktop.systemd1 exited with status 1
    [0.306] Could not move child process into a systemd scope: [Errno 5] Failed to call StartTransientUnit: org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1
    [0.192] Could not move child process into a systemd scope: [Errno 5] Failed to call StartTransientUnit: org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1
    [0.195] [glfw error 65544]: Wayland: fatal display error: Connection reset by peer
    [0.309] [0.310] [glfw error 65544]: Wayland: fatal display error: Broken pipe
    [glfw error 65544]: Wayland: fatal display error: Broken pipe
    [0.313] [glfw error 65544]: Wayland: fatal display error: Broken pipe
    ```

[JimmyCozza]

Thanks for this PR @zharsing

Does this address #524 fully?

I don't have my touchscreen laptop set up quite yet so I'll review the code the best I can until I get a chance to actually physically run the branch

[zharsing]

Hi Jimmy,

Thanks for the review, indeed, this does not address the issue in full.

What does this address then?

The PR covers basic 'plumbing', touch and tablet (pen) input device handling with wlroots and event forwarding to capable clients. Also introduces the output property in awful.input.rules to associate input devices with their relevant output devices to map the coordinate spaces.

Whats missing then?

The PR does not cover 'mouse emulation'; translation of touch events to standard pointer/cursor (mouse) movements and/or actions (buttons), gestures, .. etc.

My Background

I use keyboard for the most and TrackPoint with 3 buttons as my pointer device for the majority of the time. I use the touch for navigating 2D document spaces (Xournal++, PDF viewers, browsers) which are typically designed to work with native touch events.

(All I see of SomeWM is a slim bar which I would not try to touch anyway.. :)

My Setup

I have a ThinkPad with Wacom Touch and Pen and a Samsung Android tablet with touch and pen. I connected them together via vkms -> Sunshine -> Artemis to have the tablet function as an external display over WiFi.

History

In the first commit, I have pretty much just 'hacked' it together to make it work SomeHOW; while in the following commit reviewed the device life cycle management, added output mapping for multi screen setup and cleaned up the event handlers to remove unnecessary calls.

Current State

The touch event handling works with clients actually implementing touch handling. The device life cycle is managed, input-to-output mapping is implemented, event handlers hooked.

Going Forward

In order to implement mouse emulation or any cursor interaction, the only place to look (I believe) is the event handlers in input.c:712-892 range of the second commit.

Considering my habits, I am not necessarily the best person to decide what to actually implement, although I'm happy to work on improving this feature.

I would really appreciate 'some' input on what to actually add. While I do have a couple of ideas, I don't really have the capacity to think it through properly, to contemplate what kind of behaviour others might expect.

The Catch

Having the touch controlling the mouse may not always be desirable since its a different category of events. Especially true when working with multiple screens, you don't always want to warp the cursor over to the other, sort of allowing simultaneous access. Right now, I can open 2 instances of Xournal++ - laptop and tablet - and draw on both simultaneously without any interference while the mouse cursor or the focus is not going anywhere from where I left it. The same is true for touch navigation. Its a pretty good feature for me, the emulation must be optional.

By The Way

While I'm writing this response and contemplating the architecture I can't help but think of a third party utility which might just do the remapping of the touch events better than I can ever imagine. Previously, SomeWM did not report touch capability to the seat, yet now it does. I'm not sure, but I have a wild guess about capturing and redelivering translated events might be a thing already implemented somewhere else?

Vision

If I was to go really hardcore on the touch handling, I'd probably want to have highly configurable emulation per input device per output per client.. etc. Such a feature requires very careful design as it can bring about serious latency with high frequency events.

[sicelo]

Thanks so much!

Regarding the mouse emulation, I would just recommend following sway. Anyway, that discussion probably belongs in #524.

[sicelo]

Heh, so I built and tested this on the device mentioned in #524. I can't click anywhere (I guess due to the lacking mouse emulation). Can't bring up menu, etc. However, I can indeed see touch working if I open foot (touch scrolling works) or xournalpp (i can scroll page up and down).

Unfortunately at least for my device, the mouse emulation appears to be necessary. 😄

[shuber2]

@zharsing @sicelo That is interesting work, thank you. I do not have much knowledge on touch devices, however, I have these days worked on a tablet support, see #663.

When looking at your code, I see that you also include the tablet headers. This leads to the following thoughts of mine:

1. If touch support has tablet support as a prerequisite then we should maybe bring feature: Add support for tablet wayland protocol #663 to a merge-level quality first.

2. Likewise for touch, for tablet support I believe it would be good to have it in somewm-1.4 as well, and then migrate it to somewm-2.0, adding additional architectural decisions along this way.

3. The thinking behind feature: Add support for tablet wayland protocol #663 was configuration-first and then the rest followed. (But I also started with a proof-of-concept, to get a gut feeling first, and then did some literature research on sway and xorg.)

4. The implementation was in two stages: A minimum viable version (mouse emulation) and then a full version (pressure, etc.). Maybe this could also be a way to go for the touch support.

What do you think?

[sicelo]

Hi, credit belongs to @zharsing 😄 I didn't write any code for this.

I might be wrong here, but I think touch is a core Wayland protocol, not an add-on, if I could use that terminology, https://wayland.app/protocols/wayland#wl_touch. Thus it is unrelated to tablet-related protocols, although of course touchpads, touchscreens, and tablets might have a lot in common, in general.

But yeah, I don't see a major issue if the two are handled in a combined MR.

[shuber2]

I looked a bit closer, and superficially I think that touch and tablet can be implemented independently. Maybe @zharsing can comment on it.

[sicelo]

Yes, that's what I saw too. There is the issue of pointer emulation, aka. virtual pointer, but that will most likely be handled differently for touchscreens vs. tablets

[zharsing]

@shuber2

Hi Stephan,

Looks like you have done the heavy lifting. I can see the overlap for sure, it seems to me we attacked the same question from opposite directions. I started from the dev branch where the input handling has already been separated and rather retrofitted the absolutely necessary configurations with the least impact on the awesome lua code there is. Also, I was not looking for lua callbacks, just raw event forwarding.

I don't own a tablet pad, just a touch screen with pen, where the pen is considered a tablet tool. All I was dealing with directly maps to wlr_cursor's event handlers. I would associate the tablet pad with the switch device, due to its unique listeners. However also being input devices, might be worth considering an extension of the unified input device lifecycle management rather than adding redundant-looking declarations for each variant. Obviously, the registration has to branch on type, but the teardown can just iterate a list of extra listeners. Addressing tablet tool similarly is probably a viable option. I would also consider adding the related config, instead of running the lookup on the event thread (ie. mouse emulation).

I think the config first approach is a very good idea, especially now we know what we are dealing with. For example, I called it output, you called it map_to_output, while in wlroots its called output_name - sort of hair splitting, yet it might be worth adopting. We have been discussing mouse emulation with @sicelo in this context which is a rather valid concern and it would be great to consider in conjunction with all other input-related settings to avoid Frankenstein-ish outcome. I'm not sure whats the best way to manage such a project here on github, although I'm certainly up for it.

I propose to work together to reconcile the input device management and handling as a single unit of work to ensure consistency. Apart from the configuration and the actual implementation I'd also consider moving the input business from somewm.c to input.c; instead of having a truckload of extern references, just expose init/destroy lifecycle hooks. This does not apply to 1.4, I guess, working from 2.0 to 1.4 is safer as there are way too many things to accidentally hook from somewm.c@1.4.

• Zsolt

[shuber2]

Hey @zharsing , @sicelo,

I have done some work on touch support as a follow up of the tablet support. See the original PR #692. On a Thinkpad Yoga now both, the tablet pen and the touch display, work, e.g., in krita.

Also I tried to streamline discussion on touch support by creating a feature request #707.

What do you think?

--Stefan

p.s. Still thinking about the mouse emulation. It is not part of the implementation yet.