On Sat, Jul 2, 2011 at 12:30 PM, Julian Squires <[email protected]> wrote: > Hi folks, > > I would like to write up a description of the serial protocol on the > wiki; alas, I presently have no write access there.
I'm sure Ping or Peter can give you wiki write access. Do you have a sourceforge account already? > > In any case, I have written a kernel driver for protocol four devices > that works for me and my Digitizer II, without any changes to > xf86-input-wacom. I have done my best to accomidate other devices > supported by the prior driver, but of course these remain untested. > No doubt there are still many gotchas, especially since my own testing > is not terribly extensive (simple stylus and eraser work in the gimp). > You can get the code here: > http://cipht.net/2011/07/02/wacom_serial-initial-release.html Very cool. I'm sure you'll make a lot of people happy with this. You should probably post this snippet of your email onto linuxwacom-user's list. That is probably were you'll find audience looking to test. > > Please let me know whether this works or not on your devices. > Feedback on the code would also be appreciated. > > I have a few questions or topics to address: > > It seems to me that it would be cleaner to keep the protocol five > device support in a separate driver. Does this seem reasonable? > While I don't have one of these devices, if there is interest in > having a driver I would be willing to write one. Yeah, a little bit of both is probably right answer. If you look at drivers/input/tablet/wacom_* files, its one driver that handles both 4 and 5 devices. There is a lot of separate logic in that one file but they share a little bit of logic as well. > > Related to that: I notice in wcmSerial, everything save Intuos and > Intuos2 tablets uses protocol four. Are there any devices here which > are being run in some kind of compatibility mode, that might be better > served by using protocol five? > > Also, the link speed. I notice that in all the code I've looked at, > everything except the protocol five devices is run at 9600 bps, > although some reset commands are sent at higher rates (I'm planning to > do that from inputattach rather than the driver itself). Are there > any protocol four devices which would be better served by running at a > faster rate? > > Does anyone know what the WC_ZFILTER ("ZF\r") does? It's not part of > the setup string in older versions of the code, and the comment is > clearly wrong in wcmSerial.h. Sorry, I can't give any feedback on device specific question. I only know a little bit about newer USB Bamboo's. Hopefully others on list can give feedback. > > How should macro buttons be reported? As BTN_0..BTN_F key events? I > have avoided adding support for this yet as I'm not sure what event to > send, and what devices should be reported as in proximity in this > case. Since I don't know much about these older serial devices, its hard to give a good answer. We have examples of both ways of doing it BTN_0..BTN_F and BTN_LEFT/RIGHT/BACK/FORWARD. The later way will work with more applications out of the box but if the tablets are button happy then BTN_0..BTN_F may make more sense. For USB driver, we make a device specific decision on mappings since tablet layouts are so different. Same may be true for serial devices. Also, I have one comment on your wacom_serial.c. Can you make sure your only sending 1 tools worth of data per report_sync() call? It probably works as you've done it for protocol 4 devices. Its only a concern on tool transition. You need to make sure old BTN_TOOL_* is set to zero, a report_sync() occurs, and then new BTN_TOOL_* is set to 1. Because you have to physically flip pen this is probably always true. Its probably not true for devices with mouse pucks so you'd have to enforce it yourself. Also, we are slowly trying to move older drivers to what we've labelled as PROTOCOL_GENERIC inside xf86-input-wacom. For your current version of driver, that only means dropping the ABS_MISC event. It will affect how you send buttons though. For generic, they are just sent as needed. For protocol 4/5, they are sent kinda like they are a tool themselves. See http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Kernel_Input_Event_Overview for more information. Chris > > Thanks in advance. > > -- > Julian Squires > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Linuxwacom-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel > ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
