Hi, On Sun, Jul 3, 2011 at 7:44 PM, Peter Hutterer <[email protected]> wrote: > 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.
I agree; in this case, after getting my own device working, I had decided to add the untested portions to two ends: 1) allow users with other devices to test; 2) to see how the additions affected the structure of my existing code. I had planned to remove anything that remained untested before a proper release. But, in fact, given the questionable veracity of some of that old code, perhaps it is better to simply eliminate it and address any issues that come up as devices are tested. I can document the past behavior separately. > 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. They're different protocols. Certainly they share a common basis (high-bit marks packet start, etc), but packet handling would be completely different, and it seems to me keeping the two separate would simplify both drivers and reduce the work done at interrupt time, at the cost of the duplication of some common code (mostly initialization code, that could be shared, although the amount looks sufficiently trivial that I wouldn't bother initially). Still, if someone else wants add protocol five support to my code and maintain it, they're welcome to do it. But if I end up implementing it, I think my first approach would be to keep the two separate. > 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. Right, the pad buttons (labelled "functions/macros" on my pad). For buttons above 10, do I send BTN_A through BTN_F? Also, I assume that I should send ABS_MISC as PAD_DEVICE_ID for these though they're being pressed with the stylus. Strangely, the last version of the serial code doesn't seem to handle these at all, but older versions do. Cheers, -- 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
