On Tue, Jan 3, 2012 at 4:21 AM, Mike Rolland <none...@gmail.com> wrote:
> I was beginning to loose my self in all this advices.
> I had needs to clean my brain and go from start, so like suggest Chris, I
> revert all and change my kernel like this to separate multi device thing and
> clarify my-self :
>
> Index: drivers/hid/hid-ids.h
> ===================================================================
> --- drivers/hid/hid-ids.h
> +++ drivers/hid/hid-ids.h 2012-01-03 13:05:37.030924428 +0400
> @@ -135,6 +135,7 @@
> #define USB_DEVICE_ID_ASUSTEK_MULTITOUCH_YFO 0x0186
>
> #define USB_VENDOR_ID_ASUSTEK 0x0b05
> +#define USB_DEVICE_ID_ASUSTEK_DIGITIZER 0x179f
> #define USB_DEVICE_ID_ASUSTEK_LCM 0x1726
> #define USB_DEVICE_ID_ASUSTEK_LCM2 0x175b
>
> Index: drivers/hid/usbhid/hid-quirks.c
> ===================================================================
> --- drivers/hid/usbhid/hid-quirks.c
> +++ drivers/hid/usbhid/hid-quirks.c 2012-01-03 13:08:07.210924957 +0400
> @@ -91,6 +91,7 @@
> { USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_MULTI_TOUCH,
> HID_QUIRK_MULTI_INPUT },
> { USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_WIRELESS,
> HID_QUIRK_MULTI_INPUT },
> { USB_VENDOR_ID_SIGMA_MICRO, USB_DEVICE_ID_SIGMA_MICRO_KEYBOARD,
> HID_QUIRK_NO_INIT_REPORTS },
> + { USB_VENDOR_ID_ASUSTEK, USB_DEVICE_ID_ASUSTEK_DIGITIZER,
> HID_QUIRK_MULTI_INPUT }, /* experimental */
> { 0, 0 }
> };
>
> All reports are in the attached file because the 40ko mailing list limits.
> My conclusion are :
> Device is known as 2 devices.
> - touchscreen
> - mouse
> So, I wonder if we shouldn't point on 1 of this device to start Wacom driver
> change (or both, depends).The wacom driver has been coded such that it skips over that mouse device when querying the device and I *think* sends a command to device that says stop sending mouse data and start sending pen data (I'm not positive about this for TABLETPC's). > On the EeeNote webpage tablet is implicitly declare as a Wacom one, and > windows drivers for digitizer is from Wacom. There is no doubt about this. > > With experimental changes evtest stay squared in the left corner, and the > first time I launched after driver change cursor was effectively squared > there. It does do several things that seem like Wacom devices but I'm starting to suspect its a new version of hardware that sends a new packet format. > > Now, with revert to initial and quirk, mouse event are good and acts like > mouse cursor in a 1024x768 pixel rectangle (nearby). > Touchscreen mode report no events in evtest and really don't know how > configure it with evdev and Xorg, so I can't tell you more. This makes some sense I think. When an interface support multiple report types, it will send only the first one until something tells it to send the other type. I've seen some eGalax touchscreens that put the touchscreen first and mouse second so by default it sends touchscreen coordinates. Wacom devices have always put mouse first in HID reports I've seen. So I guess that means you will require a custom driver to set up your digitizer correctly and probably its the wacom driver where it needs to do this. > > Because there is no error in kernel compilation, I suppose I didn't make > mistakes with my change, I missed something and don't know what (probably > because I'm not a hacker, lol) > > M. > > note: evtestX reports events with modified wacom drv in long X movement. > evtestY, the same for Y movement. > The reports showed the X doing something reasonable but a little questionable while the Y log seemed totally wrong. Here is one more thing to try so that we can get some needed information. Hopefully, your distribution auto-mounts the /sys/kernel/debug filesystem. If not, you can google and see how to mount that. One of your earlier "lsusb" outputs showed that your device is on USB bus #2 and is device 008 on that bus. If you move things around, it can change so verify that is still true for next steps. Bus 002 Device 008: ID 0b05:179f ASUSTek Computer, Inc. You can log packets coming from USB bus #2 by running this as root: cat /sys/kernel/debug/usb/usbmon/2u | tee /tmp/usb2.log The pipe part is optional but I like to do that so I can see and log whats going on. If you have a lot of devices on that bus then the output could be noisy. You can usually filter the output to just your device #008 with grep: cat /sys/kernel/debug/usb/usbmon/2u | grep 2:008 | /tmp/usb2.log The lines that say "Ii:2:008" are interrupt packets coming from hardware. When you put pen on screen, you should see a burst of them. Can you send a few of those? Then we can see if if can reverse engineer the packet format. Chris ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
