Multiple clicks with touchscreen

[Peter Hutterer]

On Thu, Aug 11, 2011 at 12:06:30AM -0500, Kerrick Staley wrote:
> Basically, what I would like to do is prevent input events from my
> touchscreen from appearing on /dev/input/mice.
> 
> I have a dual-head setup with a regular screen (built into my laptop) on the
> left and a touchscreen on the right. When the touchscreen is touched, it
> registers two clicks; this is undesirable. From what I can find in forums,
> etc., the issue is that input events appear on both /dev/input/mice and
> /dev/input/mouse0. Indeed, when the touchscreen is touched, both devices
> show activity.
> 
> Earlier, the multiple-click issue did not occur, but there was another
> issue: touchscreen events did not occur in the correct spot (they were
> spread across both monitors). I fixed this using
> $ xinput set-prop "QUANTA OpticalTouchScreen" --type=float "Coordinate
> Transformation Matrix" 0.53333333 0 0.46666666667 0 1 0 0 0 1
> n.b. The touchscreen is a HP Compaq L2105tm, which uses a touch sensor
> manufactured by Quanta. The screen is 1920x1080 and is sitting to the right
> of the laptop, which has a 1680x1050 display, so the transformation matrix
> is correct.
> 
> Now that the touchscreen is properly calibrated, there are two clicks: one
> in the correct spot, and one in the original spot (where it clicked before I
> invoked xinput; this location corresponds to an identity transformation
> matrix).
> 
> How can I fix this issue? I found 3 separate solutions, none of which worked
> for me:
> 
> 1. Disable /dev/input/mice, as described at
> http://www.conan.de/touchscreen/evtouch.html
> -There is no ServerLayout section in my xorg.conf. The dual-head layout is
> configured dynamically by Gnome 3 when I log in or when the monitor is
> attached; I'll eventually configure ivman or similar to automatically invoke
> xinput when the display is attached.
> -As I understand it, this will prevent the mouse (a TrackPoint) from
> working; the mouse is needed for the regular display.
> 
> 2. Patch the driver, per
> http://www.linuxquestions.org/questions/linux-desktop-74/hal-vs-xserver-dev-input-mice-convincing-x-to-*not*-use-a-given-input-device-697802/#post3415561
> -I don't know where in the driver I should insert this code; plus, the
> driver is part of the kernel (module hid-quanta), so I'd have to recompile
> my kernel.
> 
> 3. Write a HAL rule, per
> http://www.linuxquestions.org/questions/linux-desktop-74/hal-vs-xserver-dev-input-mice-convincing-x-to-*not*-use-a-given-input-device-697802/#post3625659
> -I tried this, and it didn't work. I used <match key="info.product"
> contains="OpticalTouchScreen">, but I'm not sure if this is correct.
> 
> I'm running X.Org 1.10.3.901 (1.10.4 RC 1) on Linux 3.0 (the distribution is
> Arch Linux). If there is any additional information needed (log output,
> etc.), please ask.

I'm not sure why /dev/input/mice is even picked up, all our default rules
ignore it. Do you have any rules that add it?

3ou're most likely using udev, not HAL so solution 3 won't work. the
xorg.conf.d equivalent to the now-deprecated HAL solution is:
https://fedoraproject.org/wiki/Input_device_configuration#Blacklisting_a_device

Cheers,
  Peter