It wasn't the debug interface I was looking for (its the HID debug
interface which filters packets) but it gives enough info to see whats
happening.
The device is stuck in mouse mode and only sending 5 byte mouse
packets. Its not responding to the standard Tablet PC request to go
into Wacom mode.
There is some unique command that probably needs to be sent to device
to switch modes but there is no way to guess this value.
You could see if Asus released the source code to their probably
custom wacom driver and use it.
Or if your able to get debugfs and usbmon working on Asus's original
Linux distro, you can monitor the USB packet it sends when you do a
rmmod followed by a insmod of their driver. Then we'd know what to
add to modern wacom drivers.
Without the info, I'm afraid we are at a dead end.
Chris
2012/1/4 Mike Rolland <none...@gmail.com>:
> well, i have no /sys/kernel/debug/usb/usbmon/2u but there is a
> /sys/kernel/debug/hid/0003\:0B05\:179F.0001/rdesc and
> /sys/kernel/debug/hid/0003\:0B05\:179F.0001/events
>
> events start from upleft corner to upright, bottom, bottom left and diagonal
> from upleft to bottom right.
> hope it helps
>
> M.
>
> Le mercredi 04 janvier 2012 à 12:56 +0400, Mike Rolland a écrit :
>
> Little trouble here...
> I've mounted debugfs, but usb dir just show devices list file.
> Have I to activate some other debug in kernel conf ? (this is a first time
> for me)
>
> Le mardi 03 janvier 2012 à 10:23 -0600, Chris Bagwell a écrit :
>
> 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
>
>
>
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
