0

I got a Raspberry Pi 3 and a 15" touchscreen, using VGA for video (I use a converter to plug into the Pi's HDMI) and and USB for touch capabilities.

Out of the box when I boot up with the device plugged in, the usbtouchscreen module handles the device and creates two inputs: /dev/input/event3 and /dev/input/mouse1. Xorg registers the event3 input and I am able to interact via touch with the system, but not in a way that I'd expect. I cannot click on anything, only move the mouse around. It also does not register the mouse1 input due to no driver found (more details in log outputs below). Touches register mostly everywhere on the screen except for the extreme corners, but the mouse moves back to near the bottom left corner after every touch. When I say near the bottom left corner, I mean about 1/8th of the screen away from the actual corner on both axes. After putting in the Xorg config to swap and invert axes into 10-evdev.conf:

Option "SwapAxes" "1"
Option "InvertY" "1"

The mouse is in the bottom right quadrant. The mouse is also constrained to about 1/2 to 2/3rd of the screen no matter the axis orientation, sort of like a scaling effect. When I click the top left of the screen, the mouse moves to somewhere in the middle of the screen. Same with touching all the other parts of the screen.

I have tried setting Option "Mode" "Relative" in the config, which lets the mouse follow my finger around to anywhere on the screen (so the 0.5x scaling is gone) but it springs back to different locations, progressing and eventually reaching the bottom right corner as "home position" after presses.

I have tried rebuilding the Raspberry Pi 3 kernel with all of the eGalax/EETI options modularized or included:

CONFIG_TOUCHSCREEN_EGALAX=m
CONFIG_TOUCHSCREEN_EETI=m
CONFIG_TOUCHSCREEN_USB_COMPOSITE=m
CONFIG_TOUCHSCREEN_USB_EGALAX=y

Same thing happens as described above.

I have tried following the EETI guide to install their proprietary driver, located at http://www.eeti.com.tw/drivers_Linux.html. I downloaded the eGTouch_v2.5.5814.L-ma file, tweaked the 4 kernel settings they recommended, applied the source code patches for kernel versions 2.6+, and built. When I put the kernel onto my Pi SD and booted, the event3 and mouse1 weren't created because they had me remove usbtouchscreen from the kernel. The guide said I was supposed to see my eGalax touch screen with no handlers (as opposed to mouse1 and event3 I was seeing before) when I ran cat /proc/bus/input/devices but it didn't show up at all. I additionally am not able to interact at all via touch in this setup.

I've tried flashing Raspbian, Ubuntu MATE, and Arch Linux ARM .img's and they all behaved the same way, except for one notable exception. Somewhere in the process of me installing Ubuntu MATE and doing an apt update && apt upgrade as well as an rpi-update, I tested the screen out for the first time since flashing Ubuntu onto the SD and it worked perfectly! This kills me since once I finished upgrading and rebooted, I was never able to reproduce. I tried re-flashing Ubuntu to no avail. I was confident that it would remain so I didn't get any of the log outputs or configuration parameters that made it come up this way.

My theory is that the mouse1 input is what creates clicks, and that is not being registered. According to the Xorg log below:

Adding input device eGalax Inc. USB TouchController (/dev/input/mouse1) No input driver specified, ignoring this device.

I've tried adding /dev/input/mouse1 to 10-evdev.conf with Driver "evdev" but it gives me the following error message: evdev: eGalax Inc. USB TouchController: Unable to query fd: Inappropriate ioctl for device. Sounds like evdev doesn't recognize the input being provided by mouse1. Any other drivers that I can try?

Various log output:

cat /proc/bus/input/devices relevant output:

I: Bus=0003 Vendor=0eef Product=0001 Version=0100
N: Name="eGalax Inc. USB TouchController"
P: Phys=usb-3f980000.usb-1.5/input0
S: Sysfs=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5:1.0/input/input4
U: Uniq=
H: Handlers=mouse1 event3 
B: PROP=0
B: EV=b
B: KEY=400 0 0 0 0 0 0 0 0 0 0
B: ABS=3

ls -l /dev/input/by-id/:

lrwxrwxrwx 1 root root 9 Nov 25 18:09 usb-DELL_DELL_USB_Keyboard-event-kbd -> ../event2
lrwxrwxrwx 1 root root 9 Nov 25 18:53 usb-eGalax_Inc._USB_TouchController-event-if00 -> ../event3
lrwxrwxrwx 1 root root 9 Nov 25 18:09 usb-Logitech_USB_Receiver-event-if01 -> ../event1
lrwxrwxrwx 1 root root 9 Nov 25 18:09 usb-Logitech_USB_Receiver-event-mouse -> ../event0
lrwxrwxrwx 1 root root 9 Nov 25 18:09 usb-Logitech_USB_Receiver-mouse -> ../mouse0

lsusb output:

Bus 001 Device 006: ID 0eef:0001 D-WAV Scientific Co., Ltd eGalax TouchScreen
Bus 001 Device 005: ID 413c:2005 Dell Computer Corp. RT7D50 Keyboard
Bus 001 Device 004: ID 046d:c52f Logitech, Inc. Unifying Receiver
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

usb-devices relevant output:

T:  Bus=01 Lev=02 Prnt=02 Port=04 Cnt=04 Dev#=  6 Spd=1.5 MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0eef ProdID=0001 Rev=01.00
S:  Manufacturer=eGalax Inc.
S:  Product=USB TouchController
C:  #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=usbtouchscreen

ls /dev/input:

by-id
by-path
event0
event1
event2
event3
mice
mouse0
mouse1

