Asus as released a product called "Eee Note" that contains a Wacom digitizer.
The product does run an embedded version of Linux but this tracker item is not related at all to that. Instead, the product supports a novel feature where if you hook up the tablet to a PC with a USB cable, it can be used like a traditional tablet with no screen.
With no custom driver, the tablet acts like a touchpad (if I recall correctly) but confuses Linux's hid-core evdriver to point its unlessable. It can be made useable with hid-core (acts like a touchpad) if you add the correct Product ID (0b05:179f) and quirk (HID_QUIRK_MULTI_INPUT) to overcome hid-core confusing it as a combo mouse with extra ABS X/Y axis.
Mark Rolland performed enough debugging to realize this device accepts the standard Feature Report #2 to go into Wacom packet mode and stop acting like a touchpad.
The stylus packet format is same size as other Tablet PC's which in turn almost exactly matches Bamboo stylus packets (see wacom_wac.c driver for minor differences in stylus buttons/eraser logic).
Packet logs also show it does have 1 important difference to its packet format compared to both Bamboo and current Tablet PC's. That is the fact that its proximity bit is in a different location. A value of 0x20 was used by both Bamboo and Tablet PC's for proximity but Eee Note has moved it to 0x10.
In addition, Tablet PC's have other minor bit differences for stylus button/eraser detection compared to Bamboo (see wacom_wac.c). It needs more research to see which bit pattern this issues.
We may choice to create a whole new device class for this 1 bit proximity change or we may be able to detect difference at run time. For example, bit 0x80 may be fixed value that is different between the two packet formats? If we make it a runtime difference *and* choice Tablet PC then some kind of modification needs to be made so Feature Request #2 is sent for subset of Tablet PC's.