New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better touchscreen detection? #108

Closed
craftyguy opened this Issue Sep 19, 2017 · 20 comments

Comments

Projects
None yet
3 participants
@craftyguy

craftyguy commented Sep 19, 2017

Hi! I know tslib looks for touchscreen devices in some pre-set location (e.g. /dev/input/touchscreen), but I'm wondering if there's a better way to do this.. such as scanning devices for supported EV_* and ABS_* events?

My use case of tslib involves using this library in initramfs, where devices are added by mdev (not udev), and there seems to be way to write mdev rules but when trying to support multiple system types that all have different touchscreen hardware this can be a bit cumbersome to write custom rules for each. Note that this isn't super critical or urgent, we're getting by OK by manually setting TSLIB_TSDEVICE for systems that do not have their touchscreen device initialized to /dev/input/event0. This is merely a questions as to whether there might be a better way to automatically detect these devices in tslib. Thanks!

@merge

This comment has been minimized.

Show comment
Hide comment
@merge

merge Sep 19, 2017

Collaborator

We can think about it and I'll leave the issue open. It's not on my priority list though. ts_setup() could do something similar to what X11 does in finding touchscreens. That said I think people who build systems should implement known, persistent event device file names in some way or another.

You might not even need to set TSLIB_TSDEVICE. If you use ts_setup() at least. Otherwise it's up to programs to use it. In case TSLIB_TSDEVICE is not set, ts_setup() tries, in the following order:

"/dev/input/ts",
"/dev/input/touchscreen",
"/dev/input/event0",

I think you're not the first one to ask this, so let's see.

Collaborator

merge commented Sep 19, 2017

We can think about it and I'll leave the issue open. It's not on my priority list though. ts_setup() could do something similar to what X11 does in finding touchscreens. That said I think people who build systems should implement known, persistent event device file names in some way or another.

You might not even need to set TSLIB_TSDEVICE. If you use ts_setup() at least. Otherwise it's up to programs to use it. In case TSLIB_TSDEVICE is not set, ts_setup() tries, in the following order:

"/dev/input/ts",
"/dev/input/touchscreen",
"/dev/input/event0",

I think you're not the first one to ask this, so let's see.

@merge merge added the question label Sep 19, 2017

@craftyguy

This comment has been minimized.

Show comment
Hide comment
@craftyguy

craftyguy Sep 19, 2017

Right, but ts_setup() only looks for the touchscreen at the locations you've noted right? For instance if it's located at /dev/input/event1, it would not 'see' it?

Totally understand about this not being a priority for you, that's fine. I just wanted to kick around the idea a bit to see if something like this 'more advanced detection' is even possible :)

craftyguy commented Sep 19, 2017

Right, but ts_setup() only looks for the touchscreen at the locations you've noted right? For instance if it's located at /dev/input/event1, it would not 'see' it?

Totally understand about this not being a priority for you, that's fine. I just wanted to kick around the idea a bit to see if something like this 'more advanced detection' is even possible :)

@merge

This comment has been minimized.

Show comment
Hide comment
@merge

merge Sep 19, 2017

Collaborator

sure it 's possible :) Anybody could write it and it'd have a good chance of getting in, if it doesn't break anything.

yes. ts_setup() coincidently looks for /dev/input/event0 specifically.

Collaborator

merge commented Sep 19, 2017

sure it 's possible :) Anybody could write it and it'd have a good chance of getting in, if it doesn't break anything.

yes. ts_setup() coincidently looks for /dev/input/event0 specifically.

@merge

This comment has been minimized.

Show comment
Hide comment
@merge

merge Oct 24, 2017

Collaborator

One problem is that we don't want Linux specific code in our core.

Looking roughly at what udev does, see https://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-input_id.c it's not too fancy:

if we have either the BTN_TOUCH or INPUT_PROP_DIRECT bit, we are a touchscreen. I wonder if that's even accurate to say. btn_touch is often no there anymore, and prop_direct might be missing in the driver, but ok, it should be there.

