From: Donald Kayser <hidden> Date: 2012-06-21 15:05:31
Hello All,
I am part of development of a product that uses touchscreens
extensively. We have to maintain touchscreen calibration and X Display
association across boots. We support up to six screens, 3 internal to
our product, 3 external to our product. All internal screens have
touchscreens with cables that don't move, so using the device /dev/
input/by-path/<devicelink> I could modify xorg.conf with an
InputSection and associate the screen and touchscreen, include
calibration, and every time the user returned, it was already
calibrated and working correctly. It has worked great until we started
adding multi-touch devices. The line of multi-touch devices we are
using is manufactured my MosArt.
I added the defines for the products in my local kernel tree's driver/
hid/hid-ids.h and added the quirk for HID_QUIRK_MULTI_INPUT in hid-
quirks.c. With the kernel 2.6.39.4 and earlier to 2.6.32.n, there is
confusion with the /dev/input/by-path/<devlink>. These multi-touch
devices show up with four entries in /dev/input/<dev>. From looking at
the output of lsinput, two of the entries have identical information
with regards to event bits. Only one of these identical entries in /
dev/input/<dev> actually work; one reports 13 axis, one reports 3
axis. When the /dev/input/by-path/<devlink> points to the 'working' /
dev/input/<dev> all is fine. This only happens 50% of the time and
with three screens it is not likely to get all three right on any boot.
So, is this a good place to ask this question? What other information
would be beneficial? I purposely left out a bunch of debug info so not
to get too noisy.
Thanks in advance,
Donald Kayser
linux at kayser dot net
From: Benjamin Tissoires <hidden> Date: 2012-06-21 20:31:06
Hello Donald,
I think that you are encountering at least 3 problems:
1) your devices are not correctly handled by the kernel
2) solving the handling of multitouch devices by adding the quirk
HID_QUIRK_MULTI_INPUT is __really__ a bad idea in your case
3) you seem to use very old kernels.
So:
1) between 2.6.34 and 2.6.39, Mosart devices are handled in
hid-mosart, and since 3.0 through hid-multitouch. Using these drivers
will allow you to have a better support of your devices.
However I'm not 100% sure it won't create more than one input device
if your hardware declares more than one interface.
2) Using the quirk HID_QUIRK_MULTI_INPUT is the exact opposite of what
you want to do -> it creates several inputs when it sees several
touches -> you then have a lot of inputs with unusable stuff.
3) By using a kernel >=3.4 and by modprobing hid-multitouch, your
mosart devices will be correctly handled by the kernel.
However, if you can not update your kernel here are some ideas:
- use the right module for your devices (hid-mosart or hid-multitouch)
- patch your kernel (> 2.6.35) using the patches here:
http://www.lii-enac.fr/en/architecture/linux-input/multitouch-howto.html#get
(but I did not tested old kernel releases) -> you will get the same
input layer for multitouch than a 3.4 kernel (the older the kernel is,
the more intrusive it is).
- work on an udev rule that detect the physical path, and creates a
symlink /dev/input/mosart-X
- rely on xorg input rules system to detect your devices (though I
don't know when they added the physical path in the configuration
options).
Cheers,
Benjamin
On Thu, Jun 21, 2012 at 4:52 PM, Donald Kayser [off-list ref] wrote:
Hello All,
I am part of development of a product that uses touchscreens extensively. We
have to maintain touchscreen calibration and X Display association across
boots. We support up to six screens, 3 internal to our product, 3 external
to our product. All internal screens have touchscreens with cables that
don't move, so using the device /dev/input/by-path/<devicelink> I could
modify xorg.conf with an InputSection and associate the screen and
touchscreen, include calibration, and every time the user returned, it was
already calibrated and working correctly. It has worked great until we
started adding multi-touch devices. The line of multi-touch devices we are
using is manufactured my MosArt.
I added the defines for the products in my local kernel tree's
driver/hid/hid-ids.h and added the quirk for HID_QUIRK_MULTI_INPUT in
hid-quirks.c. With the kernel 2.6.39.4 and earlier to 2.6.32.n, there is
confusion with the /dev/input/by-path/<devlink>. These multi-touch devices
show up with four entries in /dev/input/<dev>. From looking at the output of
lsinput, two of the entries have identical information with regards to event
bits. Only one of these identical entries in /dev/input/<dev> actually work;
one reports 13 axis, one reports 3 axis. When the
/dev/input/by-path/<devlink> points to the 'working' /dev/input/<dev> all is
fine. This only happens 50% of the time and with three screens it is not
likely to get all three right on any boot.
So, is this a good place to ask this question? What other information would
be beneficial? I purposely left out a bunch of debug info so not to get too
noisy.
Thanks in advance,
Donald Kayser
linux at kayser dot net
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Donald Kayser <hidden> Date: 2012-06-22 12:56:44
Thanks Benjamin. This will get me down a new path. I was very
uncertain about the quirk and I am grateful you pointed it out.
On Jun 21, 2012, at 3:31 PM, Benjamin Tissoires wrote:
3) you seem to use very old kernels.
Yes, it is due to our priorities of delivering a system to our
customers that is stable, that we have time to do complete system
regression testing, and most importantly, our embedded system's
distribution must work across several versions of the product with
slightly different video and network interfaces. Right now two of my
target systems have ATI graphics, in one I have to use the 1.10 fglrx
drivers. On the other I have to use 1.12 fglrx drivers. The 1.10
driver modules do not build past around kernel 2.6.38ish because of
changes in the kernel headers to change smp locking. The newest
version of fglrx does not support both chip sets on my target
machines. The matrix of which kernel is available becomes limited.
I would like to be able to do it different, but our products last
around ten years or more in some cases. In a product delivery
environment of our type, we just can't be idealists, or we would never
have a product to sell.
- rely on xorg input rules system to detect your devices (though I
don't know when they added the physical path in the configuration
I haven't found this to be an automatic option. In order for us to
have a panoramic surface of up to 6 screens, we have 6 X Displays. You
end up this way when you have 3 graphics cards in a system as we do.
Every screen has a touchscreen and in the environment we have to
support directing the mouse input to the correct X Display. I have
learned in the newer world of kernel and X you have this lovely affine
matrix for all kinds of transformations, but not in our world yet. In
order for evdev to work in our environment, I added an option ScreenNo
so that I could do what the old elographics driver did and set the X
display before passing off the event. We have a custom calibration
utility that associates /dev/input/by-path/<dev> to an InputSection in
xorg.conf that configures the ScreenNo option. Maybe there is a better
way in the environment, but this is the solution that I came up with
so the user doesn't have to calibrate until he adds and external
touchscreen.
I know that the call I used in evdev to change to a different screen
doesn't exist in the newest X server and they are relying on the
matrices for the transformations. I have wondered if they have
considered that with three video cards, each with its own device
section in xorg.conf, will I be able to direct the press correctly?
Does there definitions of screen coordinate cross across X Display
boundaries?
Best regards and thanks again. I will get rid of the quirk solution
and try again.
Donald
On Thu, Jun 21, 2012 at 4:52 PM, Donald Kayser [off-list ref]
wrote:
quoted
Hello All,
I am part of development of a product that uses touchscreens
extensively. We
have to maintain touchscreen calibration and X Display association
across
boots. We support up to six screens, 3 internal to our product, 3
external
to our product. All internal screens have touchscreens with cables
that
don't move, so using the device /dev/input/by-path/<devicelink> I
could
modify xorg.conf with an InputSection and associate the screen and
touchscreen, include calibration, and every time the user returned,
it was
already calibrated and working correctly. It has worked great until
we
started adding multi-touch devices. The line of multi-touch devices
we are
using is manufactured my MosArt.
I added the defines for the products in my local kernel tree's
driver/hid/hid-ids.h and added the quirk for HID_QUIRK_MULTI_INPUT in
hid-quirks.c. With the kernel 2.6.39.4 and earlier to 2.6.32.n,
there is
confusion with the /dev/input/by-path/<devlink>. These multi-touch
devices
show up with four entries in /dev/input/<dev>. From looking at the
output of
lsinput, two of the entries have identical information with regards
to event
bits. Only one of these identical entries in /dev/input/<dev>
actually work;
one reports 13 axis, one reports 3 axis. When the
/dev/input/by-path/<devlink> points to the 'working' /dev/input/
<dev> all is
fine. This only happens 50% of the time and with three screens it
is not
likely to get all three right on any boot.
So, is this a good place to ask this question? What other
information would
be beneficial? I purposely left out a bunch of debug info so not to
get too
noisy.
Thanks in advance,
Donald Kayser
linux at kayser dot net
--
To unsubscribe from this list: send the line "unsubscribe linux-
input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Donald Kayser <hidden> Date: 2012-06-28 20:34:43
Hi Benjamin,
So:
1) between 2.6.34 and 2.6.39, Mosart devices are handled in
hid-mosart, and since 3.0 through hid-multitouch. Using these drivers
will allow you to have a better support of your devices.
However I'm not 100% sure it won't create more than one input device
if your hardware declares more than one interface.
2) Using the quirk HID_QUIRK_MULTI_INPUT is the exact opposite of what
you want to do -> it creates several inputs when it sees several
touches -> you then have a lot of inputs with unusable stuff.
I have returned to this problem today. I've turned off the QUIRK and
added the hid_mosart driver. These devices are new so I added their
ID's so the mosart driver would recognize them. I end up with the same
results I had before ever trying the QUIRK: the event codes from the
device are not ABS_X and ABS_Y, but ABS_HAT2X and ABS_HAT2Y. These
ABS_HAT2? events make it through the system device files and I can
read them using the linux input API. The problem is that the xorg
evdev driver does not process the ABS_HAT2? events. The QUIRK made the
events change to ABS_X and ABS_Y. The usbhid driver and hid_mosart
driver end up giving the same results with respect to the data being
reported via linux input API.
I am reluctant to patch the kernel we end up qualifying for our
systems. It is an unknown for me trying to deliver a product soon.
- work on an udev rule that detect the physical path, and creates a
symlink /dev/input/mosart-X
This is helpful and made it where I could get the QUIRK solution
working okay. Without the QUIRK there isn't an entry problem in the /
dev/input/by-path directory.
- rely on xorg input rules system to detect your devices (though I
don't know when they added the physical path in the configuration
options).
I have been attempting to get the driver layer to send up ABS_X and
ABS_Y so that evdev would work. I mod'd evdev to process the new
events but it got screwy. I prefer to get the system to send up events
that evdev will handle and I won't have to modify it further. I don't
need any kind of multi-touch capability until the next major revision
of our application software, so I am taking the shortest path to get
there.
Thanks,
Donald
From: Benjamin Tissoires <hidden> Date: 2012-06-28 21:38:09
Hi Donald,
On Thu, Jun 28, 2012 at 10:34 PM, Donald Kayser [off-list ref] wrote:
Hi Benjamin,
quoted
So:
1) between 2.6.34 and 2.6.39, Mosart devices are handled in
hid-mosart, and since 3.0 through hid-multitouch. Using these drivers
will allow you to have a better support of your devices.
However I'm not 100% sure it won't create more than one input device
if your hardware declares more than one interface.
2) Using the quirk HID_QUIRK_MULTI_INPUT is the exact opposite of what
you want to do -> it creates several inputs when it sees several
touches -> you then have a lot of inputs with unusable stuff.
I have returned to this problem today. I've turned off the QUIRK and added
the hid_mosart driver. These devices are new so I added their ID's so the
mosart driver would recognize them. I end up with the same results I had
You also have to add your device in the blacklist in hid-core.c.
Earlier kernels (< 3.2) do not detect multitouch devices and handle it
through the hid-generic layer no matter you assign them to another
driver.
This blacklist is called hid_have_special_driver in earlier kernels (>
2.6.38) and hid_blacklist in earlier kernels (<= 2.6.37).
before ever trying the QUIRK: the event codes from the device are not ABS_X
and ABS_Y, but ABS_HAT2X and ABS_HAT2Y. These ABS_HAT2? events make it
through the system device files and I can read them using the linux input
API. The problem is that the xorg evdev driver does not process the
ABS_HAT2? events. The QUIRK made the events change to ABS_X and ABS_Y. The
usbhid driver and hid_mosart driver end up giving the same results with
respect to the data being reported via linux input API.
Yep, that's because you are not using the hid-mosart driver. When
using it, you should see in evtest the events ABS_MT_POSITION_X (and
Y) and MT_SYNC IIRC. The good point for you is that the mouse
emulation should work, and you can ignore those mt-events.
Cheers,
Benjamin
I am reluctant to patch the kernel we end up qualifying for our systems. It
is an unknown for me trying to deliver a product soon.
quoted
- work on an udev rule that detect the physical path, and creates a
symlink /dev/input/mosart-X
This is helpful and made it where I could get the QUIRK solution working
okay. Without the QUIRK there isn't an entry problem in the
/dev/input/by-path directory.
quoted
- rely on xorg input rules system to detect your devices (though I
don't know when they added the physical path in the configuration
options).
I have been attempting to get the driver layer to send up ABS_X and ABS_Y so
that evdev would work. I mod'd evdev to process the new events but it got
screwy. I prefer to get the system to send up events that evdev will handle
and I won't have to modify it further. I don't need any kind of multi-touch
capability until the next major revision of our application software, so I
am taking the shortest path to get there.
Thanks,
Donald
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html