Touchscreen input not honored

[sicelo]

Branch

release/1.4 (stable, AwesomeWM 4.4 parity)

somewm --version output

somewm --version
## somewm version info

**somewm:** 1.4.1 (unknown)
**wlroots:** 0.19
**Lua:** Lua 5.4 (compiled: Lua 5.4.8)
**LGI:** 0.9.2
**Build:** D-Bus=yes, XWayland=yes

**System:**
- Distro: postmarketOS edge
- Kernel: 6.19.0
- Arch: armv7l
- GPU: omapdrm
- Session: wayland (nested: yes)

How did you install somewm?

Distro package (AUR, nixpkgs, etc.)

What happened?

The mouse/cursor cannot be interacted with using the touchscreen

Steps to reproduce

Install somewm on device with touchscreen (resistive touchscreen in my case). Notice all touch input is ignored, e.g. mouse cursor does not move

Expected behavior

Should be possible to use the touchscreen to move the mouse/cursor, e.g. to click the SomeWM menu or interact with applications

Relevant rc.lua

Logs, crash output, or backtrace

libinput list-devices output:

<snip>

Device:                  TSC2005 touchscreen
Kernel:                  /dev/input/event1
Id:                      <unknown>:0000:07d5
Group:                   2
Seat:                    seat0, default
Capabilities:            touch
Tap-to-click:            n/a
Tap-and-drag:            n/a
Tap button map:          n/a
Tap drag lock:           n/a
Left-handed:             n/a
Nat.scrolling:           n/a
Middle emulation:        n/a
Calibration:             1.11 0.00 -0.06 0.00 -1.19 1.08
Scroll methods:          none
Scroll button:           n/a
Scroll button lock:      n/a
Click methods:           none
Clickfinger button map:  n/a
Disable-w-typing:        n/a
Disable-w-trackpointing: n/a
Accel profiles:          n/a
Rotation:                0.0
Area rectangle:          n/a

<snip>

somewm startup log:

