On Tue, Jul 05, 2011 at 09:19:59AM -0400, Julian Squires wrote: > 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.
Two-sided sword, as usual. In your case, I'd probably prefer to keep it to the minimum (tested) set of devices and wait for someone to complain that their device is't working. Then you have a tester. > > 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. I'd keep it separate. But I recommend asking on linux-input what the preferred way is. > > 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? I honestly don't know. again, best to ask on lkml/linux-input for this. Cheers, Peter > 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. ------------------------------------------------------------------------------ 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