So: Actually that should be our check in check_fd() of our input module I guess. Let's see if we can support this already, but I think so.

But as for detection during ts_setup() we would make it Linux-dependent and portable, but it looks doable to do somethink like this:

  1. user file
  2. TSLIB_TSDEVICE
  3. /dev/input/ts
  4. /dev/input/touchscreen
  5. starting with /dev/input/event0 open all device files and take the first one that matches.
Collaborator

merge commented Oct 24, 2017

One problem is that we don't want Linux specific code in our core.

Looking roughly at what udev does, see https://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-input_id.c it's not too fancy:

if we have either the BTN_TOUCH or INPUT_PROP_DIRECT bit, we are a touchscreen. I wonder if that's even accurate to say. btn_touch is often no there anymore, and prop_direct might be missing in the driver, but ok, it should be there.

So: Actually that should be our check in check_fd() of our input module I guess. Let's see if we can support this already, but I think so.

But as for detection during ts_setup() we would make it Linux-dependent and portable, but it looks doable to do somethink like this:

  1. user file
  2. TSLIB_TSDEVICE
  3. /dev/input/ts
  4. /dev/input/touchscreen
  5. starting with /dev/input/event0 open all device files and take the first one that matches.

@merge merge added the improvement label Oct 24, 2017

@merge merge added this to the 2.0 milestone Oct 24, 2017

@merge

This comment has been minimized.

Show comment
Hide comment
@merge

merge Oct 25, 2017

Collaborator

some useful code from evemu. All #if LINUX:

#include <dirent.h>
#include <stdio.h>

#define DEV_INPUT_EVENT "/dev/input"
#define EVENT_DEV_NAME "event"

static int is_event_device(const struct dirent *dir) {
	return strncmp(EVENT_DEV_NAME, dir->d_name, 5) == 0;
}

static char* scan_devices(void)
{
	struct dirent **namelist;
	int i, ndev, devnum;
	char *filename;
        int is_touchscreen = 0;

	ndev = scandir(DEV_INPUT_EVENT, &namelist, is_event_device, alphasort);
	if (ndev <= 0)
		return NULL;

	for (i = 0; i < ndev; i++)
	{
		char fname[64];
		int fd = -1;

		snprintf(fname, sizeof(fname),
			 "%s/%s", DEV_INPUT_EVENT, namelist[i]->d_name);
		fd = open(fname, O_RDONLY);
		if (fd < 0)
			continue;
          /* check for BTN_TOUCH or PROP_DIRECT and set is_touchscreen */
		ioctl(fd, EVIOCGNAME(sizeof(name)), name);

		close(fd);
		free(namelist[i]);

                if (is_touchscreen) {
	                asprintf(&filename, "%s/%s%d",
		                 DEV_INPUT_EVENT, EVENT_DEV_NAME,
		                 i);

	                return filename;
                }
	}
}
Collaborator

merge commented Oct 25, 2017

some useful code from evemu. All #if LINUX:

#include <dirent.h>
#include <stdio.h>

#define DEV_INPUT_EVENT "/dev/input"
#define EVENT_DEV_NAME "event"

static int is_event_device(const struct dirent *dir) {
	return strncmp(EVENT_DEV_NAME, dir->d_name, 5) == 0;
}

static char* scan_devices(void)
{
	struct dirent **namelist;
	int i, ndev, devnum;
	char *filename;
        int is_touchscreen = 0;

	ndev = scandir(DEV_INPUT_EVENT, &namelist, is_event_device, alphasort);
	if (ndev <= 0)
		return NULL;

	for (i = 0; i < ndev; i++)
	{
		char fname[64];
		int fd = -1;

		snprintf(fname, sizeof(fname),
			 "%s/%s", DEV_INPUT_EVENT, namelist[i]->d_name);
		fd = open(fname, O_RDONLY);
		if (fd < 0)
			continue;
          /* check for BTN_TOUCH or PROP_DIRECT and set is_touchscreen */
		ioctl(fd, EVIOCGNAME(sizeof(name)), name);

		close(fd);
		free(namelist[i]);

                if (is_touchscreen) {
	                asprintf(&filename, "%s/%s%d",
		                 DEV_INPUT_EVENT, EVENT_DEV_NAME,
		                 i);

	                return filename;
                }
	}
}

@merge merge self-assigned this Oct 25, 2017

@merge merge removed the question label Oct 25, 2017

@merge

This comment has been minimized.

Show comment
Hide comment
@merge

merge Oct 26, 2017

Collaborator

There is a feature branch you could test now. Note that the ts_uinput daemon doesn't use it yet

Collaborator

merge commented Oct 26, 2017

There is a feature branch you could test now. Note that the ts_uinput daemon doesn't use it yet

@merge merge closed this in 58e2ef4 Oct 31, 2017

@craftyguy

This comment has been minimized.

Show comment
Hide comment
@craftyguy

craftyguy Oct 31, 2017

@merge wow, thanks! I'll test this out in the next couple of days. Sorry for the delay. I really appreciate the work you put into adding this!

craftyguy commented Oct 31, 2017

@merge wow, thanks! I'll test this out in the next couple of days. Sorry for the delay. I really appreciate the work you put into adding this!

@merge

This comment has been minimized.

Show comment
Hide comment
@merge

merge Oct 31, 2017

Collaborator

no rush, but any testing feedback is always welcome. everything the tslib package ships should now have touchscreen discovery, and it'llbe part of the next release.

Collaborator

merge commented Oct 31, 2017

no rush, but any testing feedback is always welcome. everything the tslib package ships should now have touchscreen discovery, and it'llbe part of the next release.

@merge

This comment has been minimized.

Show comment
Hide comment
@merge

merge Nov 6, 2017

Collaborator

1.14-rc2 should be pretty safe to use and hopefully almost identically to the release. Are you able to do a test run, maybe verifying device detection (if TSLIB_TSDEVICE or symlinks in /dev/input/ are not set)?

Collaborator

merge commented Nov 6, 2017

1.14-rc2 should be pretty safe to use and hopefully almost identically to the release. Are you able to do a test run, maybe verifying device detection (if TSLIB_TSDEVICE or symlinks in /dev/input/ are not set)?

@craftyguy

This comment has been minimized.

Show comment
Hide comment
@craftyguy

craftyguy Nov 7, 2017

@merge really sorry for the delay in testing this out.

I'm not sure if my test is valid, ts_test should be triggering ts_setup, which should then try to detect the touchscreen device, correct? I see, with strace, that it is opening all of the eventX devices but the application (ts_test) still fails.

For reference, /dev/input/event3 is my actual touchscreen device.

localhost:/home/user# strace ts_test
....

open("/dev/input/ts", O_RDWR|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/dev/input/touchscreen", O_RDWR|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/dev/touchscreen/ucb1x00", O_RDWR|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/dev/input", O_RDONLY|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
getdents64(3, /* 13 entries */, 2048)   = 384
getdents64(3, /* 0 entries */, 2048)    = 0
close(3)                                = 0
open("/dev/input/event0", O_RDONLY|O_LARGEFILE) = 3
ioctl(3, EVIOCGPROP(4), [ 0 ])          = 4
open("/dev/input/event1", O_RDONLY|O_LARGEFILE) = 4
ioctl(4, EVIOCGPROP(4), [ 0 ])          = 4
open("/dev/input/event2", O_RDONLY|O_LARGEFILE) = 5
ioctl(5, EVIOCGPROP(4), [ 0 ])          = 4
open("/dev/input/event3", O_RDONLY|O_LARGEFILE) = 6
ioctl(6, EVIOCGPROP(4), [ 0 ])          = 4
open("/dev/input/event4", O_RDONLY|O_LARGEFILE) = 7
ioctl(7, EVIOCGPROP(4), [ 0 ])          = 4
open("/dev/input/event5", O_RDONLY|O_LARGEFILE) = 8
ioctl(8, EVIOCGPROP(4), [ 0 ])          = 4
open("/dev/input/event6", O_RDONLY|O_LARGEFILE) = 9
ioctl(9, EVIOCGPROP(4), [ 0 ])          = 4
writev(2, [{iov_base="", iov_len=0}, {iov_base="ts_open", iov_len=7}], 2ts_open) = 7
writev(2, [{iov_base="", iov_len=0}, {iov_base=":", iov_len=1}], 2:) = 1
writev(2, [{iov_base="", iov_len=0}, {iov_base=" ", iov_len=1}], 2 ) = 1
writev(2, [{iov_base="", iov_len=0}, {iov_base="No such file or directory", iov_len=25}], 2No such file or directory) = 25
writev(2, [{iov_base="", iov_len=0}, {iov_base="\n", iov_len=1}], 2
) = 1
exit_group(1)                           = ?
+++ exited with 1 +++
localhost:/home/user# ls /dev/input/
by-path  event0   event1   event2   event3   event4   event5   event6   js0      mice     mouse0
localhost:/home/user# ts_test
ts_open: No such file or directory

craftyguy commented Nov 7, 2017

@merge really sorry for the delay in testing this out.

I'm not sure if my test is valid, ts_test should be triggering ts_setup, which should then try to detect the touchscreen device, correct? I see, with strace, that it is opening all of the eventX devices but the application (ts_test) still fails.

For reference, /dev/input/event3 is my actual touchscreen device.

localhost:/home/user# strace ts_test
....

open("/dev/input/ts", O_RDWR|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/dev/input/touchscreen", O_RDWR|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/dev/touchscreen/ucb1x00", O_RDWR|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/dev/input", O_RDONLY|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
getdents64(3, /* 13 entries */, 2048)   = 384
getdents64(3, /* 0 entries */, 2048)    = 0
close(3)                                = 0
open("/dev/input/event0", O_RDONLY|O_LARGEFILE) = 3
ioctl(3, EVIOCGPROP(4), [ 0 ])          = 4
open("/dev/input/event1", O_RDONLY|O_LARGEFILE) = 4
ioctl(4, EVIOCGPROP(4), [ 0 ])          = 4
open("/dev/input/event2", O_RDONLY|O_LARGEFILE) = 5
ioctl(5, EVIOCGPROP(4), [ 0 ])          = 4
open("/dev/input/event3", O_RDONLY|O_LARGEFILE) = 6
ioctl(6, EVIOCGPROP(4), [ 0 ])          = 4
open("/dev/input/event4", O_RDONLY|O_LARGEFILE) = 7
ioctl(7, EVIOCGPROP(4), [ 0 ])          = 4
open("/dev/input/event5", O_RDONLY|O_LARGEFILE) = 8
ioctl(8, EVIOCGPROP(4), [ 0 ])          = 4
open("/dev/input/event6", O_RDONLY|O_LARGEFILE) = 9
ioctl(9, EVIOCGPROP(4), [ 0 ])          = 4
writev(2, [{iov_base="", iov_len=0}, {iov_base="ts_open", iov_len=7}], 2ts_open) = 7
writev(2, [{iov_base="", iov_len=0}, {iov_base=":", iov_len=1}], 2:) = 1
writev(2, [{iov_base="", iov_len=0}, {iov_base=" ", iov_len=1}], 2 ) = 1
writev(2, [{iov_base="", iov_len=0}, {iov_base="No such file or directory", iov_len=25}], 2No such file or directory) = 25
writev(2, [{iov_base="", iov_len=0}, {iov_base="\n", iov_len=1}], 2
) = 1
exit_group(1)                           = ?
+++ exited with 1 +++
localhost:/home/user# ls /dev/input/
by-path  event0   event1   event2   event3   event4   event5   event6   js0      mice     mouse0
localhost:/home/user# ts_test
ts_open: No such file or directory

@merge

This comment has been minimized.

Show comment
Hide comment
@merge

merge Nov 7, 2017

Collaborator

thanks! Could you post an output of evtest (or evemu-describe) using your touchscreen device? thanks!

Collaborator

merge commented Nov 7, 2017

thanks! Could you post an output of evtest (or evemu-describe) using your touchscreen device? thanks!

@craftyguy

This comment has been minimized.

Show comment
Hide comment
@craftyguy

craftyguy Nov 7, 2017

evtest output (including one tap):

localhost:~$ sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:	twl4030_pwrbutton
/dev/input/event1:	TWL4030 Keypad
/dev/input/event2:	RX-51 AV Jack
/dev/input/event3:	TSC2005 touchscreen
/dev/input/event4:	ST LIS3LV02DL Accelerometer
/dev/input/event5:	twl4030:vibrator
/dev/input/event6:	gpio_keys
Select the device event number [0-6]: 3
Input driver version is 1.0.1
Input device ID: bus 0x1c vendor 0x0 product 0x7d5 version 0x0
Input device name: "TSC2005 touchscreen"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 330 (BTN_TOUCH)
  Event type 3 (EV_ABS)
    Event code 0 (ABS_X)
      Value   3211
      Min        0
      Max     4095
      Fuzz       4
    Event code 1 (ABS_Y)
      Value   1368
      Min        0
      Max     4095
      Fuzz       7
    Event code 24 (ABS_PRESSURE)
      Value      0
      Min        0
      Max     2048
      Fuzz       2
Properties:
Testing ... (interrupt to exit)
Event: time 1510073793.400152, type 3 (EV_ABS), code 0 (ABS_X), value 2451
Event: time 1510073793.400152, type 3 (EV_ABS), code 1 (ABS_Y), value 2004
Event: time 1510073793.400152, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 104
Event: time 1510073793.400152, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1510073793.400152, -------------- SYN_REPORT ------------
Event: time 1510073793.404913, type 3 (EV_ABS), code 0 (ABS_X), value 2439
Event: time 1510073793.404913, type 3 (EV_ABS), code 1 (ABS_Y), value 2003
Event: time 1510073793.404913, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 144
Event: time 1510073793.404913, -------------- SYN_REPORT ------------
Event: time 1510073793.409826, type 3 (EV_ABS), code 0 (ABS_X), value 2430
Event: time 1510073793.409826, type 3 (EV_ABS), code 1 (ABS_Y), value 1983
Event: time 1510073793.409826, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 169
Event: time 1510073793.409826, -------------- SYN_REPORT ------------
Event: time 1510073793.415715, type 3 (EV_ABS), code 1 (ABS_Y), value 1984
Event: time 1510073793.415715, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 150
Event: time 1510073793.415715, -------------- SYN_REPORT ------------
Event: time 1510073793.420293, type 3 (EV_ABS), code 0 (ABS_X), value 2433
Event: time 1510073793.420293, type 3 (EV_ABS), code 1 (ABS_Y), value 2001
Event: time 1510073793.420293, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 136
Event: time 1510073793.420293, -------------- SYN_REPORT ------------
Event: time 1510073793.425908, type 3 (EV_ABS), code 0 (ABS_X), value 2443
Event: time 1510073793.425908, type 3 (EV_ABS), code 1 (ABS_Y), value 1984
Event: time 1510073793.425908, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 184
Event: time 1510073793.425908, -------------- SYN_REPORT ------------
Event: time 1510073793.475068, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 0
Event: time 1510073793.475068, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1510073793.475068, -------------- SYN_REPORT ------------

craftyguy commented Nov 7, 2017

evtest output (including one tap):

localhost:~$ sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:	twl4030_pwrbutton
/dev/input/event1:	TWL4030 Keypad
/dev/input/event2:	RX-51 AV Jack
/dev/input/event3:	TSC2005 touchscreen
/dev/input/event4:	ST LIS3LV02DL Accelerometer
/dev/input/event5:	twl4030:vibrator
/dev/input/event6:	gpio_keys
Select the device event number [0-6]: 3
Input driver version is 1.0.1
Input device ID: bus 0x1c vendor 0x0 product 0x7d5 version 0x0
Input device name: "TSC2005 touchscreen"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 330 (BTN_TOUCH)
  Event type 3 (EV_ABS)
    Event code 0 (ABS_X)
      Value   3211
      Min        0
      Max     4095
      Fuzz       4
    Event code 1 (ABS_Y)
      Value   1368
      Min        0
      Max     4095
      Fuzz       7
    Event code 24 (ABS_PRESSURE)
      Value      0
      Min        0
      Max     2048
      Fuzz       2
Properties:
Testing ... (interrupt to exit)
Event: time 1510073793.400152, type 3 (EV_ABS), code 0 (ABS_X), value 2451
Event: time 1510073793.400152, type 3 (EV_ABS), code 1 (ABS_Y), value 2004
Event: time 1510073793.400152, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 104
Event: time 1510073793.400152, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1510073793.400152, -------------- SYN_REPORT ------------
Event: time 1510073793.404913, type 3 (EV_ABS), code 0 (ABS_X), value 2439
Event: time 1510073793.404913, type 3 (EV_ABS), code 1 (ABS_Y), value 2003
Event: time 1510073793.404913, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 144
Event: time 1510073793.404913, -------------- SYN_REPORT ------------
Event: time 1510073793.409826, type 3 (EV_ABS), code 0 (ABS_X), value 2430
Event: time 1510073793.409826, type 3 (EV_ABS), code 1 (ABS_Y), value 1983
Event: time 1510073793.409826, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 169
Event: time 1510073793.409826, -------------- SYN_REPORT ------------
Event: time 1510073793.415715, type 3 (EV_ABS), code 1 (ABS_Y), value 1984
Event: time 1510073793.415715, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 150
Event: time 1510073793.415715, -------------- SYN_REPORT ------------
Event: time 1510073793.420293, type 3 (EV_ABS), code 0 (ABS_X), value 2433
Event: time 1510073793.420293, type 3 (EV_ABS), code 1 (ABS_Y), value 2001
Event: time 1510073793.420293, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 136
Event: time 1510073793.420293, -------------- SYN_REPORT ------------
Event: time 1510073793.425908, type 3 (EV_ABS), code 0 (ABS_X), value 2443
Event: time 1510073793.425908, type 3 (EV_ABS), code 1 (ABS_Y), value 1984
Event: time 1510073793.425908, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 184
Event: time 1510073793.425908, -------------- SYN_REPORT ------------
Event: time 1510073793.475068, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 0
Event: time 1510073793.475068, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1510073793.475068, -------------- SYN_REPORT ------------
@merge

This comment has been minimized.

Show comment
Hide comment
@merge

merge Nov 7, 2017

Collaborator

thanks a lot! For your driver this is expected. It doesn't set INPUT_PROP_DIRECT and therefore doesn't make it easy for userspace to discover and identify it as a touchscreen device.

Android for example wouldn't work with it either. udev (systemd) would still recognize it because it also checks for BTN_TOUCH. But that's deprecated IMO because you can really have false positives. Also there are device drivers that don't set BTN_TOUCH anymore. For type B multitouch it's not required.

So in short, this is a Linux problem, not a tslib problem. I'd be happy to send a patch to Dmitry, so that it'll be in Linux 4.15, or do you do it yourself?

thanks a lot again

Collaborator

merge commented Nov 7, 2017

thanks a lot! For your driver this is expected. It doesn't set INPUT_PROP_DIRECT and therefore doesn't make it easy for userspace to discover and identify it as a touchscreen device.

Android for example wouldn't work with it either. udev (systemd) would still recognize it because it also checks for BTN_TOUCH. But that's deprecated IMO because you can really have false positives. Also there are device drivers that don't set BTN_TOUCH anymore. For type B multitouch it's not required.

So in short, this is a Linux problem, not a tslib problem. I'd be happy to send a patch to Dmitry, so that it'll be in Linux 4.15, or do you do it yourself?

thanks a lot again

@craftyguy

This comment has been minimized.

Show comment
Hide comment
@craftyguy

craftyguy Nov 8, 2017

I would totally send a patch upstream if I had the slightest idea of what I would need to change (I don't, unfortunately). If you're willing to give me some hints as to what the patch would need to include, I can give it my best shot! :)

Android for example wouldn't work with it either.

Do you mean devices that run Android? I deal with a lot of devices which originally ran Android, but we're now installing gnu/Linux on them, and they generally have MT touch devices. Just FYI, the device I tested on above is not a MT device and it's not a former Android device, it's a resistive touchscreen.

craftyguy commented Nov 8, 2017

I would totally send a patch upstream if I had the slightest idea of what I would need to change (I don't, unfortunately). If you're willing to give me some hints as to what the patch would need to include, I can give it my best shot! :)

Android for example wouldn't work with it either.

Do you mean devices that run Android? I deal with a lot of devices which originally ran Android, but we're now installing gnu/Linux on them, and they generally have MT touch devices. Just FYI, the device I tested on above is not a MT device and it's not a former Android device, it's a resistive touchscreen.

@merge

This comment has been minimized.

Show comment
Hide comment
@merge

merge Nov 8, 2017

Collaborator

I mean the Android userspace wouldn't work with the kernel driver you are running; just as an example. And so doesn't tslib :)

I already went ahead and submitted it and it's already included in the input subsystem tree: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=for-linus&id=eca253912f734927005500da7d646536064b3ed3 I can't say for sure, but this way it has a chance that it will even be merged into 4.14, which will be LTS, so it'll be nice for you. So as soon as you update Linux, this device should work with tslib.

Can you test tslib 1.14-rc2 with another (maybe MT) device? I mean autodetection (unset TSLIB_TSDEVICE and so on).

Collaborator

merge commented Nov 8, 2017

I mean the Android userspace wouldn't work with the kernel driver you are running; just as an example. And so doesn't tslib :)

I already went ahead and submitted it and it's already included in the input subsystem tree: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=for-linus&id=eca253912f734927005500da7d646536064b3ed3 I can't say for sure, but this way it has a chance that it will even be merged into 4.14, which will be LTS, so it'll be nice for you. So as soon as you update Linux, this device should work with tslib.

Can you test tslib 1.14-rc2 with another (maybe MT) device? I mean autodetection (unset TSLIB_TSDEVICE and so on).

@craftyguy

This comment has been minimized.

Show comment
Hide comment
@craftyguy

craftyguy Nov 8, 2017

Oh wow, thank you for submitting that :)

I don't have a MT device, or even another touch device to test on.. I will try summoning some of the users of my app who have these devices, that may be able to help!

Arise @drebrez, @ata2001, @IanS5, @ollieparanoid! Would either one of you with a MT touchscreen device be able/willing to test out a new tslib version that implements auto-detection for touchscreen devices? This would have the benefit for us of not having to set TSLIB_TSDEVICE! An easy way to test this is to grab Alpine's upstream tslib APKBUILD, change pkgver to 1.14-rc2 (yes, I know it's not compliant with apkbuild standards, but it works), then build tslib using pmbootstrap, upload to your device and install it, then unset TSLIB_TSDEVICE before running osk-sdl!

craftyguy commented Nov 8, 2017

Oh wow, thank you for submitting that :)

I don't have a MT device, or even another touch device to test on.. I will try summoning some of the users of my app who have these devices, that may be able to help!

Arise @drebrez, @ata2001, @IanS5, @ollieparanoid! Would either one of you with a MT touchscreen device be able/willing to test out a new tslib version that implements auto-detection for touchscreen devices? This would have the benefit for us of not having to set TSLIB_TSDEVICE! An easy way to test this is to grab Alpine's upstream tslib APKBUILD, change pkgver to 1.14-rc2 (yes, I know it's not compliant with apkbuild standards, but it works), then build tslib using pmbootstrap, upload to your device and install it, then unset TSLIB_TSDEVICE before running osk-sdl!

@ollieparanoid

This comment has been minimized.

Show comment
Hide comment
@ollieparanoid

ollieparanoid Nov 8, 2017

Wow, that feature sounds really awesome! I've installed 1.14-rc2 on the Android device Samsung Galaxy SII and ts_test recognized the touch screen correctly, although TSLIB_TSDEVICE etc. were not set.

I didn't strace it, but touching the screen works (nice demo program btw 👍), so it must have found the touch screen in /dev/input/event2.

ts_test_mt is also working. when I move 3 fingers across the screen, it shows 3 cursors at the right locations (but also one flickering cursor in the middle when not moving the fingers).

Is there anything else you want me to test, or any output you need?

ollieparanoid commented Nov 8, 2017

Wow, that feature sounds really awesome! I've installed 1.14-rc2 on the Android device Samsung Galaxy SII and ts_test recognized the touch screen correctly, although TSLIB_TSDEVICE etc. were not set.

I didn't strace it, but touching the screen works (nice demo program btw 👍), so it must have found the touch screen in /dev/input/event2.

ts_test_mt is also working. when I move 3 fingers across the screen, it shows 3 cursors at the right locations (but also one flickering cursor in the middle when not moving the fingers).

Is there anything else you want me to test, or any output you need?

@merge

This comment has been minimized.

Show comment
Hide comment
@merge

merge Nov 9, 2017

Collaborator

Thanks for testing! I don't need anything else for the upcoming release. Feel free to report any problems anytime.

Yeah the flickering cross in the center of ts_test_mt... It shouldn't be there, it's ugly and a bug basically. On the other hand, it indicates that there is an unused available slot still available, which I personally find handy :)

But if you want to, create and issue for that. If we want to indicate how many slots are available in total, we should do so explicitely. We could write a small number to a corner of the screen?

Collaborator

merge commented Nov 9, 2017

Thanks for testing! I don't need anything else for the upcoming release. Feel free to report any problems anytime.

