Event Filter Config To Rotate Touchscreen Input

Hardware
1

I have tried a few times to set up “event_filter” to rotate the touch input to match the framebuffer rotation, using the “rotate” or “reorient” tags, as described in the README, but without success.

Could someone provide a snippet of a working example of this, which I could use as a starting point.

Thanks!

2

Good point. I would also like to know how to rotate the touchscreen input. Then we could think about how to combine the two, but first one step at a time.

3

Sorry for the late reply. The transformations described in the README are, indeed, very basic. What worked for me with a display resolution of 2160x1440:

  • rotate the by screen 90 degree
  • add <reorient angle=”270” width=”1440” height=”2160”/> to the /config/event_filter

I had to find this by try-and-error using a surrounding <log motion=”yes”> around the <transform> node.

2 Likes
4

Oh, great. I will try it today.

5

That’s a quite valid remark. We should improve the README with the given example.

6

Ok, now it works. I had to rotate the display (using the intel_fb component in Leitzentrale) to 90° and the touchdisplay (using the reorient angle in event_filter) to 270 (or vice versa). I assigned to width and height the values of the rotated display.

Here the modified snippet from my /config/event-filter:

         <transform>
            <input name="usb"/>
            <scale x="0.164" y="0.164"/>
            <reorient angle="270" width="1080" height="1920" />
          </transform>
2 Likes
7

Looking at the implementation and refreshing my knowledge about rotation matrices from Wikipedia, I suspect that the rotation/reorientation is rather implemented as a counter-clockwise rotation. @chelmuth Can you confirm/refute that?

8

IIRC it’s implemented in the mathematical positive sense, i.e., counter-clockwise.

EDIT: The README states the opposite: Rotates clockwise (around origin (0,0) by 90, 180, or 270 degrees in attribute ‘angle’. So, maybe I’m mistaken.

9

I checked the implementation with a small Linux test. My memory is not deceiving me: rotate and reorient operate counter-clockwise.

(  5,  0)  rotate(90)  (  0,  5) ... (  5,  0)  reorient(90, 200, 100)  (199,  5)
(  0,  5)  rotate(90)  ( -5,  0) ... (  0,  5)  reorient(90, 200, 100)  (194,  0)
( 20, 10)  rotate(90)  (-10, 20) ... ( 20, 10)  reorient(90, 200, 100)  (189, 20)

I’ll improve the documentation accordingly.

EDIT: This commit on staging adapts the doc.

2 Likes
10

I’ve been on the road for the past week, so I’m just testing this now, and it worked! Woo Hoo! :tada:

Thanks for the tip! Things are getting interesting in touchscreen world…

11

Let me add a brief explanation for the rotation angle: When the framebuffer has been rotated by 90 degrees clockwise, e.g. using the intel_fb UI in the Leitzentrale, you need to rotate the device counter clockwise in order to compensate the framebuffer rotation. The configuration of the event filter must be seen in relation to the rotation of the device, not the framebuffer. This explains why the reorientation angle must be set to 270 in this example.

3 Likes
12

This doesn’t really advance the discussion, but I would just like to say again how much fun it is to use Sculpt in touch mode on the large screen (including rotation)! (This has been a long-time dream of mine. :partying_face: )

For those who haven’t thought about it, I should also point out that Leitzentrale works really well with touch. The button sizes are perfect, and it avoids right mouse clicks and things like hover, so it translates very cleanly. (I personally wouldn’t mind those things for advanced features, but that would complicate the touch interface.)

Thanks again to all involved!

3 Likes
13

If I would like to write a script that couple the rotation of both (touchinput and display) what would be a good starting point?

14

I think I’d try to use the ROM filter to watch for changes to /config/managed/fb and generate the part of the event filter’s config. I’ve done a very similar thing for dynamic key remapping that you could take as a blueprint.

15

Oh thanks, I will take a look at it. What do you think about the idea of some kind of rotation sensor (or at least some placeholder for it)? Could this be used as an input for both components?

16

Using the builtin accelerometer to determine the device’s orientation would be great. We’re currently lacking any driver of this kind, though. If we had such a driver, the sensed device orientation could for sure be used as an input for rotating the framebuffer and the touch coordinates. Instead of a mere auto-rotating policy, however, I’d be much more in favor of a UI that asks the user to confirm the rotation first since auto-rotation can be quite annoying at times.

17

@nos I just published another Sculpt image with revised touch support (sculpt-pc-2026-03-19-hw). It also comes with a touch_rotate launcher. The latter creates a /config/keyboard/touch.merge file based on the rom_filter config specified at /config/keyboard/touch.config. You’ll find an exemplary config that you can modify to your needs (probably only the input name and the scaling factors). If you are fine with the generated /config/keyboard/touch.merge, you can include it into the merge node of your /config/event_filter.

1 Like
18

Thanks for the continued work on this!

I installed this image, but I don’t see the “touch_rotate” launcher. It should be in “config/launcher”, right?

P.S. I like the background widgets you set up for these images. I need to look at how you set those up. :slight_smile: