On Sat, Sep 4, 2010 at 2:18 PM, Nikolai Kondrashov <[email protected]> wrote: > On 09/04/2010 09:21 PM, Chris Bagwell wrote: >> >> Here is some initial things to consider. First up, the typical way of >> detecting in userspace what type the input device is is by looking at >> what events it declares it supports. You'll see this even in >> xf86-input-evdev init logic. > > Sure, I've seen it in many places. > >> What input devices do the waltop kernel drivers create? For example, >> is there one for pen and one for eraser? Or does "dumb" mean they >> only support one type of stylus-tool? > > First, I'm not talking only about Waltop devices here. I've also added > support for 4 UC-Logic models - these are the "dumbest" so far. I'm also > looking forward to fixing one Kye device. > > Currently, UC-Logic tablets create two event devices at most: one for the > pen, one for the mouse (if any). The mouse reports relative events and is > handled perfectly by the evdev driver. The pen reports ABS_X/Y/PRESSURE and > BTN_TOUCH/STYLUS/STYLUS2. There is no BTN_TOOL_STYLUS. >
Can you briefly say how those three BTN_* are used? For example, does one represent when your using certain end of the pen (eraser)? Or does BTN_TOUCH represent when pen is touching and others represent the buttons on the pen? > The Waltop tablets using my driver could have several event devices: a pen, > a pseudo-mouse, having only scroll wheels, and a pair of keyboards reporting > other things controlled by wheels on the tablet frame. The pen has the usual > ABS_X/Y/PRESSURE and BTN_TOUCH/STYLUS/STYLUS2 and there is BTN_TOOL_STYLUS. > > Neither UC-Logic nor Waltop tablets I've seen have any other tools. > >> How are the buttons on the tablet reported? Are they on their own >> input device? Hopefully so because that would closely match how >> xf86-input-wacom wants to see them and solves an issue with which >> stylus tool owns the button reports. > > I'm not sure if you mean the same or different buttons by "the buttons on > the tablet" and the buttons which the stylus tool owns and what they all > exactly are, but hopefully I have explained the situation sufficiently > above. > >> Without defining BTN_TOOL_PEN, BTN_TOOL_RUBBER, and BTN_TOOL_FINGER >> (for pen, eraser, and buttons respectively) in kernel for each input >> device, at best, xf86-input-wacom would have to assume they were all >> PENs and user would be forced to config files to resolve this. > > It seems X.org configuration code matches even BTN_TOOL_PEN-less devices > with MatchIsTablet, but I'll have to verify it. If it is true, > xf86-input-wacom could maybe ship a configuration with an InputClass > matching only the pen event device and leave the rest to evdev. Yeah, its really udev doing the work here for MatchIsTablet. See test_pointers() from this file: http://udev.sourcearchive.com/documentation/148/input__id_8c-source.html So anything reporting BTN_STYLUS or BTN_TOOL_PEN is considered a tablet. > >> Once that basic issue is solved, the additional changes needed to >> xf86-input-wacom are probably pretty small. > > Could you say that the basic issue is solved from what I've written above? > Because I'm not sure I understood everything right. I think we can say its answered. It sounds like drivers your working on will be detected as IS_INPUT_TABLET by udev because they all have common thread of BTN_STYLUS and one also has BTN_TOOL_PEN. So one initial update to xf86-input-wacom to make it more generic would require places were it check to see if this is a pen vs. mouse vs. whatever tool that it can say BTN_TOOL_PEN || BTN_STYLUS. > > Also, from what I've seen in the code, I came to the conclusion that > MSC_SERIAL is necessary for selecting a channel. Am I wrong? Plus, it seems > BTN_TOOL_PEN is necessary too, but there is some additional check for > "_source" option in wcmIsAValidType which I don't yet understand, but which > allows the device to not have it. Could you please explain in short what > does it do and what "_source" option exactly is? Let me first point you to this following post. It explains kernel side interface for wacom devices and may help to decode what xf86-input-wacom is trying to parse. http://www.mail-archive.com/[email protected]/msg00959.html A channel in xf86-input-wacom is loosely defined as maximum # of multiplexed tools on single input device that can be in proximity at the same time. MSC_SERIAL is not strictly required and it will default to channel 0 (see wcmUSB.c:usbChooseChannel). Most dumb devices can get away with single channel but we will eventually need to figure out how they report button presses on physical tablet because thats what second channel is mostly for. For these simple devices, I think there must be some way we can allow buttons to be associated with the PEN channel and not required to be a fully independent device. The wcmIsValidType is used during initialization time. X driver creates internally a device for each of the multiplex tools reported over single input device. The _source helps detect if its a real device or a fake device that X created. Your devices will only have BTN_TOOL_PEN/BTN_STYLUS so it won't hit the logic to create this other devices... > > Thank you very much :) > > Sincerely, > Nick > ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
