On Sat, Jul 02, 2011 at 01:30:40PM -0400, Julian Squires wrote:
> I would like to write up a description of the serial protocol on the
> wiki; alas, I presently have no write access there.

Just create a sourceforge account and let me know your username (private
email). I'll add you to the editors and then you're good to go.
http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=WikiEditingGuidelines
I can't remember if there was some extra step of you logging into the wiki
first, but we'll figure that out quickly.

> 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 nice. I've had a quick browse throught he code and it looks good. One
thing I do recommend though: if you cannot test a set of devices it might be
better to just not add them. Detecting them and putting a warning to the log
is good, but if you aren't sure about whether the code works at all, it's
better to wait for someone to care enough about actually testing them.

> 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.

Can you specify "cleaner"? Are we talking about two different protocols or
just a lot of model/version handling? If it's really two different
protocols, then two drivers may be more appropriate.
 
> 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?

I _think_ the devices can only run at one speed, so if you run too fast
you'll get garbage. Ping will know.

> 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.
> 
> 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.

One day we'll need a glossary :) 
What are macro buttons? the ones on the pad? If so, the current set of
supported devices export the pad buttons as BTN_0, BTN_1, etc. events.

Cheers,
  Peter

------------------------------------------------------------------------------
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

Reply via email to