00:00:00.011 [INFO] [libseat] [libseat/backend/seatd.c:64] Could not connect to socket /run/seatd.sock: No such file or directory
00:00:00.016 [INFO] [libseat] [libseat/libseat.c:76] Backend 'seatd' failed to open seat, skipping
00:00:00.088 [INFO] [libseat] [libseat/libseat.c:73] Seat opened with backend 'logind'
00:00:00.088 [INFO] [backend/session/session.c:117] Successfully loaded libseat session
00:00:00.117 [INFO] [backend/backend.c:248] Found 1 GPUs
00:00:00.122 [INFO] [backend/drm/backend.c:225] Initializing DRM backend for /dev/dri/card0 (omapdrm)
00:00:00.123 [DEBUG] [backend/drm/drm.c:110] Using atomic DRM interface
00:00:00.123 [DEBUG] [backend/drm/drm.c:131] ADDFB2 modifiers supported
00:00:00.123 [INFO] [backend/drm/drm.c:310] Found 2 DRM CRTCs
00:00:00.132 [INFO] [backend/drm/drm.c:268] Found 3 DRM planes
00:00:00.136 [INFO] [util/env.c:25] Loading WLR_RENDERER option: pixman
00:00:00.136 [INFO] [render/pixman/renderer.c:328] Creating pixman renderer
00:00:00.137 [DEBUG] [render/allocator/allocator.c:142] Trying to create drm dumb allocator
00:00:00.139 [DEBUG] [render/allocator/drm_dumb.c:230] Created DRM dumb allocator
00:00:00.272 [INFO] [../luaa.c:2611] Lua Lua 5.4 initialized
2026-04-30 13:22:34 W: somewm: a_dbus_connect:639: Could not connect to D-Bus session bus: /usr/bin/dbus-launch terminated abnormally without any error message
00:00:00.330 [INFO] [../ipc.c:149] IPC listening on /run/user/10000/somewm-socket
00:00:00.333 [DEBUG] [backend/libinput/backend.c:88] Starting libinput backend
00:00:00.584 [DEBUG] [backend/libinput/events.c:69] Adding TWL4030 Keypad [1:1]
00:00:00.656 [DEBUG] [backend/libinput/events.c:69] Adding TSC2005 touchscreen [0:2005]
00:00:00.657 [DEBUG] [backend/libinput/events.c:69] Adding gpio_keys [1:1]
00:00:00.705 [DEBUG] [backend/libinput/backend.c:125] libinput successfully initialized
00:00:00.707 [INFO] [backend/drm/drm.c:1741] Scanning DRM connectors on /dev/dri/card0
00:00:00.708 [INFO] [backend/drm/drm.c:1796] Found connector 'DPI-1'
00:00:00.709 [INFO] [backend/drm/drm.c:1821] 'DPI-1' connected
00:00:00.710 [DEBUG] [backend/drm/drm.c:1596] Current CRTC: 56
00:00:00.711 [INFO] [backend/drm/drm.c:1610] Detected modes:
00:00:00.712 [INFO] [backend/drm/drm.c:1634]   800x480 @ 57.219 Hz (preferred)
00:00:00.713 [INFO] [backend/drm/drm.c:1671] Physical size: 77x46
00:00:00.714 [ERROR] [backend/drm/util.c:65] Failed to parse EDID
00:00:00.715 [INFO] [backend/drm/drm.c:1796] Found connector 'Composite-1'
00:00:00.716 [INFO] [backend/drm/drm.c:1855] connector DPI-1: Requesting modeset
00:00:00.716 [ERROR] [../somewm.c:1843] [HOTPLUG] createmon: DPI-1 enabled=1 mons=0
00:00:00.716 [DEBUG] [types/output/render.c:123] Attaching empty buffer to output for modeset
00:00:00.716 [DEBUG] [types/output/swapchain.c:27] Choosing primary buffer format XR24 (0x34325258) for output 'DPI-1'
00:00:00.716 [DEBUG] [types/output/swapchain.c:96] Testing swapchain for output 'DPI-1'
00:00:00.716 [DEBUG] [render/swapchain.c:101] Allocating new swapchain buffer
00:00:00.739 [DEBUG] [render/allocator/drm_dumb.c:105] Allocated 800x480 DRM dumb buffer
00:00:00.742 [DEBUG] [render/pixman/renderer.c:186] Created pixman buffer 800x480
00:00:00.745 [INFO] [backend/drm/drm.c:944] connector DPI-1: Modesetting with 800x480 @ 57.219 Hz
00:00:00.755 [DEBUG] [../objects/screen.c:126] screen created: index=1 geometry=0x0+-1+-1
00:00:00.757 [ERROR] [../somewm.c:6273] [HOTPLUG] updatemons geom: DPI-1 0,0 800x480
00:00:00.758 [ERROR] [../somewm.c:6349] [HOTPLUG] updatemons exit selmon=DPI-1
W: /usr/share/somewm/lua/awful/mouse/init.lua:381: invalid cursor left_ptr
2026-04-30 13:22:40 E: awesome: Failed to get list of keyboard groups
00:00:07.051 [INFO] [../luaa.c:4484] loaded config from /home/user/.config/somewm/rc.lua
00:00:09.113 [DEBUG] [xcursor/wlr_xcursor.c:224] Loaded cursor theme 'default' at size 24 (26 available cursors)
00:00:09.114 [DEBUG] [types/output/cursor.c:204] Hardware cursor not supported
00:00:09.115 [DEBUG] [types/output/cursor.c:305] Failed to render cursor buffer
00:00:09.115 [DEBUG] [types/output/cursor.c:424] Falling back to software cursor on output 'DPI-1'
2026-04-30 13:22:43 W: awesome: systray: Failed to connect to session bus: /usr/share/somewm/lua/awful/systray.lua:1038: attempt to index a nil value (local 'b')
00:00:09.220 [DEBUG] [render/swapchain.c:101] Allocating new swapchain buffer
00:00:09.254 [DEBUG] [render/allocator/drm_dumb.c:105] Allocated 800x480 DRM dumb buffer
00:00:09.255 [DEBUG] [render/pixman/renderer.c:186] Created pixman buffer 800x480

Note that wlroots does report the "TSC2005 touchscreen" to somewm. There is no input issue on Sway or Wayfire, which also use wlroots.

Preflight checklist

• I have searched existing issues and this is not a duplicate.
• I have tested with a minimal rc.lua (or rc_fallback.lua) to confirm this is not a bug in my own config.
• I have read CONTRIBUTING.md#branches and selected the correct branch above.

[mps-x]

