Handling NextWindow Touchscreen (multitouch) via the nwfermi (proprietary) driver

[Jamie Lennox]

Binary package hint: xserver-xorg-input-evdev

Ubuntu 9.04/8.10 and probably other.

The NextWindow touch screen is used on the HP TouchSmart systems however doesn't work out of the box on 8.10 or 9.04.

Firstly it is allocated to a synaptic touchpad driver initially which is wrong, but can be overcome with the appropriate HAL fdi to change to evdev.

Secondly (and this is a most likely a problem of either the hardware or X), it reports X, Y values using ABS_RX, ABS_Z rather than the expected ABS_X, ABS_Y. The evtouch driver will work because it accepts these as alternatives.

Lastly, because the system is multi-touch aware it reports to the xserver that it has buttons. This causes it to be misclassified by evdev as a touchpad rather than a touchscreen.

The following patch fixes the problem for me but is obviously not a general solution. This is against packaged version 1:2.1.1-1ubuntu4:

--- src/evdev.c.orig 2010-05-22 16:08:14.000000000 +1000
+++ src/evdev.c 2009-05-22 16:09:30.000000000 +1000
@@ -382,10 +382,12 @@

  case EV_ABS:
      switch (ev.code) {
+ case ABS_Z:
      case ABS_X:
   pEvdev->abs_x = value;
   abs = 1;
   break;
+ case ABS_RX:
      case ABS_Y:
   pEvdev->abs_y = value;
   abs = 1;
@@ -1368,11 +1370,11 @@
         xf86Msg(X_INFO, "%s: Found x and y absolute axes\n", pInfo->name);
  pEvdev->flags |= EVDEV_ABSOLUTE_EVENTS;
  if (TestBit(BTN_TOUCH, key_bitmask)) {
- if (num_buttons) {
+/* if (num_buttons) {
                 xf86Msg(X_INFO, "%s: Found absolute touchpad\n", pInfo->name);
                 pEvdev->flags |= EVDEV_TOUCHPAD;
                 pEvdev->old_x = pEvdev->old_y = -1;
- } else {
+ } else */ {
                 xf86Msg(X_INFO, "%s: Found absolute touchscreen\n", pInfo->name);
                 pEvdev->flags |= EVDEV_TOUCHSCREEN;
                 pEvdev->flags |= EVDEV_BUTTON_EVENTS;

ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 9.04
NonfreeKernelModules: nvidia
Package: xserver-xorg-input-evdev 1:2.1.1-1ubuntu4 [modified: usr/lib/xorg/modules/input/evdev_drv.so]
ProcEnviron:
 LANG=en_AU.UTF-8
 SHELL=/bin/bash
ProcVersion: Linux version 2.6.28-11-generic (buildd@crested) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #42-Ubuntu SMP Fri Apr 17 01:58:03 UTC 2009
SourcePackage: xserver-xorg-input-evdev
Uname: Linux 2.6.28-11-generic x86_64

[komputes (komputes)]

We can confirm this with HP TouchSmart dx9000 which has the unnamed touchscreen device on the USB bus as ID "1926:0003". This touchscreen does not work out of the box. I figure "1926:0003" is the touchscreen since it shows up in dmesg as NextWindow Touchscreen:

[ 7.762373] usbcore: registered new interface driver hiddev
[ 7.767059] input: NextWindow Touchscreen as /devices/pci0000:00/0000:00:1d.0/usb6/6-1/6-1:1.0/input/input3
[ 7.769073] generic-usb 0003:1926:0003.0001: input,hidraw0: USB HID v1.00 Keyboard [NextWindow Touchscreen] on usb-0000:00:1d.0-1/input0
[ 7.771743] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/device:23/input/input4
[ 7.776112] generic-usb 0003:1926:0003.0002: hiddev96,hidraw1: USB HID v1.00 Device [NextWindow Touchscreen] on usb-0000:00:1d.0-1/input1
[ 7.777120] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
[ 7.780169] input: NextWindow Touchscreen as /devices/pci0000:00/0000:00:1d.0/usb6/6-1/6-1:1.2/input/input5
[ 7.784108] generic-usb 0003:1926:0003.0003: input,hiddev97,hidraw2: USB HID v1.00 Mouse [NextWindow Touchscreen] on usb-0000:00:1d.0-1/input2

Jamie can you please confirm that
1) You have "1926:0003" as a device in your lsusb output (just making sure we have the same touchscreen)
2) Having xserver-xorg-input-evdev and xserver-xorg-input-evtouch allows you to use the touchscreen (regardless of the orientation issue)

Also, besides confirming these can you attach you dmesg and lsusb output.

Once complete, I will confirm this. Thanks!

Side note: USB ID should be named properly as "NextWindow Touchscreen" in the Linux USB ID database.

[Jamie Lennox (jamielennox)]

1926:003 is a device

[Jamie Lennox (jamielennox)]

/proc/bus/input/devices confirms that the device registers as NextWindow Touchscreen

[Jamie Lennox (jamielennox)]

dmesg (though older attached above)

[Jamie Lennox (jamielennox)]

I can confirm on hardy (haven't tried on jaunty) that evdev and evtouch can cooperate however the 11-x11-synaptics.fdi is assumed to be the driver.

I've also been using a different touchscreen on a different machine and used the same technique to fix it (see patch), so i was thinking that perhaps this was a kernel reporting issue as again the axis were incorrectly reported and synaptics then touchpad was assumed.

The current patch i'm using is attached which fixes at least the NextWindow, the eGalax is the other device though the egalax uses different axis again and requires xinput config to use.

Anything else i can do let me know.

[komputes (komputes)]

Thank you for your prompt response Jamie.

I have subscribed Bryce Harington, who can hopefully share his knowledge and shed some light on this bug.

Bryce, please let either Jamie or I know if anything else is needed to move this forward.

[komputes (komputes)]

Thank you for your prompt response Jamie.

I have subscribed Bryce Harrington, who can hopefully share his knowledge and shed some light on this bug.

Bryce, please let either Jamie or I know if anything else is needed to move this forward.

[Petteri Hirvonen (pete-sciwi)]

I've got the same kind of issue in jaunty. I have an open frame lcd touchscreen which identifies as "nextwindow touchscreen", it has got the same id 1926:0003 in lsusb without a name. I guess it is manyfactured by chi lin tech.
http://www.chilintech.com.tw/index.asp?le=english
What can i do to make it work, how to use the patch?

[Petteri Hirvonen (pete-sciwi)]

I just installed karmic, same issue..

[akoutsoulelos (akoutsoulelos)]

I've just installed 9.10 on the new HP Touchsmart 600-1050, facing the same problem, though the touchscreen is pointed as "1926:0006" on bus 003 device 004 (usb). Also no input is connected to the device and no device is created.

I also tried newer kernel (2.6.32.2) but with no success...

[Timo Aaltonen (tjaalton)]

Please try with a lucid livecd.

[Lance R. Vick (lrvick)]

Also can confirm akoutsoulelos post on my HP Touchsmart 600-1050.

Will try lucid livecd soon...

[Lance R. Vick (lrvick)]

Writing this from a lucid livecd.

Only thing dmesg had to say was:

[ 7.155279] generic-usb 0003:1926:0006.0003: hiddev97,hidraw2: USB HID v1.11 Device [NextWindow Touchscreen] on usb-0000:00:04.0-7/input1

Sadly touch is not working and catting /dev/input/event1 gives me no output.

I will go ahead and dump everything in case someone sees something I do not.

[Ignacio Huerta (iox8)]

I have a Dell Inspiron One Touch with Nextwindow Touchscreen. Sadly, I believe it is a different model as lsusb reports:

Bus 002 Device 002: ID 1926:007a

I have managed to make it appear in /dev/input/event6 with the commands:

sudo modprobe usbtouchscreen
sudo sh -c "echo 1926 007a > /sys/bus/usb/drivers/usbtouchscreen/new_id"

After that, I've tried evtest:

evtest /dev/input/event6

But the screen is sending no input when I touch it. I'm not sure if my problem is from xserver-xorg-input-evdev package, or maybe usbtouchscreen module. Any idea?

[Lance R. Vick (lrvick)]

Update:

I poked around in a set of vanilla 2.6.33-rc4 kernel sources and found that the ONLY NextWindow device listed in drivers/hid/usb-hids.c is 1926:0003. I swapped that to 1926:0006, recompiled, then ran:

sudo sh -c "echo 1926 0006 > /sys/bus/usb/drivers/usbtouchscreen/new_id"

And I get an event6 that I can actually cat output from on touch, which is a start!

[Lance R. Vick (lrvick)]

Just ran evtest.

Spams random values so fast it is hard to tell it is even responding to touch... but... it stops after a while when i stop touching it, and starts up again the instant i touch it ;-)

The values are all over the place from 1 to 1071 for x and 200 to 600 for y though.

Though the "Touch" events do indeed start and stop based on me touching or not touching, they do not seem to have anything to do with _where_ I touch and seem almost totally random.

[Liam Manderson (liam-icb)]

Similar to Lance, using the I managed to get my touchscreen running as event7 and I can cat output, but when I run evtest on it, it reacts to my touching the screen, but the output values seem random. I remember reading (addmitedly for an earlier model nextwindow touchscreen) that some patching of evtouch was necessary to deal with its multitouch input.

Has there been any movement on this issue?

[Liam Manderson (liam-icb)]

Since my last post I have been trying out the ubuntu 10.04 alpha3 live cd (on my hp touchsmart 600-1050). Once again by running:

sudo sh -c "echo 1926 0006 > /sys/bus/usb/drivers/usbtouchscreen/new_id"

I get the touchscreen registering as event7 and I can get output via cat and evtest. Unlike in 9.10, the when I touch the screen it does trigger cursor movement and clicks but once again they seem to be more or less random. The only pattern being that it starts and stops when I touch the screen.

[Ignacio Huerta (iox8)]

Update:

After exchanging a few emails with NextWindow support, they finally sent me a driver, a "prototype written for ubuntu". I'm attaching the file they sent me. I don't have much information about it, but it works great with Ubuntu Karmic i386! These are the steps I took:

- Install Ubuntu 9.10 i386.

- Install the driver (nwfermi-0.1_i383.deb)

- Install some extra software: joystick (for testing) and xserver-xorg-input-evtouch.

- Load the module:
     sudo modprobe nw-fermi

- Activate the input device:
     sudo sh -c "echo 1926 007a > /sys/bus/usb/drivers/nwfermi/new_id"

- After this, the device "/dev/input/event6" is working. Testing:
     sudo evtest /dev/input/event6

- Restart Xorg (restart the session)

Moreover, I tweaked to work after reboot:

- Add "nw-fermi" to /etc/modules

- Add boot script to /etc/rc.local
        sh -c "echo 1926 007a > /sys/bus/usb/drivers/nwfermi/new_id"

I hope this works for someone, I had never seen "nw-fermi" before. If it's new code, we should probably ask NextWindow to release the code.

[HolySmoke (7-admin-localhorst-tv)]

I can confirm that these exact steps do work for the NextWindow 0x007a (as built into the Dell Inspiron One) in a current Jaunty build.

Big thanks to iox

[Ignacio Huerta (iox8)]

You are welcome!

I just wrote to NextWindow confirming their prototype driver is working on 1926:007a, and asking them to release the code/info. Let's see what happens :).

[Ignacio Huerta (iox8)]

NextWindow's answer: "the code will contain some very highly sensitive intellectual property". So they are not planning to release the code. That's bad news :(.

Well, maybe someone can use the closed source driver to code an open one. What I'm gonna do right now is to give them some ideas about software patents. I invite anyone to copy-paste http://www.gnu.org/philosophy/fighting-software-patents.html and send it to <email address hidden>. Share the code!

[djp (djpnewton)]

Hi guys,

I just want to clarify for everyone that there are two classes of Nextwindow Touchscreens here.

1) 1900 Model, usb id: 1926:0003

  These touchscreens have a standard mouse and digitizer HID data supplied from the device and can be used with evdev or evtouch drivers.

2) 1950 Model, usb ids 1926:0006,~0060-0099

  There are a bunch of different hardware ids in this class (above is a rough range). These touchscreens are kinda like the winmodems of the touchscreen world (hence the need for nwfermi).

Let me know if you have any questions.

Cheers

Dan

[robireland (rob-robscreative)]

Hi Dan,
How do I get the touchscreen working on my touchsmart 300-1000 which is showing up as 1926:0006

cheers
rob

[djp (djpnewton)]

Hi Rob,

all you should need to do is install the nwfermi package attached to message #31 of this bug.

After that it should work (you might need to reboot, or insmod the driver and restart X)

If you have a 1950 device that isnt 1926:0006 you will have to follow the other instructions in message #31 (adding the hardware ID to /sys/bus/usb/drivers/nwfermi/new_id)

[robireland (rob-robscreative)]

Thanks for the quick reply, Dan.

I tried the different installs, and I get the same thing regardless. It works for anything from a couple of seconds to a couple of minutes. Then the mouse buttons stop working and a few seconds later machine just stops dead and won't accept any input from anything forcing me to do a hard reboot.

[Ignacio Huerta (iox8)]

Looks like a problem with nwfermi :(. You could try writing to NextWindow to see if they send you a better driver: <email address hidden>

[djp (djpnewton)]

Hmm there is probably a bug with one of the driver locks (if anyone wants to
help review the code the source to the kernel module is included with the
nwfermi package)

What kernel are you using?

On Tue, Apr 6, 2010 at 1:11 PM, robireland <email address hidden> wrote:

> Thanks for the quick reply, Dan.
>
> I tried the different installs, and I get the same thing regardless. It
> works for anything from a couple of seconds to a couple of minutes.
> Then the mouse buttons stop working and a few seconds later machine just
> stops dead and won't accept any input from anything forcing me to do a
> hard reboot.
>
> --
> Handling NextWindow Touchscreen (multitouch)
> https://bugs.launchpad.net/bugs/379313
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “xserver-xorg-input-evdev” package in Ubuntu: Incomplete
>
> Bug description:
> Binary package hint: xserver-xorg-input-evdev
>
> Ubuntu 9.04/8.10 and probably other.
>
> The NextWindow touch screen is used on the HP TouchSmart systems however
> doesn't work out of the box on 8.10 or 9.04.
>
> Firstly it is allocated to a synaptic touchpad driver initially which is
> wrong, but can be overcome with the appropriate HAL fdi to change to evdev.
>
> Secondly (and this is a most likely a problem of either the hardware or X),
> it reports X, Y values using ABS_RX, ABS_Z rather than the expected ABS_X,
> ABS_Y. The evtouch driver will work because it accepts these as
> alternatives.
>
> Lastly, because the system is multi-touch aware it reports to the xserver
> that it has buttons. This causes it to be misclassified by evdev as a
> touchpad rather than a touchscreen.
>
> The following patch fixes the problem for me but is obviously not a general
> solution. This is against packaged version 1:2.1.1-1ubuntu4:
>
> --- src/evdev.c.orig 2010-05-22 16:08:14.000000000 +1000
> +++ src/evdev.c 2009-05-22 16:09:30.000000000 +1000
> @@ -382,10 +382,12 @@
>
> case EV_ABS:
> switch (ev.code) {
> + case ABS_Z:
> case ABS_X:
> pEvdev->abs_x = value;
> abs = 1;
> break;
> + case ABS_RX:
> case ABS_Y:
> pEvdev->abs_y = value;
> abs = 1;
> @@ -1368,11 +1370,11 @@
> xf86Msg(X_INFO, "%s: Found x and y absolute axes\n", pInfo->name);
> pEvdev->flags |= EVDEV_ABSOLUTE_EVENTS;
> if (TestBit(BTN_TOUCH, key_bitmask)) {
> - if (num_buttons) {
> +/* if (num_buttons) {
> xf86Msg(X_INFO, "%s: Found absolute touchpad\n",
> pInfo->name);
> pEvdev->flags |= EVDEV_TOUCHPAD;
> pEvdev->old_x = pEvdev->old_y = -1;
> - } else {
> + } else */ {
> xf86Msg(X_INFO, "%s: Found absolute touchscreen\n",
> pInfo->name);
> pEvdev->flags |= EVDEV_TOUCHSCREEN;
> pEvdev->flags |= EVDEV_BUTTON_EVENTS;
>
> ProblemType: Bug
> Architecture: amd64
> DistroRelease: Ubuntu 9.04
> NonfreeKernelModules: nvidia
> Package: xserver-xorg-input-evdev 1:2.1.1-1ubuntu4 [modified:
> usr/lib/xorg/modules/input/evdev_drv.so]
>...

[WebNuLL (babciastefa)]

Im waiting for multi-touch too. But i think its difficult to implement. It can take a long time to bring multi-pointer support to this driver.

[WebNuLL (babciastefa)]

Working on 2.6.37-2 kernel

[WebNuLL (babciastefa)]

http://www.youtube.com/watch?v=Z7djhhEjxJ0

[Bryce Harrington (bryce)]

Chase - could you take a look at this bug report and let us know how it fits with the multitouch development efforts?

[Chase Douglas (chasedouglas)]

This bug has a lot of data and comments in it. Could someone provide a summary of where things stand? What does this bug represent at this point? Is this bug really against 11.04 now, or are people looking for support for previous Ubuntu releases?

Thanks

[Bryce Harrington (bryce)]

On Tue, Nov 30, 2010 at 05:56:35PM -0000, Chase Douglas wrote:
> This bug has a lot of data and comments in it. Could someone provide a
> summary of where things stand? What does this bug represent at this
> point? Is this bug really against 11.04 now, or are people looking for
> support for previous Ubuntu releases?

Well, I'm mainly interested in what the support situation for this
hardware should be in 11.04 and going forward, as I doubt any of this
would qualify for SRU.

Chase, key comments to look at here appear to be:
  Proprietary driver: #31 (original) and 89-90 (latest)
  evdev patches: #81

I'm not sure what the restrictions are on the proprietary driver as far
as redistribution and so on, but the question is whether the MT work
you're doing will cover this hardware sufficiently by itself?

If not, then what would you need from the hardware vendor to include
support in evdev/linux?

If including support in the open does not look feasible for now, do you
have any thoughts on the proprietary driver?

[Chase Douglas (chasedouglas)]

Thanks Bryce!

The MT work in X has taken a different form from what was proposed in the message linked in comment #31. However, we are getting near to having an XI 2.1 protocol extension for MT set. I hope to introduce some of the MT work into Natty soon.

Kernel drivers need to be written for the MT evdev protocol to work properly. Either the slotted or non-slotted protocol will work, though slotted is better. If the kernel presents working MT evdev data, it will work with the X MT solution. It sounds like the NextWindow proprietary driver does not handle MT data quite yet though. The proprietary nature of the driver will have no affect on its ability to function in the MT stack in ubuntu.

Proprietary MT drivers will always be a second class citizen on Ubuntu because they are not installed by default. In fact, this is the first time I've ever heard of a proprietary MT driver being used in Ubuntu. I would strongly recommend NextWindow to open the code or even just the specifications of the hardware so users have the best experience possible.

In short: Yes, the proprietary driver will work when it is updated for MT support. Nothing extra will be needed in evdev or elsewhere.

[WebNuLL (babciastefa)]

Question to author of this driver - there is any progress to bring multi-touch on this driver?

[djp (djpnewton)]

On Thu, Dec 2, 2010 at 1:31 AM, WebNuLL <email address hidden> wrote:

> Question to author of this driver - there is any progress to bring
> multi-touch on this driver?
>
>
Yes, this is going to be my priority now over the next few weeks

[Mohamed IKBEL Boulabiar (boulabiar)]

On Wed, Dec 1, 2010 at 9:24 PM, djp <email address hidden> wrote:
> On Thu, Dec 2, 2010 at 1:31 AM, WebNuLL <email address hidden> wrote:
>
>> Question to author of this driver - there is any progress to bring
>> multi-touch on this driver?
>>
>>
> Yes, this is going to be my priority now over the next few weeks

2 weeks ago I asked NextWindow and they answered me here:
http://twitter.com/#!/NextWindow/status/5389587354484736

i

[WebNuLL (babciastefa)]

Dnia 2010-12-01, śro o godzinie 20:24 +0000, djp pisze:
> On Thu, Dec 2, 2010 at 1:31 AM, WebNuLL <email address hidden> wrote:
>
> > Question to author of this driver - there is any progress to bring
> > multi-touch on this driver?
> >
> >
> Yes, this is going to be my priority now over the next few weeks
>

Thank you, im waiting for it.

[Bryce Harrington (bryce)]

Thanks Chase. It sounds like support on the open source has some blockers, so for this bug report let's focus on the nwfermi driver.

@djp, thanks for posting the .debs. It appears this contains a GPL'd kernel driver installable via dkms, and a closed binary nwfermi_daemon which is invoked using udev. Can you specify what the distribution terms are for nwfermi_daemon? Is it permissible for us to package and ship it in Ubuntu as a closed source driver?

Because this driver does not depend on anything particular on the X side, I guess xserver-xorg-input-evdev is not the best component for it to be filed against, but I'm not certain of what package would be better (linux?) so will leave it here for now.

[Bryce Harrington (bryce)]

djp, you mentioned earlier an interest in posting this to a PPA. Do you need help with this? Do you have a plan in place for how you want to be distributing it to go into the PPA?

I think once that is sorted out, it would make it straightforward for us to even consider incorporating this into multiverse with other closed source drivers, which would make it even easier for Ubuntu users to install it. I'm not sure what the process is for getting additional closed source drivers accepted there, so that may or may not be feasible, but once it's packaged for PPA I'd be willing to investigate for you, if you'd like.

[djp (djpnewton)]

@Bryce,

Yes some pointers on PPA packaging would be appreciated.

I will check what the distribution terms are and get back to you.

Thanks a lot,
Dan

On Fri, Dec 3, 2010 at 1:47 PM, Bryce Harrington
<email address hidden>wrote:

> djp, you mentioned earlier an interest in posting this to a PPA. Do you
> need help with this? Do you have a plan in place for how you want to be
> distributing it to go into the PPA?
>
> I think once that is sorted out, it would make it straightforward for us
> to even consider incorporating this into multiverse with other closed
> source drivers, which would make it even easier for Ubuntu users to
> install it. I'm not sure what the process is for getting additional
> closed source drivers accepted there, so that may or may not be
> feasible, but once it's packaged for PPA I'd be willing to investigate
> for you, if you'd like.
>
> ** Summary changed:
>
> - Handling NextWindow Touchscreen (multitouch)
> + Handling NextWindow Touchscreen (multitouch) via the nwfermi
> (proprietary) driver
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/379313
>
> Title:
> Handling NextWindow Touchscreen (multitouch) via the nwfermi (proprietary)
> driver
>
> Status in “xserver-xorg-input-evdev” package in Ubuntu:
> Triaged
>
> Bug description:
> Binary package hint: xserver-xorg-input-evdev
>
> Ubuntu 9.04/8.10 and probably other.
>
> The NextWindow touch screen is used on the HP TouchSmart systems however
> doesn't work out of the box on 8.10 or 9.04.
>
> Firstly it is allocated to a synaptic touchpad driver initially which is
> wrong, but can be overcome with the appropriate HAL fdi to change to evdev.
>
> Secondly (and this is a most likely a problem of either the hardware or X),
> it reports X, Y values using ABS_RX, ABS_Z rather than the expected ABS_X,
> ABS_Y. The evtouch driver will work because it accepts these as
> alternatives.
>
> Lastly, because the system is multi-touch aware it reports to the xserver
> that it has buttons. This causes it to be misclassified by evdev as a
> touchpad rather than a touchscreen.
>
> The following patch fixes the problem for me but is obviously not a general
> solution. This is against packaged version 1:2.1.1-1ubuntu4:
>
> --- src/evdev.c.orig 2010-05-22 16:08:14.000000000 +1000
> +++ src/evdev.c 2009-05-22 16:09:30.000000000 +1000
> @@ -382,10 +382,12 @@
>
> case EV_ABS:
> switch (ev.code) {
> + case ABS_Z:
> case ABS_X:
> pEvdev->abs_x = value;
> abs = 1;
> break;
> + case ABS_RX:
> case ABS_Y:
> pEvdev->abs_y = value;
> abs = 1;
> @@ -1368,11 +1370,11 @@
> xf86Msg(X_INFO, "%s: Found x and y absolute axes\n", pInfo->name);
> pEvdev->flags |= EVDEV_ABSOLUTE_EVENTS;
> if (TestBit(BTN_TOUCH, key_bitmask)) {
> - if (num_buttons) {
> +/* if (num_buttons) {
> xf86Msg(X_INFO, "%s: Found absolute touchpad\n",
> pInfo->name);
> pEvdev->flags |= EVDEV_TOUCHPAD;
> pEvdev->old_x ...

[Bryce Harrington (bryce)]

Hi djp,

Since PPAs require uploading source packages rather than pre-built debs, what you'll need to do is create a wrapper source package, that contains the precompiled binaries. The "build" process for this package would merely copy the appropriate binary into place.

I don't know if there is official documentation for doing this, but here's a guide that explains it with examples:

http://www.debian-administration.org/articles/529

Hope this helps, let me know if you have more questions.

[Mathijs (c-launchpad-thijsje-nl)]

Hi,

@djp: Can you perhaps give a status update of the nw-fermi driver that includes mutlitouch capabilities?
@djp: have you also looked at the nwtool? It says it is able to set modes and save settings, (like those modes described in the Windows API).
You can find nwtool here: https://patchwork.kernel.org/patch/64411/

Regards,

Mathijs

[WebNuLL (babciastefa)]

djp, can you also add calibration possibility via xinput?

I can calibrate eGalax touchscreen in Samsung Q1 Tablet PC with this command:
xinput set-int-prop "Touchkit HID-USB Touchscreen" "Evdev Axis Calibration" 32 80 3950 150 3900

It works perfectly, can it be possible with nwfermi?

Im installing Gentoo today, i dont know nwfermi will works correctly on it, can you implement calibration function to driver?

[WebNuLL (babciastefa)]

Im now using NextWindow touchscreen on Gentoo Linux and it works fine.
Its not callibrated (on Ubuntu too) - i can touch all but corners of screen.

[Aymeric (mulx)]

After installing the nwfermi package on Ubuntu 10.04 my Samsung 22” Lapfit Touchscreen Monitor (LD220Z) work with the touchscreen.
Like #118 it's not calibrated, I can touch the left corners but not the right.
From the documentation of my screen, it seem to be multi-touch, but I don't know what application I can use to know if multi-touch work or not, so it's untested.

[djp (djpnewton)]

@Bryce, cheers that is helpful I will try to make a PPA early next year. I do have one question, is it possible to put a EULA type agreement (do not sue us etc) into a deb or PPA?

@Mathijs, there will a multitouch release in January, I havent seen nwtool but I will take a look

@WebNuLL @ Aymeric, we already have a calibration facility, I will explain how to use it in this new release

I am attaching fermi 0.4.5, the main fixes here are:
  - nwfermi_daemon udev coldboot doesnt always work
  - configuration settings are available via named pipe

To start the calibration procedure run the following command:
  ‘echo -e "C\x02\x21\x01" > /tmp/nwfermi0-tl-in’

The cursor will move to four locations around the screen and to complete calibration you just need to touch and hold at the cursor positions untill they move to the next location. Upon successful calibration settings will be saved to "/etc/nextwindow/nw-fermi/XXXX_XXXXXX_DriverSettings.dat", you can delete this file to return to factory defaults.

I hope this is helpful you all.

Cheers,
Dan

[WebNuLL (babciastefa)]

I compiled kernel module, copied to /lib/modules/2.6.36-gentoo-r5/kernel/drivers/usb/nw-fermi.ko where i had old module.

killall nwfermi_daemon -9
rmmod nw-fermi
modprobe nw-fermi

The mouse automaticaly is moving fastly from down right to up left corner very fast when i touch some point on screen i got old calibration and screen working normally without any changes on calibration.

I will try today on Ubuntu (i have dualboot with Gentoo) to check whats wrong.

[Jiandong Zheng (ezjd)]

What is the purpose of the user space daemon (nwfermi_daemon) since driver already uses event interface? As I am trying to use Dell touch screen monior with ARM dev board, it won't work for me because I can't find the armel daemon.

djp, can you also release armel deb?

Thanks!

[Bryce Harrington (bryce)]

On Fri, Dec 24, 2010 at 02:28:50AM -0000, djp wrote:
> @Bryce, cheers that is helpful I will try to make a PPA early next year.
> I do have one question, is it possible to put a EULA type agreement (do
> not sue us etc) into a deb or PPA?

You can put it into the deb.

The PPA has a description field, but it's purely informational and
doesn't support click-thru-agreement type behavior. It's good for
putting directions or caveats.

Regarding EULAs in debs, I've never done this myself, but you can put a
question into the preinst script. Some more info (and a tutorial):

  http://stackoverflow.com/questions/2154352/including-license-agreement-in-deb-file

Not sure how that'd work in conjunction with a PPA, so you'll want to
test it. IIRC, it just does a text prompt on the command line, but
hopefully that'll get you in the right direction.

Some packages like mscorefonts and iirc some java packages include
install-time eula agreements, which might be worth studying. Fwiw I
think fglrx and nvidia do *not* require click thru's, but I'm not sure
how they handle the EULA agreement - perhaps the way they solved it
would be worth looking at as an alternate approach.

[Bryce Harrington (bryce)]

Alright, I'm going to move this bug report off -evdev and back to just xorg for now (actually I think it really should belong to the kernel, but we'll continue tracking it with X for now).

It sounds like this package will be requiring an EULA, which makes me doubtful it's something we can distribute with Ubuntu itself. Thus I'll decline the nominations and drop the natty tag for now.

[Bryce Harrington (bryce)]

djp, I would recommend that you create a nwfermi project in launchpad for tracking the driver. You can do this here:

https://launchpad.net/projects/+new

It's pretty easy, and I'd do it for you but I think you'd be better as the owner of it so you have full control.

Once you have a project set up, you can attach one or more PPAs to it, and we can move this bug report over to it. It will have its own bug tracker, and you can add public or private mailing lists if you'd like. It should be straightforward but if you have any questions, feel free to contact me directly.

[djp (djpnewton)]

Ok I have created a launchpad project for nwfermi (https://launchpad.net/nwfermi). Future nwfermi releases will be posted there and anyone interested should be able to post bug reports, questions, etc.

I havent made much progress with creating a source package for the ppa yet (the various different tools and methods are overwhelming me!) but should have a multitouch release ready shortly.

Cheers again for all the help Bryce.

[djp (djpnewton)]

A annoncement for anyone who was waiting for multitouch support. There is now a new release (0.5) at https://launchpad.net/nwfermi/trunk/nwfermi0.5

[WebNuLL (babciastefa)]

I tested nwfermi0.5 on Ubuntu and Gentoo Linux but multi-touch is still not working.

My device:
Bus 001 Device 008: ID 1926:0086 NextWindow 1950 HID Touchscreen

I just see single mouse, cant touch more than one point on screen - its looks like single touch.

On Ubuntu i just installed package and restarted computer, on Gentoo Linux i copied all files, built kernel module, modified xorg configuration - it should work but it isn't.

[Aymeric (mulx)]

Same as WebNuLL, on Ubuntu Lucid after installing package and restarted computer, multitouch don't work.

[WebNuLL (babciastefa)]

Here is /var/log/Xorg.0.log

Xorg recognizing device, but i think it not classifying it as multi-touch capable.

[WebNuLL (babciastefa)]

I tried many combinations of input xorg settings in 70-nwfermi.conf but it still doesn't work.

Any help?

[WebNuLL (babciastefa)]

Im not a C programmer but i debugged the code, and found that kernel module is always handling touchscreen as mouse.

[djp (djpnewton)]

As far as I know the X included with ubuntu does not handle multitouch input directly. Ubuntu has a multitouch framework called uTouch (not installed on the desktop edition by default (https://wiki.ubuntu.com/Multitouch).

If you want to relatively easily test if the kernel multitouch information is being supplied a good example is the PyMT demo (https://wiki.ubuntu.com/Multitouch/PyMT).

Although my X input driver might be blocking the gesture daemon somehow...

Anyhow post bug reports at https://bugs.launchpad.net/nwfermi

[Chase Douglas (chasedouglas)]

djp,

For full multitouch support both in Ubuntu 10.10 and future releases, the X evdev input module should be used. In 10.10 this will enable support for the uTouch stack, and in 11.04 this will allow for multitouch support through the X window system.

One should not need to use a different X input module. If you are using a different X input module, please provide more information so we can figure out the best way forward.

Just to clarify, Ubuntu 10.10 desktop edition has uTouch support as well, but the only package with uTouch integration is the Unity window manager. Since Unity doesn't come with 10.10 by default, it seems like uTouch is missing even though it's still there :). Natty will have more integration across multiple apps, and the desktop edition will ship Unity by default too.

Thanks!

[Bryce Harrington (bryce)]

Moving this bug report from 'xorg' to the new 'nwfermi' project. At this time this driver is not shipped with the ubuntu distribution but rather provided by a PPA, so support will be at https://bugs.launchpad.net/nwfermi/ and the Ubuntu distro task is a 'Wont Fix'. (Actually, maybe some day it will be included in ubuntu once distribution terms are sorted and so on, but that bridge can be crossed in its own time.)

I would recommend people file reports about new issues as new bugs rather than adding to this bug report. I expect djp will prefer to close this bug report now that the issues can be handled individually, but I'll leave that to him. :-)
https://bugs.launchpad.net/nwfermi/+filebug

[WebNuLL (babciastefa)]

Ubuntu, and Ubuntu but how about Gentoo? How i can run this driver on other Linux based operating systems for desktop x86/amd64 computers?

[Tom Dickson (8-launchpad-bombcar-com)]

Has anyone been able to get this to work on 10.04-1 x64? I had it working in 32 mode, but now I can't seem to get it to work on the Sony VAIO VPCL135FX. My Xorg.log shows:

(II) config/udev: Adding input device Nextwindow Fermi Touchscreen (/dev/input/event10)
(**) Nextwindow Fermi Touchscreen: Applying InputClass "evdev pointer catchall"
(**) Nextwindow Fermi Touchscreen: Applying InputClass "nw fermi"
(II) LoadModule: "nextwindow"
(II) Loading /usr/lib/xorg/modules/input/nextwindow_drv.so
(II) Module nextwindow: vendor="X.Org Foundation"
 compiled for 1.9.0, module version = 0.0.1
 Module class: X.Org XInput Driver
 ABI class: X.Org XInput driver, version 11.0
(WW) module ABI major version (11) doesn't match the server's version (7)
(**) Option "Device" "/dev/input/event10"
(II) Nextwindow Fermi Touchscreen: Using device /dev/input/event10.
(**) Option "UseTouchHelp" "1"
(II) Nextwindow Fermi Touchscreen: Using touch help.
(**) Option "DragThreshold" "10"
(**) Option "RightClickTimeout" "1200"
(**) Option "DoubleClickTimeout" "500"
(**) Nextwindow Fermi Touchscreen: always reports core events
(II) XINPUT: Adding extended input device "Nextwindow Fermi Touchscreen" (type: TOUCHSCREEN)
(II) Nextwindow Fermi Touchscreen: On.
(II) config/udev: Adding input device Nextwindow Fermi Touchscreen (/dev/input/js0)
(II) No input driver/identifier specified (ignoring)
(II) config/udev: Adding input device Nextwindow Fermi Touchscreen (/dev/input/mouse3)
(II) No input driver/identifier specified (ignoring)
(II) config/udev: Adding input device Macintosh mouse button emulation (/dev/input/event2)
(**) Macintosh mouse button emulation: Applying InputClass "evdev pointer catchall"
(**) Macintosh mouse button emulation: always reports core events
(**) Macintosh mouse button emulation: Device: "/dev/input/event2"
(II) Macintosh mouse button emulation: Found 3 mouse buttons
(II) Macintosh mouse button emulation: Found relative axes
(II) Macintosh mouse button emulation: Found x and y relative axes
(II) Macintosh mouse button emulation: Configuring as mouse
(**) Macintosh mouse button emulation: YAxisMapping: buttons 4 and 5
(**) Macintosh mouse button emulation: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
(II) XINPUT: Adding extended input device "Macintosh mouse button emulation" (type: MOUSE)
(II) Macintosh mouse button emulation: initialized for relative axes.
(II) config/udev: Adding input device Macintosh mouse button emulation (/dev/input/mouse0)
(II) No input driver/identifier specified (ignoring)
(II) config/udev: Adding input device Sony Vaio Jogdial (/dev/input/event9)
(II) No input driver/identifier specified (ignoring)
(II) config/udev: Adding input device Sony Vaio Jogdial (/dev/input/mouse2)
(II) No input driver/identifier specified (ignoring)

but nothing seems to work.

[djp (djpnewton)]

@Chase,

Thanks for the info. My xorg input module has a touch helper to detect right clicks etc (like the tablet pc service in windows), I am trying to get permission to convert this into a patch for possible inclusion into xorg evdev. I saw your evdev hooks into grails and have been testing the same with my driver but in the future hope to be able to use evdev directly.

@Bryce, cheers

@All,

I am closing this bug now. Please feel free to log individual questions or issues:
 - https://bugs.launchpad.net/nwfermi
 - https://answers.launchpad.net/nwfermi