| Message ID | 43e72e891003040120o497814aap4d1ef7f772cf8773@mail.gmail.com |
|---|---|
| State | RFC |
| Headers | show |
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 >
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 >>
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
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.
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
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 >> >
> 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
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,
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)