also touchsreen doesn't work on Samsung chromebook gru-kevin (rk3399) with alpine linux

[sicelo]

Yeah, I looked at wlroots a bit, and found that somewm will need to integrate the wlr_touch family of interfaces, etc. described at https://wlroots.pages.freedesktop.org/wlroots/

[zharsing]

Greetings Folks!

I have implemented a basic proof of concept (mainly for my own use). I own a ThinkPad with touch and pen support, and I was desperate to get browser navigation and Xournal++ working. Here is what I have so far:

https://github.com/zharsing/somewm/tree/touch-input

It is by no means complete and I have other ideas to implement, yet I'd prefer not to roll my own. Can you guide me toward contribution / PRs and friends? Also, please share what you think of it and what you think is missing.

Kind Regards,
Zsolt Harsing

[sicelo]

Nice work! Yeah i think you can open a pull request, which makes it easier to review.

I have other ideas to implement

What are some of the ideas, if you don't mind sharing/discussing?

[zharsing]

Hi Sicelo,

Sorry for the delay, I've been tracking on different threads. I've opened a pull request as suggested.

Background

As of ideas, well, might be misleading a bit, yet having plans would be a bit strong. I was trying to signal that I would like to contribute to SomeWM, even beyond this update. I'd appreciate some guidance, since this is my very first OSS contribution.

I have had a rather superficial look at the current issues and I found a few where I might be able to chip in. I am also experiencing some trouble with my own setup which I want to address at some point.

As of now, when I look at the code, I see high degree of complexity and a lot of (legacy?) technical debt, I still need to spend more time to actually understand the overall architecture, so I'm really just tip-toeing around and trying to pick rather simple tasks.

In Sight

• Work towards supporting wlroots 0.20 #579 Updating the dependency to wlroots 0.20 would be an excellent opportunity to familiarise myself with the landscape.
• Feature Request: input/libinput: support switch devices #519 Since I've been tinkering around libinput devices, this would be rather familiar to work on.
• v2.x Direction: Where my head is at #385 I am contemplating the lua integration and the event delivery, callback plumbing.
• Hot-reload leaks ~90 MB RSS per awesome.restart() #574 Very much interested in the lua vm related memory leak and the relevant lifecycle management. I also have my own issue with the restart. Here is what I found

1. add some nonsense to your rc.lua: awful.input.nonsense = 'value'
2. hit restart -> error!
3. remove the nonsense from rc.lua
4. hit restart -> error?
5. hit restart -> still error?

Not sure whether the code is cached or the Lua VM was not destroyed..

2 Cents

As of my own experience, the behaviour of the client list, focus management, client state management is inconsistent with my expectations. I am coming from AwesomeWM and while it was not perfect either, I have some muscle memory and I can tell its different.

• New clients appear at the left of the client list, instead of the right / end
• Keyboard navigation can break the event handling / target (terminal->select text->browser, paste->switch back on keyboard and click the mouse without moving it = no click, text selection stays)
• Changing display layout (wlr-randr) scatters the clients in inconsistent states
• Full screen mode initiated by the client clears original window state (browser->maximised->youtube->fullscreen->exit = maximised state gone)

Perspective

I'm sure some refactoring would also look really good on the codebase, although its very early for me to commit to such a huge task. Most of the above seems to be somehow connected to the structure of the code.. I don't see where is the main thread to track it all down, although it may be as simple as the main thread and the event loop to begin with. Based on this recent experience, I would have expected the input initializers to be found in input.c, rather than in somewm.c.

Afterthought

Regarding touch events, implementing touch event handling in the SomeWM UI elements is probably better than seeking mouse emulation or controlling the cursor otherwise in an Awesome way. Please see 'The Catch' in my comment for more detail: #612 (comment)

Hope this helps.

[sicelo]

Going Forward

...
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.

I think mouse emulation is expected by the average user. Not saying you must personally work on it, but having started with #612, why not? 😄

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.

Interesting use case. I guess optional emulation is a reasonable compromise, with emulation as default, since I guess more users want/expect this workflow

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?

Seat (and libinput) has always detected the touch device, and reported it to somewm. Just somewm didn't do anything about that report. Anyway, in Wayland ecosystem, the compositor (somewm in this case) is responsible for interaction with input devices. That's why #519 is something that must be handled inside somewm instead of externally, even though this is something AwesomeWM never needed to do.