Xorg.0.log relevant output:

[    51.878] (II) config/udev: Adding input device eGalax Inc. USB TouchController (/dev/input/event3)
[    51.879] (**) eGalax Inc. USB TouchController: Applying InputClass "evdev touchscreen catchall"
[    51.879] (II) Using input driver 'evdev' for 'eGalax Inc. USB TouchController'
[    51.879] (**) eGalax Inc. USB TouchController: always reports core events
[    51.879] (**) evdev: eGalax Inc. USB TouchController: Device: "/dev/input/event3"
[    51.879] (--) evdev: eGalax Inc. USB TouchController: Vendor 0xeef Product 0x1
[    51.879] (--) evdev: eGalax Inc. USB TouchController: Found absolute axes
[    51.879] (--) evdev: eGalax Inc. USB TouchController: Found x and y absolute axes
[    51.879] (--) evdev: eGalax Inc. USB TouchController: Found absolute touchscreen
[    51.879] (II) evdev: eGalax Inc. USB TouchController: Configuring as touchscreen
[    51.879] (**) evdev: eGalax Inc. USB TouchController: YAxisMapping: buttons 4 and 5
[    51.879] (**) evdev: eGalax Inc. USB TouchController: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
[    51.879] (**) Option "config_info" "udev:/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5:1.0/input/input3/event3"
[    51.879] (II) XINPUT: Adding extended input device "eGalax Inc. USB TouchController" (type: TOUCHSCREEN, id 9)
[    51.879] (II) evdev: eGalax Inc. USB TouchController: initialized for absolute axes.
[    51.880] (**) eGalax Inc. USB TouchController: (accel) keeping acceleration scheme 1
[    51.880] (**) eGalax Inc. USB TouchController: (accel) acceleration profile 0
[    51.880] (**) eGalax Inc. USB TouchController: (accel) acceleration factor: 2.000
[    51.880] (**) eGalax Inc. USB TouchController: (accel) acceleration threshold: 4
[    51.881] (II) config/udev: Adding input device eGalax Inc. USB TouchController (/dev/input/mouse1)
[    51.881] (II) No input driver specified, ignoring this device.
[    51.881] (II) This device may have been added with another device file.
[  2310.541] (II) config/udev: removing device eGalax Inc. USB TouchController
[  2310.573] (II) evdev: eGalax Inc. USB TouchController: Close
[  2310.574] (II) UnloadModule: "evdev"

dmesg relevant output:

[    4.845962] input: eGalax Inc. USB TouchController as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5:1.0/input/input3
[    4.846690] usbcore: registered new interface driver usbtouchscreen

10-evdev.conf relevant lines:

Section "InputClass"
        Identifier "evdev touchscreen catchall"
        MatchIsTouchscreen "on"
        MatchDevicePath "/dev/input/event*"
    Option "SwapAxes" "1"
    Option "InvertY" "1"
        Driver "evdev"
EndSection

If you've read this far, thank you! I figured more info is better than less. Appreciate any pointers.

Improve this question
2
  • The first step is to go back to the usbtouchscreen driver, use evtest /dev/input/event3 (actual path may change, make sure you use the current one, or use dev/input/by-id) and see what kind of events you get, and what happens after the click that makes it spring back to the old location. Does dmesg mention a HID or HIDRAW device?
    – dirkt
    Commented Jan 20, 2017 at 16:25
  • Running evtest/xinput test reveals a jitter that the mouse takes on, sometimes when I'm not touching the screen even. The a[0] (axis 0, or X-axis) switches between 1703 and 1704 randomly. Sometimes it goes silent but when I touch the screen it always pulls back to there. This changes depending on my axis inversion/swap settings. The only mentions of hid/hidraw in dmesg are my Logitech USB receiver (twice) and my Dell USB Keyboard. I also should mention, I'm not able to click on the screen. Can only move the mouse.
    – Ashish Narasimham
    Commented Jan 21, 2017 at 2:25

1 Answer 1

Reset to default
1

I first thought the issue was that the USB wire being reversed made the monitor work, but it turns out the display moves around inside of the display's housing. It moved just enough to start working when I flipped the USB wire's ends. Very finicky monitor.

Improve this answer
4
  • Now the interesting question is how you got the effect you described from reversing the cable. With a normal host-device cable, something like this can't happen. Maybe an OTG port is involved somehow.
    – dirkt
    Commented Jan 21, 2017 at 11:09
  • Yeah that's why I didn't try this for so long - thought the cable was identical both ways. However it has what I just learned to be a ferrite core close to one end of it, like this: slate.com/blogs/browbeat/2012/11/01/… Not sure if that has anything to do with the asymmetry.
    – Ashish Narasimham
    Commented Jan 21, 2017 at 19:59
  • Nope, a ferrite core is just for EM noise reduction. OTG ports have an extra pin, so different cables can be used to switch it between host/peripheral mode. Have you looked at the pins in the plugs? (I'm just curious, that's the first time I've ever heard of such a behaviour caused by reversing a cable).
    – dirkt
    Commented Jan 21, 2017 at 20:07
  • 1
    Ok, so I figured out the real issue. Flipping the USB was a confounding factor, but the problem is that the monitor is a budget monitor and the actual screen moves around inside of the monitor's housing. While reversing the cable I must have moved the monitor around into a position in which it worked. I transported the monitor to a different location and it ended up doing the same thing. Looks like it's time for a return.
    – Ashish Narasimham
    Commented Jan 22, 2017 at 20:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .