Patchwork Upcoming Kernel - MultiTouchScreen Support

login
register
mail settings
Submitter Luis Rodriguez
Date March 4, 2010, 9:20 a.m.
Message ID <43e72e891003040120o497814aap4d1ef7f772cf8773@mail.gmail.com>
Download mbox | patch
Permalink /patch/46894/
State RFC
Headers show

Comments

Luis Rodriguez - March 4, 2010, 9:20 a.m.
On Thu, Mar 4, 2010 at 12:18 AM, Amit Kucheria
<amit.kucheria@canonical.com> wrote:
> Hi Thomas,
>
> I'm forwarding this to the kernel-team mailing list so other developers can
> also comment.
>
> Regards,
> Amit
>
> ----- Forwarded message from Thomas Winteler <info@win-soft.ch> -----
>
> Date: Wed, 03 Mar 2010 09:26:56 +0100
> From: Thomas Winteler <info@win-soft.ch>
> To: amit.kucheria@ubuntu.com
> Subject: Upcoming Kernel - MultiTouchScreen Support
> User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2
> Organization: Win-Soft, Business IT eXpert
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Good Morning Mr. Amit Kucheria
>
> Thank you for your time, reading my eMail.
>
> The new Hardware on the market offer MultiTouchScreens, like the Netbook
> from ASUS:
> ASUS EEE PC T91MT
> http://www.asus.com/product.aspx?P_ID=KIqtSJ1aVsmVpeqS
>
> I found some information in ASUS's Support Forum and found also a Linux
> Driver Builder.
> http://vip.asus.com/forum/view.aspx?id=20091214162901203&SLanguage=en-us&page=2&board_id=20&model=Eee%20PC%20T91MT
>
> ENAC Interactive computing laboratory HowTo
> http://lii-enac.fr/en/projects/shareit/linux-howto.html
>
> Drivers from ENAC
> http://lii-enac.fr/en/projects/shareit/linux.html
>
> MosArt MT Driver for ASUS's T91MT
> http://lii-enac.fr/en/projects/shareit/multitouch-devices.html
> - --> MosArt
>
> The Problem on this thing is, that the Kernel needs to be patched and
> recompiled to get it running.

The kernel changes don't seem that bad, I only see mention to one
header file which needs to be changed as follows:

 /* HID core API */

But this the change required is not documented, why is this required?
Anyway apart from it seems you need to modify the hid module and
provide it as a replacement. The rest is just adding drivers, and that
should be relatively trivial.

What would be better is to track what is not upstream, see if the
authors are working on that, and if not see if the driver project can
get it upstream at least through staging.

  Luis
Luis Rodriguez - March 4, 2010, 9:23 a.m.
Adding Chatty @ ENAC, in hopes some more light can be shed on this.

On Thu, Mar 4, 2010 at 1:20 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Thu, Mar 4, 2010 at 12:18 AM, Amit Kucheria
> <amit.kucheria@canonical.com> wrote:
>> Hi Thomas,
>>
>> I'm forwarding this to the kernel-team mailing list so other developers can
>> also comment.
>>
>> Regards,
>> Amit
>>
>> ----- Forwarded message from Thomas Winteler <info@win-soft.ch> -----
>>
>> Date: Wed, 03 Mar 2010 09:26:56 +0100
>> From: Thomas Winteler <info@win-soft.ch>
>> To: amit.kucheria@ubuntu.com
>> Subject: Upcoming Kernel - MultiTouchScreen Support
>> User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2
>> Organization: Win-Soft, Business IT eXpert
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Good Morning Mr. Amit Kucheria
>>
>> Thank you for your time, reading my eMail.
>>
>> The new Hardware on the market offer MultiTouchScreens, like the Netbook
>> from ASUS:
>> ASUS EEE PC T91MT
>> http://www.asus.com/product.aspx?P_ID=KIqtSJ1aVsmVpeqS
>>
>> I found some information in ASUS's Support Forum and found also a Linux
>> Driver Builder.
>> http://vip.asus.com/forum/view.aspx?id=20091214162901203&SLanguage=en-us&page=2&board_id=20&model=Eee%20PC%20T91MT
>>
>> ENAC Interactive computing laboratory HowTo
>> http://lii-enac.fr/en/projects/shareit/linux-howto.html
>>
>> Drivers from ENAC
>> http://lii-enac.fr/en/projects/shareit/linux.html
>>
>> MosArt MT Driver for ASUS's T91MT
>> http://lii-enac.fr/en/projects/shareit/multitouch-devices.html
>> - --> MosArt
>>
>> The Problem on this thing is, that the Kernel needs to be patched and
>> recompiled to get it running.
>
> The kernel changes don't seem that bad, I only see mention to one
> header file which needs to be changed as follows:
>
> diff --git a/include/linux/hid.h b/include/linux/hid.h
> index b1344ec..5ad8e6e 100644
> --- a/include/linux/hid.h
> +++ b/include/linux/hid.h
> @@ -663,7 +663,7 @@ struct hid_ll_driver {
>
>  /* Applications from HID Usage Tables 4/8/99 Version 1.1 */
>  /* We ignore a few input applications that are not widely used */
> -#define IS_INPUT_APPLICATION(a) (((a >= 0x00010000) && (a <=
> 0x00010008)) || (a == 0x00010080) || (a == 0x000c0001) || ((a >=
> 0x000d0002) && (a <= 0x000d000
> +#define IS_INPUT_APPLICATION(a) (a >= 0xd0002 && a <= 0xd0006)
>
>  /* HID core API */
>
> But this the change required is not documented, why is this required?
> Anyway apart from it seems you need to modify the hid module and
> provide it as a replacement. The rest is just adding drivers, and that
> should be relatively trivial.
>
> What would be better is to track what is not upstream, see if the
> authors are working on that, and if not see if the driver project can
> get it upstream at least through staging.
>
>  Luis
>
Stéphane Chatty - March 4, 2010, 9:56 a.m.
Hi,

in order to have the driver up and running, two modifications are  
necessary in the hid subsystem:

  1. the one described below, in hid.h. This is required for a whole  
bunch of multitouch devices but obviously it has to be done only once.

  2. the addition of the device's (VendorID, ProductID) couple to a  
black list in the hid subsystem's core, so that the new driver can  
manage it. This involves changes in hid-ids.h and hid-core.c, for  
every new driver.

If hid is compiled as a module, this is fairly straightfowrad. If, as  
in Ubuntu, it is statically compiled in the kernel, it means that one  
needs to recompile the kernel each time they add a new multitouch  
driver.

I was hoping that at least the first patch would be taken into  
account for 2.6.33 so as to save work for a lot of people, but it  
looks like the patch came too late in the process.

Cheers,

St.

Le 4 mars 10 à 10:23, Luis R. Rodriguez a écrit :

> Adding Chatty @ ENAC, in hopes some more light can be shed on this.
>
> On Thu, Mar 4, 2010 at 1:20 AM, Luis R. Rodriguez  
> <mcgrof@gmail.com> wrote:
>> On Thu, Mar 4, 2010 at 12:18 AM, Amit Kucheria
>> <amit.kucheria@canonical.com> wrote:
>>> Hi Thomas,
>>>
>>> I'm forwarding this to the kernel-team mailing list so other  
>>> developers can
>>> also comment.
>>>
>>> Regards,
>>> Amit
>>>
>>> ----- Forwarded message from Thomas Winteler <info@win-soft.ch>  
>>> -----
>>>
>>> Date: Wed, 03 Mar 2010 09:26:56 +0100
>>> From: Thomas Winteler <info@win-soft.ch>
>>> To: amit.kucheria@ubuntu.com
>>> Subject: Upcoming Kernel - MultiTouchScreen Support
>>> User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv: 
>>> 1.9.1.8) Gecko/20100216 Thunderbird/3.0.2
>>> Organization: Win-Soft, Business IT eXpert
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Good Morning Mr. Amit Kucheria
>>>
>>> Thank you for your time, reading my eMail.
>>>
>>> The new Hardware on the market offer MultiTouchScreens, like the  
>>> Netbook
>>> from ASUS:
>>> ASUS EEE PC T91MT
>>> http://www.asus.com/product.aspx?P_ID=KIqtSJ1aVsmVpeqS
>>>
>>> I found some information in ASUS's Support Forum and found also a  
>>> Linux
>>> Driver Builder.
>>> http://vip.asus.com/forum/view.aspx? 
>>> id=20091214162901203&SLanguage=en-us&page=2&board_id=20&model=Eee% 
>>> 20PC%20T91MT
>>>
>>> ENAC Interactive computing laboratory HowTo
>>> http://lii-enac.fr/en/projects/shareit/linux-howto.html
>>>
>>> Drivers from ENAC
>>> http://lii-enac.fr/en/projects/shareit/linux.html
>>>
>>> MosArt MT Driver for ASUS's T91MT
>>> http://lii-enac.fr/en/projects/shareit/multitouch-devices.html
>>> - --> MosArt
>>>
>>> The Problem on this thing is, that the Kernel needs to be patched  
>>> and
>>> recompiled to get it running.
>>
>> The kernel changes don't seem that bad, I only see mention to one
>> header file which needs to be changed as follows:
>>
>> diff --git a/include/linux/hid.h b/include/linux/hid.h
>> index b1344ec..5ad8e6e 100644
>> --- a/include/linux/hid.h
>> +++ b/include/linux/hid.h
>> @@ -663,7 +663,7 @@ struct hid_ll_driver {
>>
>>  /* Applications from HID Usage Tables 4/8/99 Version 1.1 */
>>  /* We ignore a few input applications that are not widely used */
>> -#define IS_INPUT_APPLICATION(a) (((a >= 0x00010000) && (a <=
>> 0x00010008)) || (a == 0x00010080) || (a == 0x000c0001) || ((a >=
>> 0x000d0002) && (a <= 0x000d000
>> +#define IS_INPUT_APPLICATION(a) (a >= 0xd0002 && a <= 0xd0006)
>>
>>  /* HID core API */
>>
>> But this the change required is not documented, why is this required?
>> Anyway apart from it seems you need to modify the hid module and
>> provide it as a replacement. The rest is just adding drivers, and  
>> that
>> should be relatively trivial.
>>
>> What would be better is to track what is not upstream, see if the
>> authors are working on that, and if not see if the driver project can
>> get it upstream at least through staging.
>>
>>  Luis
>>
Luis Rodriguez - March 4, 2010, 10:12 a.m.
On Thu, Mar 4, 2010 at 1:56 AM, Stéphane Chatty <chatty@enac.fr> wrote:
> Hi,
>
> in order to have the driver up and running, two modifications are necessary
> in the hid subsystem:
>
>  1. the one described below, in hid.h. This is required for a whole bunch of
> multitouch devices but obviously it has to be done only once.

Why is this required, what's the change do?

>  2. the addition of the device's (VendorID, ProductID) couple to a black
> list in the hid subsystem's core, so that the new driver can manage it. This
> involves changes in hid-ids.h and hid-core.c, for every new driver.

If the non upstream drivers are sucked into staging I'm not sure how
this could be handled. Staging drivers have kconfig entries so perhaps
those can be used to add new entries to hid, not sure if that would be
acceptable upstream.

> If hid is compiled as a module, this is fairly straightfowrad. If, as in
> Ubuntu, it is statically compiled in the kernel, it means that one needs to
> recompile the kernel each time they add a new multitouch driver.
>
> I was hoping that at least the first patch would be taken into account for
> 2.6.33 so as to save work for a lot of people, but it looks like the patch
> came too late in the process.

Are familiar with the drivers? How's the quality of the drivers, I
haven't gotten a chance to review yet, were they developed with
upstream in mind or are they they your typical vendor driver?

  Luis
Stéphane Chatty - March 4, 2010, 11:05 a.m.
Le 4 mars 10 à 11:12, Luis R. Rodriguez a écrit :

> On Thu, Mar 4, 2010 at 1:56 AM, Stéphane Chatty <chatty@enac.fr>  
> wrote:
>> Hi,
>>
>> in order to have the driver up and running, two modifications are  
>> necessary
>> in the hid subsystem:
>>
>>  1. the one described below, in hid.h. This is required for a  
>> whole bunch of
>> multitouch devices but obviously it has to be done only once.
>
> Why is this required, what's the change do?

The IS_INPUT_APPLICATION macro decides whether a HID device should be  
connected to the input subsystem or not, considering that some uses  
of HID are for things that are not real user input devices. The macro  
lists all 'legitimate' cases of user input devices. Its current  
version ignores most digitizers, including multitouch panels. The  
patch aims at having them considered as legitimate user input  
devices, so that they are not ignored by the input subsystem.

>
>>  2. the addition of the device's (VendorID, ProductID) couple to a  
>> black
>> list in the hid subsystem's core, so that the new driver can  
>> manage it. This
>> involves changes in hid-ids.h and hid-core.c, for every new driver.
>
> If the non upstream drivers are sucked into staging I'm not sure how
> this could be handled. Staging drivers have kconfig entries so perhaps
> those can be used to add new entries to hid, not sure if that would be
> acceptable upstream.

Er, I'm not expert enough in kernel inclusion processes to answer  
this one. I add Jiri Kosina to this reply, hoping he can help.

>
>> If hid is compiled as a module, this is fairly straightfowrad. If,  
>> as in
>> Ubuntu, it is statically compiled in the kernel, it means that one  
>> needs to
>> recompile the kernel each time they add a new multitouch driver.
>>
>> I was hoping that at least the first patch would be taken into  
>> account for
>> 2.6.33 so as to save work for a lot of people, but it looks like  
>> the patch
>> came too late in the process.
>
> Are familiar with the drivers? How's the quality of the drivers, I
> haven't gotten a chance to review yet, were they developed with
> upstream in mind or are they they your typical vendor driver?

I wrote these drivers, so they must be perfect of course :-) More  
seriously, they were developed with upstream in mind and have been  
widely tested already. Previous similar multitouch drivers of mine  
are already included since 2.6.32.

St.
Chase Douglas - March 4, 2010, 2:35 p.m.
I'd like to share a few points from my experiences. I have an Apple
Magic Mouse (the entire surface is a big multitouch panel), so I saw the
ENAC work and Jiri's magicmouse driver. I got Jiri's driver working by
patching the lucid kernel, but I wasn't able to get the ENAC multitouchd
software to compile (or really to figure out what it was intended to do,
there's no documentation in the tarball). The one thing I really am
interested in is scrolling through the magic mouse touch panel, but the
current X input implementation for scrolling leaves much to be desired
in the end result because there's no smooth scrolling.

I didn't bother bringing this up before now because I figured support
just wasn't there in user space to make the effort worth while in the
kernel for Lucid. However, as noted, it would make things easier if
ubuntu shipped with the hid driver compiled as a module instead of
statically in the kernel. This is not only the case for ENAC's
multitouch work, but also for the magicmouse driver Jiri wrote. Perhaps
we should consider changing this?

Thanks,
Chase
Benjamin Tissoires - March 5, 2010, 11:07 a.m.
Hello,

I'm the guy who wrote multitouchd and the xf86-input-evdev patch for 
multitouch. So I can give you some explanations.

Basically, the xorg patch just transfers the different events coming 
from the different points to different slave devices. By default, it 
does not do anything and act as a normal evdev driver (it uses the 
emulation given by the kernel).

Multitouchd is a tool that simplify the process to set up the device for 
multitouch. It tells it to create one or more subdevices that will 
handle the different touches.
Then, multitouchd set up the xserver by adding one master device per 
subdevice. Finally it attaches each subdevice to one master pointer.

However, all the multitouch devices I know do not send their button 
press/release. So the result will be just the motion of the different 
pointers. That's why multitouchd uses Xtest to send the press/release 
events, according to the valuator "Tracking ID".


As for the Apple Magic Mouse, I also own one. I tested it against the 
patched evdev driver (in X), and I got into some troubles: I think this 
is the first time (besides the wacom that are a little bit different) 
that I get a device that reports both absolute and relative valuators in 
the same report.
However, the X server is not aware of a per axis mode (absolute or 
relative). So this can not work, unless we make a sided driver to split 
the two modes, or unless we patch the xserver to handle it correctly. I 
started doing that, the patch of the xserver, but I don't have much time 
to work on it.

So the Magic Mouse is too far for being including as a multitouch device 
and that's why the scrolling has to be inside the kernel for now (which 
is a very bad idea I think).

Cheers,
Benjamin


Le 04/03/2010 16:31, Stéphane Chatty a écrit :
> Début du message réexpédié :
>
>> De : Chase Douglas <chase.douglas@canonical.com>
>> Date : 4 mars 2010 15:35:46 HNEC
>> À : Stéphane Chatty <chatty@enac.fr>
>> Cc : "Luis R. Rodriguez" <mcgrof@gmail.com>, Greg KH <greg@kroah.com>,
>> List Ubuntu Kernel Team <kernel-team@lists.ubuntu.com>, Jiri Kosina
>> <jkosina@suse.cz>, devel@driverdev.osuosl.org, Thomas Winteler
>> <info@win-soft.ch>
>> Objet : Rép : Upcoming Kernel - MultiTouchScreen Support
>>
>> I'd like to share a few points from my experiences. I have an Apple
>> Magic Mouse (the entire surface is a big multitouch panel), so I saw the
>> ENAC work and Jiri's magicmouse driver. I got Jiri's driver working by
>> patching the lucid kernel, but I wasn't able to get the ENAC multitouchd
>> software to compile (or really to figure out what it was intended to do,
>> there's no documentation in the tarball). The one thing I really am
>> interested in is scrolling through the magic mouse touch panel, but the
>> current X input implementation for scrolling leaves much to be desired
>> in the end result because there's no smooth scrolling.
>>
>> I didn't bother bringing this up before now because I figured support
>> just wasn't there in user space to make the effort worth while in the
>> kernel for Lucid. However, as noted, it would make things easier if
>> ubuntu shipped with the hid driver compiled as a module instead of
>> statically in the kernel. This is not only the case for ENAC's
>> multitouch work, but also for the magicmouse driver Jiri wrote. Perhaps
>> we should consider changing this?
>>
>> Thanks,
>> Chase
>>
>
Henrik Rydberg - March 5, 2010, 2:57 p.m.
> I didn't bother bringing this up before now because I figured support
> just wasn't there in user space to make the effort worth while in the
> kernel for Lucid. However, as noted, it would make things easier if
> ubuntu shipped with the hid driver compiled as a module instead of
> statically in the kernel. This is not only the case for ENAC's
> multitouch work, but also for the magicmouse driver Jiri wrote. Perhaps
> we should consider changing this?

Yes, the configuration of experimental dkms drivers broke when the hid module
got compiled into the kernel at approximately the same time (around 2.6.30) as
the level of detail of the kernel quirks changed. Compiling hid as a module
would indeed help.

Henrik
Jiri Kosina - March 8, 2010, 11:04 a.m.
On Thu, 4 Mar 2010, Stéphane Chatty wrote:

> > > 2. the addition of the device's (VendorID, ProductID) couple to a 
> > > black list in the hid subsystem's core, so that the new driver can 
> > > manage it. This involves changes in hid-ids.h and hid-core.c, for 
> > > every new driver.
> > 
> > If the non upstream drivers are sucked into staging I'm not sure how 
> > this could be handled. Staging drivers have kconfig entries so perhaps 
> > those can be used to add new entries to hid, not sure if that would be 
> > acceptable upstream.
> 
> Er, I'm not expert enough in kernel inclusion processes to answer this 
> one. I add Jiri Kosina to this reply, hoping he can help.

Hi,

I probably don't have full context here.

Do I understand it correctly that there are HID drivers which are not 
upstream yet, and you are planning to have them merged into 
drivers/staging first, because of their code quality?

If so, we'll indeed have to sort out the blacklist question somehow. 
Either some ifdef magic, or let userspace to unbind the driver through 
sysfs, or introduce some API to actually do the rebind ...

What are the drivers in question anyway? Maybe we could fix them quickly 
instead :)

Thanks,

Patch

diff --git a/include/linux/hid.h b/include/linux/hid.h
index b1344ec..5ad8e6e 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -663,7 +663,7 @@  struct hid_ll_driver {

 /* Applications from HID Usage Tables 4/8/99 Version 1.1 */
 /* We ignore a few input applications that are not widely used */
-#define IS_INPUT_APPLICATION(a) (((a >= 0x00010000) && (a <=
0x00010008)) || (a == 0x00010080) || (a == 0x000c0001) || ((a >=
0x000d0002) && (a <= 0x000d000
+#define IS_INPUT_APPLICATION(a) (a >= 0xd0002 && a <= 0xd0006)