On Tue, Aug 16, 2011 at 11:48:51PM -0700, Ping Cheng wrote: > > > I don't know what I can call the new value yet. It will need to get > > through > > > the LKML's review when the kernel driver is ready. I am thinking to call > > it > > > "ABS_VOLUME", which represents the led that is turned on (yeah, we are > > going > > > to support LED in the driver). > > > > > > > ABS_VOLUME for a LED??? > > > > Well, the LED_* defined in input.h does not fit the ones I am going to > report. Requesting for a new set of LED_* may have problem too. I am not > sure. I'll see where I can get when I start working on it.
if we need kernel patches anyway, why not suggest adding the necessary LED defines? This isn't the first device that would require this. mis-using ABS_VOLUME for LEDs is just a hack that makes it hard to write proper code (see also: resolution hidden in RX). > > > Another way to report this value is through "xsetwacom get pad ". It has > > > less challenge to implement. But, is it a good solution? Please share > > your > > > thoughts. > > > > what does it do? > > > > As I mentioned above, it tells the userland which LED is on/off. Basically > the generic status of the LEDs without default function associated. It will > be up to the app developers' to translate the status to the functions they > like. Driver interface could be simply a property with X booleans then. But the kernel interface is needed first. Cheers, Peter ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