Yeah the flickering cross in the center of ts_test_mt... It shouldn't be there, it's ugly and a bug basically. On the other hand, it indicates that there is an unused available slot still available, which I personally find handy :)

But if you want to, create and issue for that. If we want to indicate how many slots are available in total, we should do so explicitely. We could write a small number to a corner of the screen?

@merge

This comment has been minimized.

Show comment
Hide comment
@merge

merge Nov 11, 2017

Collaborator

@craftyguy The update for your TSC2005 device' driver is in Linux 4.14, most probably released tomorrow. It was really at the last minute :) I guess 4.14 is a version you'll upgrade to regardless of this one day, so you'll get this automatically.

Collaborator

merge commented Nov 11, 2017

@craftyguy The update for your TSC2005 device' driver is in Linux 4.14, most probably released tomorrow. It was really at the last minute :) I guess 4.14 is a version you'll upgrade to regardless of this one day, so you'll get this automatically.

@craftyguy

This comment has been minimized.

Show comment
Hide comment
@craftyguy

craftyguy Nov 11, 2017

Oh wow, that's incredible you got it in just in time! I plan to build/run 4.14 on my device as soon as it hits kernel.org. We track as closely to mainline stable kernels as humanly possible :)

craftyguy commented Nov 11, 2017

Oh wow, that's incredible you got it in just in time! I plan to build/run 4.14 on my device as soon as it hits kernel.org. We track as closely to mainline stable kernels as humanly possible :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment