NextWindow product ID 025a

try:
  echo 1926 025a > /sys/bus/usb/drivers/nwfermi/new_id

Thanks for lending the advice.

That didn't seem to have any effect. Would that alter whether the kernel reports multi-touch events? At present, I'm not seeing any. The touchpanel shows up as two devices, the first of which (/dev/input/input2) is multi-touch but reports no events, and the second which (/dev/input/input3) is a single-touch absolute pointing device that does:

  $ dmesg | grep -ie nextwindow
  [ 2.430572] input: NextWindow Touchscreen as /devices/pci0000:00/0000:00:12.0/usb4/4-1/4-1:1.1/input/input2
  [ 2.431557] generic-usb 0003:1926:025A.0002: input,hiddev0,hidraw0: USB HID v1.11 Device [NextWindow Touchscreen] on usb-0000:00:12.0-1/input1
  [ 2.436815] input: NextWindow Touchscreen as /devices/pci0000:00/0000:00:12.0/usb4/4-1/4-1:1.2/input/input3
  [ 2.437245] generic-usb 0003:1926:025A.0003: input,hidraw1: USB HID v1.11 Mouse [NextWindow Touchscreen] on usb-0000:00:12.0-1/input2

  $ sudo evtest /dev/input/event2
  Input driver version is 1.0.1
  Input device ID: bus 0x3 vendor 0x1926 product 0x25a version 0x111
  Input device name: "NextWindow Touchscreen"
  Supported events:
    Event type 0 (EV_SYN)
    Event type 3 (EV_ABS)
      Event code 47 (ABS_MT_SLOT)
      Event code 48 (ABS_MT_TOUCH_MAJOR)
      Event code 49 (ABS_MT_TOUCH_MINOR)
      Event code 50 (ABS_MT_WIDTH_MAJOR)
      ...
  Testing ... (interrupt to exit)

No event data is reported here. Not a peep.

  $ sudo evtest /dev/input/event3
  Input driver version is 1.0.1
  Input device ID: bus 0x3 vendor 0x1926 product 0x25a version 0x111
  Input device name: "NextWindow Touchscreen"
  Supported events:
    Event type 0 (EV_SYN)
    Event type 1 (EV_KEY)
      Event code 272 (BTN_LEFT)
      Event code 273 (BTN_RIGHT)
    Event type 3 (EV_ABS)
      Event code 0 (ABS_X)
      Event code 1 (ABS_Y)
    Event type 4 (EV_MSC)
      Event code 4 (MSC_SCAN)
  Testing ... (interrupt to exit)
  Event: time 1337653958.697879, type 3 (EV_ABS), code 0 (ABS_X), value 17422
  Event: time 1337653958.697882, type 3 (EV_ABS), code 1 (ABS_Y), value 17178
  Event: time 1337653958.697883, -------------- SYN_REPORT ------------
  Event: time 1337653960.712081, type 3 (EV_ABS), code 0 (ABS_X), value 23156
  Event: time 1337653960.712087, type 3 (EV_ABS), code 1 (ABS_Y), value 15972
  Event: time 1337653960.712089, -------------- SYN_REPORT ------------
  Event: time 1337653960.826076, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90001
  Event: time 1337653960.826079, type 1 (EV_KEY), code 272 (BTN_LEFT), value 1
  ...

My apologies for all the inline data.

Is this normal? I am wrong in expecting to see evtest output from /dev/input/event2?

Ok, I added my model's USB ID to nw-fermi.c, and rebuilt and reinstalled the kernel module. Now when I boot, the nw_fermi module is loaded. Other than this, things seem the same. Xorg still uses evdev, unless I specify the nextwindow driver in xorg.conf. When I use the nextwindow Xorg driver, the single-touch pointer device (/dev/input/event3) works fine. The multi-touch device (/dev/input/event2) still shows no input events.

Question: should nwfermi_daemon be running? Should it be auto-starting? It isn't.

Short answer to original question: it doesn't need to.

This model is HID multi-touch compliant; it's just not recognized by default. Once hid-multitouch sees it, a third device that unifies the event properties of the first two is created (in my case /dev/input/event7), and you get multi-touch events. To get this, you need to add two file entries:

1. In /etc/modules, add:
  hid-multitouch

2. In /etc/rc.local, add:
  echo 3 1926 025a 1 > "/sys/module/hid_multitouch/drivers/hid:hid-multitouch/new_id"

The second entry is in the form: {bus} {vendor_id} {product_id} {mt_class}, where bus 3 is USB, and mt_class is a constant defined in /drivers/hid/hid-multitouch.c (MT_CLS_DEFAULT =1).

Hope this helps somebody.

Cheers to NextWindow for products that work with Linux, and people (person?) who support that!