Re: [Linuxwacom-devel] Issues with DTI-520
On Sat, Feb 11, 2012 at 8:42 PM, Adam Nielsen wrote: >> For the buttons, none of the wacom drivers currently support anything >> quite like this. I see in the USB report that the device has 2 >> interfaces. Normally, we only see this on touchscreens where the >> second interface reports touch events. >> >> In your case, the second interface seems to define those buttons. I >> see a set of 5 buttons clearly labeled and then some more bits that >> aren't obvious how to decode. >> >> You'd have to write a custom decoder for those if you want to process >> them. In mean time, we may or may not need to detect that interface >> and disable it (if it crashes for example). > > > When you say 'custom decoder' does that mean just figuring out the protocol, > and using existing code for reporting button presses? Or will it require > adding support for buttons from scratch? Yes, that is all I mean. Based on your later info, it means there would be some code that looks like this: if (packet_size == 8 && data[0] == 2) // Do pen processing else if (packet_size == 6 && data[0] == 4) // Do button processing. Thats all. Not to bad, coding wise. > > >> This says the packet size is 7 8-bit bytes. That maps to >> WACOM_PKGLEN_PENPRTN. I've seen occasionally where they do not >> include in this count the 1st byte in packet which is ID. So the >> packet len could either be 7 or 8. I'd try 8 first which maps to >> WACOM_PKGLEN_GRAPHIRE. > > > As per below, it looks like this is 8. Agree. Looks like 8 it is. When 1 USB device has 2 interfaces, each interface can have a different packet length. In Wacom driver, our convention is to put the pen's packet length in the table your modifying and then set at run time for the other interface. > > >> Thats all on stylus. Sometimes they include extra info like max X/Y >> values and resolution but doesn't look like it in this report. You'll >> have to figure those out at some point and fill them in structures. > > > That's fine. Am I looking at e.g. usbmon to find out the maximum value or > xinput output, evtest, or somewhere else? evtest is my preferred for max X/Y. Just need to draw at borders of screen and see max values reported. Resolution is manually computed based on screen size to max X/Y... but in kernel its stored in metric and screen size is often in inches so you'll need to convert. Usually, its some round number like 100 to help you know when you got it right. > > >> Its kinda a max packet length. With most peoples USB hubs, its OK to >> leave it large. Some USB hubs will return an error if a packet is >> received with less bytes then requested and on those machines you have >> to get this value exactly right. > > > Ah, that explains a few things from other USB tinkering I've done... The > behaviour hasn't changed with a packet length of 32, so looks like that's > ok. > > >> All the stylus formats are usually pretty similar but it takes just 1 >> bit in a different location and it will act totally strange. > > > That probably explains the wrapping around of the Y coordinate with PL and > PTU then. > > Since PL and PTU didn't work for you, I'd move to some of the other similar HW types (screens with digitizers). Cintiq's are most popular and possible values for those are WACOM_24HD, CINTIQ, WACOM_BEE, and WACOM_21UX2. > > > Is WACOM_24HD new? It's not in the code I have. Otherwise here are my > results: Yes, very new. It will be in Linux 3.3 I think. > > CINTIQ: X crash > WACOM_BEE: X crash > WACOM_21UX2: no events, long time to load module, errors about no device > 'pad' > DTU: no events > > >>> I didn't try DTU because in wacom_setup_input_capabilities() in the >>> kernel >>> driver it seems to be handled the same as PL. Is it treated differently >>> elsewhere? >> >> >> Yes, there is a wacom_dtu_irq() and the stylus bits are every so >> slightly different. > > > Ah, will have to look at that. At any rate PTU definitely works better than > DTU. > > And the last option to try is Tablet PC driver. They use TABLETPC. > > > No luck - no events returned. > > If no luck with any of those, we'd have to start logging some USB packets (using kernels /sys/kernel/debug/usb/usbmon interface) and see if we can't figure out the packet format and add a new DTI driver. > > > Here is some usbmon output for the device: > > C Ii:025:01 0 32 = 0240177a 0cee 02401780 0ce6 02401784 0ce7 > 02401789 0ce3 > S Ii:025:01 -115 32 < > > If the data is in bytes, then it seems to be eight bytes repeated up to the > 32-byte buffer length. If I change the buffer length back to 8 I seem to > get a bunch of clean events: > > 880229ce40c0 304567392 C Ii:025:01 0 8 = 024008f5 002d > 880229ce40c0 304567405 S Ii:025:01 -115 8 < Interesting. Your USB hub works a little different then mine with over specifying packet size to receive. I think its related to needing 2 button presses for buttons. > > Taking
Re: [Linuxwacom-devel] Issues with DTI-520
> For the buttons, none of the wacom drivers currently support anything > quite like this. I see in the USB report that the device has 2 > interfaces. Normally, we only see this on touchscreens where the > second interface reports touch events. > > In your case, the second interface seems to define those buttons. I > see a set of 5 buttons clearly labeled and then some more bits that > aren't obvious how to decode. > > You'd have to write a custom decoder for those if you want to process > them. In mean time, we may or may not need to detect that interface > and disable it (if it crashes for example). When you say 'custom decoder' does that mean just figuring out the protocol, and using existing code for reporting button presses? Or will it require adding support for buttons from scratch? > This says the packet size is 7 8-bit bytes. That maps to > WACOM_PKGLEN_PENPRTN. I've seen occasionally where they do not > include in this count the 1st byte in packet which is ID. So the > packet len could either be 7 or 8. I'd try 8 first which maps to > WACOM_PKGLEN_GRAPHIRE. As per below, it looks like this is 8. > Thats all on stylus. Sometimes they include extra info like max X/Y > values and resolution but doesn't look like it in this report. You'll > have to figure those out at some point and fill them in structures. That's fine. Am I looking at e.g. usbmon to find out the maximum value or xinput output, evtest, or somewhere else? > Its kinda a max packet length. With most peoples USB hubs, its OK to > leave it large. Some USB hubs will return an error if a packet is > received with less bytes then requested and on those machines you have > to get this value exactly right. Ah, that explains a few things from other USB tinkering I've done... The behaviour hasn't changed with a packet length of 32, so looks like that's ok. > All the stylus formats are usually pretty similar but it takes just 1 > bit in a different location and it will act totally strange. That probably explains the wrapping around of the Y coordinate with PL and PTU then. >>> Since PL and PTU didn't work for you, I'd move to some of the other >>> similar HW types (screens with digitizers). Cintiq's are most popular >>> and possible values for those are WACOM_24HD, CINTIQ, WACOM_BEE, and >>> WACOM_21UX2. Is WACOM_24HD new? It's not in the code I have. Otherwise here are my results: CINTIQ: X crash WACOM_BEE: X crash WACOM_21UX2: no events, long time to load module, errors about no device 'pad' DTU: no events >> I didn't try DTU because in wacom_setup_input_capabilities() in the kernel >> driver it seems to be handled the same as PL. Is it treated differently >> elsewhere? > > Yes, there is a wacom_dtu_irq() and the stylus bits are every so > slightly different. Ah, will have to look at that. At any rate PTU definitely works better than DTU. >>> And the last option to try is Tablet PC driver. They use TABLETPC. No luck - no events returned. >>> If no luck with any of those, we'd have to start logging some USB >>> packets (using kernels /sys/kernel/debug/usb/usbmon interface) and see >>> if we can't figure out the packet format and add a new DTI driver. Here is some usbmon output for the device: C Ii:025:01 0 32 = 0240177a 0cee 02401780 0ce6 02401784 0ce7 02401789 0ce3 S Ii:025:01 -115 32 < If the data is in bytes, then it seems to be eight bytes repeated up to the 32-byte buffer length. If I change the buffer length back to 8 I seem to get a bunch of clean events: 880229ce40c0 304567392 C Ii:025:01 0 8 = 024008f5 002d 880229ce40c0 304567405 S Ii:025:01 -115 8 < Taking just the data and examining it: 024008f5 002d aabb pppz x and y are absolute coordinates, p is pressure (0 to ff80). It looks like this is only a 9-bit number. z is 0 normally, and 1 or 2 if the primary or secondary stylus button is pressed. z is 15-bits long but I can't see what the other bits are used for - maybe other tools? a always seems to be 02 and bb is either 00 when the stylus goes out of range, 40 when the stylus is at the edge of the screen (outside the LCD part) and c0 when the stylus is over the LCD part. Going back to the buttons: > This says the 1st 5 bits in packet map to buttons and have on/off single > values. > > Above has values between 6 and 10 so are more than 1 bit. Not sure > what it is but there are 3 of them. And then 5 of something else and > 3 of another thing follows. Pressing each of the top five buttons, left to right, gives this: C Ii:025:02 -75 6 = 04000204 S Ii:025:02 -115 8 < C Ii:025:02 -75 6 = 04000404 S Ii:025:02 -115 8 < C Ii:025:02 -75 6 = 04000104 S Ii:025:02 -115 8 < C Ii:025:02 -75 6 = 04000804 S Ii:025:02 -115 8 < C Ii:025:02 -75 6 = 04001004 The weird part is that the buttons have to be pressed twice. The first button press controls which code will be sent as above, but it's not until the second button
Re: [Linuxwacom-devel] Issues with DTI-520
On Sat, Feb 11, 2012 at 6:23 PM, Adam Nielsen wrote: > Hi Chris, > > Thanks for the quick response! > > >> Hi, I googled this model and I see its a stand alone screen with built >> in Wacom digitizer. > > > Yes that's correct. For the record, it also has a built in USB hub which > works fine: > > Bus 001 Device 021: ID 056a:003b Wacom Co., Ltd > Device Descriptor: > ... > bDeviceClass 9 Hub > bDeviceSubClass 0 Unused > bDeviceProtocol 1 Single TT > bMaxPacketSize0 64 > idVendor 0x056a Wacom Co., Ltd > idProduct 0x003b > bcdDevice 7.02 > iManufacturer 10 WACOM > iProduct 11 DTI-520 HUB > ... > > The device also has a number of pushbuttons on its face - five unlabelled > ones across the top (with a space to insert your own paper label), and six > along the bottom (L, R, up, down, and two Ctrl. One Ctrl suggests it shifts > the up/down keys into zoom in/out.) Interesting. I've never heard they did USB hubs before. For the buttons, none of the wacom drivers currently support anything quite like this. I see in the USB report that the device has 2 interfaces. Normally, we only see this on touchscreens where the second interface reports touch events. In your case, the second interface seems to define those buttons. I see a set of 5 buttons clearly labeled and then some more bits that aren't obvious how to decode. You'd have to write a custom decoder for those if you want to process them. In mean time, we may or may not need to detect that interface and disable it (if it crashes for example). > > Here is the output: > > Bus 001 Device 022: ID 056a:003a Wacom Co., Ltd > Device Descriptor: ... This first section defines a mouse device. Its default behaviour or Wacom devices. If it wasn't for the fact that all Wacom devices are blacklisted from the hid-core, this screen would most likely already be working but as an odd mouse (relative mode). > iInterface 0 > HID Device Descriptor: > bLength 9 > bDescriptorType 33 > bcdHID 1.10 > bCountryCode 0 Not supported > bNumDescriptors 1 > bDescriptorType 34 Report > wDescriptorLength 110 > Report Descriptor: (length is 110) > Item(Global): Usage Page, data= [ 0x01 ] 1 > Generic Desktop Controls > Item(Local ): Usage, data= [ 0x02 ] 2 > Mouse > Item(Main ): Collection, data= [ 0x01 ] 1 > Application > Item(Global): Report ID, data= [ 0x01 ] 1 > Item(Local ): Usage, data= [ 0x01 ] 1 > Pointer > Item(Main ): Collection, data= [ 0x00 ] 0 > Physical > Item(Global): Usage Page, data= [ 0x09 ] 9 > Buttons > Item(Local ): Usage Minimum, data= [ 0x01 ] 1 > Button 1 (Primary) > Item(Local ): Usage Maximum, data= [ 0x03 ] 3 > Button 3 (Tertiary) > Item(Global): Logical Minimum, data= [ 0x00 ] 0 > Item(Global): Logical Maximum, data= [ 0x01 ] 1 > Item(Global): Report Count, data= [ 0x03 ] 3 > Item(Global): Report Size, data= [ 0x01 ] 1 > Item(Main ): Input, data= [ 0x02 ] 2 > Data Variable Absolute No_Wrap Linear > Preferred_State No_Null_Position Non_Volatile > Bitfield > Item(Global): Report Count, data= [ 0x05 ] 5 > Item(Main ): Input, data= [ 0x03 ] 3 > Constant Variable Absolute No_Wrap Linear > Preferred_State No_Null_Position Non_Volatile > Bitfield > Item(Global): Usage Page, data= [ 0x01 ] 1 > Generic Desktop Controls > Item(Local ): Usage, data= [ 0x30 ] 48 > Direction-X > Item(Local ): Usage, data= [ 0x31 ] 49 > Direction-Y > Item(Global): Logical Minimum, data= [ 0x81 ] 129 > Item(Global): Logical Maximum, data= [ 0x7f ] 127 > Item(Global): Report Size, data= [ 0x08 ] 8 > Item(Global): Report Count, data= [ 0x02 ] 2 > Item(Main ): Input, data= [ 0x06 ] 6 > Data Variable Relative No_Wrap Linear > Preferred_State No_Null_Position Non_Volatile > Bitfield > Item(Main ): End Collection, data=none > Item(Main ): End Collection, data=none This second defines the report id #2 that contains pen data: > Item(Global): Usage Page, data= [ 0x0d ] 13 > Digitizer > Item(Local ): Usage, data= [ 0x01 ] 1 >
Re: [Linuxwacom-devel] Issues with DTI-520
Hi Chris, Thanks for the quick response! > Hi, I googled this model and I see its a stand alone screen with built > in Wacom digitizer. Yes that's correct. For the record, it also has a built in USB hub which works fine: Bus 001 Device 021: ID 056a:003b Wacom Co., Ltd Device Descriptor: ... bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 1 Single TT bMaxPacketSize064 idVendor 0x056a Wacom Co., Ltd idProduct 0x003b bcdDevice7.02 iManufacturer 10 WACOM iProduct 11 DTI-520 HUB ... The device also has a number of pushbuttons on its face - five unlabelled ones across the top (with a space to insert your own paper label), and six along the bottom (L, R, up, down, and two Ctrl. One Ctrl suggests it shifts the up/down keys into zoom in/out.) > I'm guessing you chose those initial values because there is a 0x39 > already defined and modelled after it? In general, that is a good > approach. Wacom does tend to group related HW with similar product > ID's. Yes that's what I was hoping! > rmmod wacom > lsusb -vvv Here is the output: Bus 001 Device 022: ID 056a:003a Wacom Co., Ltd Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x056a Wacom Co., Ltd idProduct 0x003a bcdDevice1.03 iManufacturer 1 WACOM iProduct2 DTI-520-U iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 59 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 2 Mouse iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType33 bcdHID 1.10 bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report wDescriptorLength 110 Report Descriptor: (length is 110) Item(Global): Usage Page, data= [ 0x01 ] 1 Generic Desktop Controls Item(Local ): Usage, data= [ 0x02 ] 2 Mouse Item(Main ): Collection, data= [ 0x01 ] 1 Application Item(Global): Report ID, data= [ 0x01 ] 1 Item(Local ): Usage, data= [ 0x01 ] 1 Pointer Item(Main ): Collection, data= [ 0x00 ] 0 Physical Item(Global): Usage Page, data= [ 0x09 ] 9 Buttons Item(Local ): Usage Minimum, data= [ 0x01 ] 1 Button 1 (Primary) Item(Local ): Usage Maximum, data= [ 0x03 ] 3 Button 3 (Tertiary) Item(Global): Logical Minimum, data= [ 0x00 ] 0 Item(Global): Logical Maximum, data= [ 0x01 ] 1 Item(Global): Report Count, data= [ 0x03 ] 3 Item(Global): Report Size, data= [ 0x01 ] 1 Item(Main ): Input, data= [ 0x02 ] 2 Data Variable Absolute No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Global): Report Count, data= [ 0x05 ] 5 Item(Main ): Input, data= [ 0x03 ] 3 Constant Variable Absolute No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Global): Usage Page, data= [ 0x01 ] 1 Generic Desktop Controls Item(Local ): Usage, data= [ 0x30 ] 48 Direction-X Item(Local ): Usage, data= [ 0x31 ] 49 Direction-Y Item(Global): Logical Minimum, data= [ 0x81 ] 129 Item(Global): Logical Maximum, data= [ 0x7f ] 127 Item(Global): Report Size, data= [ 0x08 ] 8 Item(Global): Report Count, data= [ 0x02 ] 2 Item(Main ): Input, data= [ 0x06 ] 6 Data Variable Relative No_Wrap Linear
Re: [Linuxwacom-devel] Intuos4 WL is handled by evdev - what's wrong?
On Sat, Feb 11, 2012 at 7:52 AM, Peter Hutterer wrote: > On Sat, Feb 11, 2012 at 11:24:15AM +, Przemo Firszt wrote: >> Wacom4 WL on usb cable - "Wacom" is part of the name, but ID_VENDOR >> field contains "Tablet" 8-): >> >> P: /devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/input/input10 >> E: UDEV_LOG=3 >> E: >> DEVPATH=/devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/input/input10 >> E: PRODUCT=3/56a/bc/127 >> E: NAME="Wacom Intuos4 WL" >> E: PROP=1 >> E: EV=1f >> E: KEY=1cdf 0 1f01ff 0 0 0 0 0 0 0 0 >> E: REL=100 >> E: ABS=100 f000167 >> E: MSC=1 >> E: >> MODALIAS=input:b0003v056Ap00BCe0127-e0,1,2,3,4,k100,101,102,103,104,105,106,107,108,110,111,112,113,114,140,141,142,143,144,146,147,14A,14B,14C,r8,a0,1,2,5,6,8,18,19,1A,1B,28,m0,lsfw >> E: SUBSYSTEM=input >> E: ID_INPUT=1 >> E: ID_INPUT_TABLET=1 >> E: ID_VENDOR=Tablet >> E: ID_VENDOR_ENC=Tablet >> E: ID_VENDOR_ID=056a >> E: ID_MODEL=PTK-540WL >> E: ID_MODEL_ENC=PTK-540WL >> E: ID_MODEL_ID=00bc >> E: ID_REVISION=0127 >> E: ID_SERIAL=Tablet_PTK-540WL_00-10-60-26-58-e7 >> E: ID_SERIAL_SHORT=00-10-60-26-58-e7 >> E: ID_TYPE=hid >> E: ID_BUS=usb >> E: ID_USB_INTERFACES=:030102: >> E: ID_USB_INTERFACE_NUM=00 >> E: ID_USB_DRIVER=wacom >> E: ID_PATH=pci-:00:1d.0-usb-0:1:1.0 >> E: ID_PATH_TAG=pci-_00_1d_0-usb-0_1_1_0 >> >> Some of the kernel drivers are cheanging device name, so we could >> possibly do the same. Example here: >> drivers/hid/hid-hyperv.c: sprintf(hid_dev->name, "%s", "Microsoft >> Vmbus HID-compliant Mouse"); >> >> but it's a workaround and I think it's not worth to do it. > > I think it's worth it. the ID_VENDOR_ID is 0x56a which is Wacom, the string > should reflect this to make userspace simpler. And adding this is aligned with wacom_sys.c. It is doing same dev->name update and why you see Wacom in your output: E: NAME="Wacom Intuos4 WL" > > Cheers, > Peter -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Issues with DTI-520
On Sat, Feb 11, 2012 at 2:21 AM, Adam Nielsen wrote:
> Hi all,
>
> I recently got hold of a second-hand DTI-520 and I'd like to get it working
> under Linux. It seems it is not yet supported, so I am trying to add support
> for it.
>
>
> Some of the code I added to the kernel module is:
>
> static const struct wacom_features wacom_features_0x3A =
> { "Wacom DTI520UB/L", WACOM_PKGLEN_GRAPHIRE, 3250, 65600, 2047,
> 0, PL, WACOM_PL_RES, WACOM_PL_RES };
>
Hi, I googled this model and I see its a stand alone screen with built
in Wacom digitizer.
I'm guessing you chose those initial values because there is a 0x39
already defined and modelled after it? In general, that is a good
approach. Wacom does tend to group related HW with similar product
ID's.
Here are some additional things you can try:
Run the following commands as root:
rmmod wacom
lsusb -vvv
Find the snippet related to Wacom and send it to list. In that output
will often be information on packet sizes. We can use this
information to know what value to set for WACOM_PKGLEN_* without
guessing. Worst case, set that field to 32 for right now and move to
next step.
The part that has "PL" above is what tells packet format and there are
lots of different packet formats. Hopefully, this is not a totally
new format.
Since PL and PTU didn't work for you, I'd move to some of the other
similar HW types (screens with digitizers). Cintiq's are most popular
and possible values for those are WACOM_24HD, CINTIQ, WACOM_BEE, and
WACOM_21UX2.
Probably, your screen is closer to the DTU-* and DTF-* models that are
already supported. DTU and PTU are valid values for it so I'd
probably try DTU next.
And the last option to try is Tablet PC driver. They use TABLETPC.
If no luck with any of those, we'd have to start logging some USB
packets (using kernels /sys/kernel/debug/usb/usbmon interface) and see
if we can't figure out the packet format and add a new DTI driver.
Chris
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [PATCH v3] Enable LED status change through xsetwacom
On Sat, Feb 11, 2012 at 1:24 AM, Peter Hutterer wrote: > On Sat, Feb 11, 2012 at 12:03:19AM +0800, Ping Cheng wrote: > > On Fri, Feb 10, 2012 at 4:29 PM, Peter Hutterer < > peter.hutte...@who-t.net>wrote: > > > > > On Wed, Feb 08, 2012 at 08:30:58AM -0800, Jason Gerecke wrote: > > > > On Wed, Jan 25, 2012 at 1:57 PM, Jason Gerecke > > > > wrote: > > > > > This covers most of the suggested changes. I'm not sure yet how we > > > > > want to expose the properties through X, so changes regarding that > > > > > haven't been folded in. > > > > > > [...] > > > > > > > > Any feedback on the changes or ideas on exposing the properties? > > > > > > sorry for the delay. short answer - I don't think we should merge this > > > support as properties. properties are not well-suited for this, they > are > > > too > > > generic and too much knowledge must reside in the client setting them. > > > > > > Instead, we should extend the protocol for XI 2.3 > > > > > > How do we support XI older than 2.3, then? > > we don't, at least not in xf86-input-wacom and I very much doubt that e.g. > gnome would then. While I understand the need for keeping backwards-compat > with older servers for new hardware, Just as much as you understand me on this issue, I know your point. This support is mainly for RHEL6. So, we'll need to tell the users to file a request at redhat bugzilla. Ping > I don't think LED support is that > crucial that we should merge and support an interface that can only be > badly > supported (and is driver-specific, again, like too many other features). > If > the need is that big, you could branch off but I doubt LED support is worth > the effort. > > Cheers, > Peter > > > > to add a LED class and the > > > required requests to modify the LEDs support. This gives us > > > more flexibility handling LEDs and less driver-dependent behaviour. > > > > > > Cheers, > > > Peter > -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Intuos4 WL is handled by evdev - what's wrong?
On Sat, Feb 11, 2012 at 11:24:15AM +, Przemo Firszt wrote: > Wacom4 WL on usb cable - "Wacom" is part of the name, but ID_VENDOR > field contains "Tablet" 8-): > > P: /devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/input/input10 > E: UDEV_LOG=3 > E: > DEVPATH=/devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/input/input10 > E: PRODUCT=3/56a/bc/127 > E: NAME="Wacom Intuos4 WL" > E: PROP=1 > E: EV=1f > E: KEY=1cdf 0 1f01ff 0 0 0 0 0 0 0 0 > E: REL=100 > E: ABS=100 f000167 > E: MSC=1 > E: > MODALIAS=input:b0003v056Ap00BCe0127-e0,1,2,3,4,k100,101,102,103,104,105,106,107,108,110,111,112,113,114,140,141,142,143,144,146,147,14A,14B,14C,r8,a0,1,2,5,6,8,18,19,1A,1B,28,m0,lsfw > E: SUBSYSTEM=input > E: ID_INPUT=1 > E: ID_INPUT_TABLET=1 > E: ID_VENDOR=Tablet > E: ID_VENDOR_ENC=Tablet > E: ID_VENDOR_ID=056a > E: ID_MODEL=PTK-540WL > E: ID_MODEL_ENC=PTK-540WL > E: ID_MODEL_ID=00bc > E: ID_REVISION=0127 > E: ID_SERIAL=Tablet_PTK-540WL_00-10-60-26-58-e7 > E: ID_SERIAL_SHORT=00-10-60-26-58-e7 > E: ID_TYPE=hid > E: ID_BUS=usb > E: ID_USB_INTERFACES=:030102: > E: ID_USB_INTERFACE_NUM=00 > E: ID_USB_DRIVER=wacom > E: ID_PATH=pci-:00:1d.0-usb-0:1:1.0 > E: ID_PATH_TAG=pci-_00_1d_0-usb-0_1_1_0 > > Some of the kernel drivers are cheanging device name, so we could > possibly do the same. Example here: > drivers/hid/hid-hyperv.c: sprintf(hid_dev->name, "%s", "Microsoft > Vmbus HID-compliant Mouse"); > > but it's a workaround and I think it's not worth to do it. I think it's worth it. the ID_VENDOR_ID is 0x56a which is Wacom, the string should reflect this to make userspace simpler. Cheers, Peter -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [PATCH] Add Wacom Intuos4 Wireless to 50-wacom.conf
Dnia 2012-02-11, sob o godzinie 06:04 +1000, Peter Hutterer pisze: [..] > yeah, same with me, not quite sure right now where to match properly. I've > pushed your patch for now, if we figure out how to do it better we can amend > it later. > >96a2e90..4709394 master -> master > > Cheers, > Peter OK, thanks! It will be at the very bottom of my TODO list for Wacom :-) -- Cheers, Przemo -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Intuos4 WL is handled by evdev - what's wrong?
Wacom4 WL on usb cable - "Wacom" is part of the name, but ID_VENDOR field contains "Tablet" 8-): P: /devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/input/input10 E: UDEV_LOG=3 E: DEVPATH=/devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/input/input10 E: PRODUCT=3/56a/bc/127 E: NAME="Wacom Intuos4 WL" E: PROP=1 E: EV=1f E: KEY=1cdf 0 1f01ff 0 0 0 0 0 0 0 0 E: REL=100 E: ABS=100 f000167 E: MSC=1 E: MODALIAS=input:b0003v056Ap00BCe0127-e0,1,2,3,4,k100,101,102,103,104,105,106,107,108,110,111,112,113,114,140,141,142,143,144,146,147,14A,14B,14C,r8,a0,1,2,5,6,8,18,19,1A,1B,28,m0,lsfw E: SUBSYSTEM=input E: ID_INPUT=1 E: ID_INPUT_TABLET=1 E: ID_VENDOR=Tablet E: ID_VENDOR_ENC=Tablet E: ID_VENDOR_ID=056a E: ID_MODEL=PTK-540WL E: ID_MODEL_ENC=PTK-540WL E: ID_MODEL_ID=00bc E: ID_REVISION=0127 E: ID_SERIAL=Tablet_PTK-540WL_00-10-60-26-58-e7 E: ID_SERIAL_SHORT=00-10-60-26-58-e7 E: ID_TYPE=hid E: ID_BUS=usb E: ID_USB_INTERFACES=:030102: E: ID_USB_INTERFACE_NUM=00 E: ID_USB_DRIVER=wacom E: ID_PATH=pci-:00:1d.0-usb-0:1:1.0 E: ID_PATH_TAG=pci-_00_1d_0-usb-0_1_1_0 Some of the kernel drivers are cheanging device name, so we could possibly do the same. Example here: drivers/hid/hid-hyperv.c: sprintf(hid_dev->name, "%s", "Microsoft Vmbus HID-compliant Mouse"); but it's a workaround and I think it's not worth to do it. -- Regards, Przemo -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
[Linuxwacom-devel] Issues with DTI-520
Hi all,
I recently got hold of a second-hand DTI-520 and I'd like to get it working
under Linux. It seems it is not yet supported, so I am trying to add support
for it.
After adding in USB IDs to the kernel driver and the X11 module it starts
returning data when I move the stylus around. The X-coordinates seem fine (0
to 3208) but for some reason the Y coordinate seems to wrap around as I move
down the screen. I'm not sure what's causing this - here is some sample
output from 'xinput test' as I move the stylus about a third of the way down
the screen:
motion a[0]=770 a[1]=63458 a[2]=0 a[3]=0 a[4]=0 a[5]=-900
motion a[0]=770 a[1]=63874 a[2]=0 a[3]=0 a[4]=0 a[5]=-900
motion a[0]=770 a[1]=64322 a[2]=0 a[3]=0 a[4]=0 a[5]=-900
motion a[0]=770 a[1]=64770 a[2]=0 a[3]=0 a[4]=0 a[5]=-900
motion a[0]=770 a[1]=48834 a[2]=4 a[3]=0 a[4]=0 a[5]=-900
motion a[0]=770 a[1]=32898 a[2]=4 a[3]=0 a[4]=0 a[5]=-900
motion a[0]=770 a[1]=16931 a[2]=4 a[3]=0 a[4]=0 a[5]=-900
motion a[0]=769 a[1]=932 a[2]=4 a[3]=0 a[4]=0 a[5]=-900
motion a[0]=769 a[1]=1351 a[2]=4 a[3]=0 a[4]=0 a[5]=-900
motion a[0]=769 a[1]=1801 a[2]=4 a[3]=0 a[4]=0 a[5]=-900
motion a[0]=769 a[1]=2283 a[2]=4 a[3]=0 a[4]=0 a[5]=-900
motion a[0]=769 a[1]=2829 a[2]=4 a[3]=0 a[4]=0 a[5]=-900
motion a[0]=769 a[1]=3406 a[2]=4 a[3]=0 a[4]=0 a[5]=-900
Some of the code I added to the kernel module is:
static const struct wacom_features wacom_features_0x3A =
{ "Wacom DTI520UB/L", WACOM_PKGLEN_GRAPHIRE, 3250, 65600, 2047,
0, PL, WACOM_PL_RES, WACOM_PL_RES };
This gives me these messages in the Xorg output:
[ 15979.601] [dix] Unknown event type 35. No filter
[ 15979.601] [dix] Unknown event type 35. No filter
[ 15983.121] [dix] Unknown event type 35. No filter
[ 15983.121] [dix] Unknown event type 35. No filter
Two messages each time I touch and remove the stylus from the surface.
Changing the "PL" type in the above code to "PTU" returns a button press and
button release event instead, as the stylus touches and leaves the surface.
I'm guessing this means the PTU type is probably more correct than PL. I also
seem to get pressure values coming in with the PTU type as well (in xinput's
a[2] value), although they seem a bit weird (the values are all < 256 but with
spatterings of 2048 among them, except it stays at 2048 if I press the stylus
fairly hard.)
Unfortunately I'm just poking around in the dark here, so I'm not really sure
where to go next. Does anyone know how I can proceed with figuring out how to
get this device working properly?
Many thanks,
Adam.
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
