On Mon, Jan 23, 2012 at 10:09:09AM -0800, Jason Gerecke wrote: > On Sun, Jan 22, 2012 at 8:43 PM, Peter Hutterer > <[email protected]> wrote: > > On Fri, Jan 20, 2012 at 10:56:23AM -0800, Jason Gerecke wrote: > >> Ping's out for a little while, so I'll be taking over the patch. I've > >> got other stuff on my plate though, so it may take some time to fold > >> in the changes. > >> > >> On Thu, Jan 19, 2012 at 8:13 PM, Peter Hutterer > >> <[email protected]> wrote: > >> > Thank you, I CC'd Eduard here to, he may have some comments related to > >> > his > >> > code. > >> > > >> > On Wed, Jan 18, 2012 at 04:25:42PM -0800, Ping Cheng wrote: > >> >> Signed-off-by: Ping Cheng <[email protected]> > >> >> --- > >> >> Changes to v1: > >> >> Updated test_parameter_number; > >> >> Added DBG to report sysfs node. > >> >> --- > >> >> include/wacom-properties.h | 3 ++ > >> >> man/xsetwacom.man | 7 ++++ > >> >> src/wcmCommon.c | 4 ++- > >> >> src/wcmConfig.c | 67 > >> >> +++++++++++++++++++++++++++++++++++++++++++- > >> >> src/wcmXCommand.c | 39 +++++++++++++++++++++++++- > >> >> src/xf86Wacom.c | 14 ++++++++- > >> >> src/xf86WacomDefs.h | 6 +++- > >> >> tools/xsetwacom.c | 18 +++++++++++- > >> >> 8 files changed, 152 insertions(+), 6 deletions(-) > >> >> > >> >> diff --git a/include/wacom-properties.h b/include/wacom-properties.h > >> >> index 0bb84b1..b2a3523 100644 > >> >> --- a/include/wacom-properties.h > >> >> +++ b/include/wacom-properties.h > >> >> @@ -46,6 +46,9 @@ > >> >> */ > >> >> #define WACOM_PROP_STRIPBUTTONS "Wacom Strip Buttons" > >> >> > >> >> +/* 8 bit, 2 values, LED0 (right side) and LED1 (left side) */ > >> >> +#define WACOM_PROP_LED "Wacom LEDs" > >> > > >> > I'd prefer "Wacom LED Luminosity" or something that hints at _what_ the > >> > property affects on the LEDs. In the future we may need a "Wacom LED > >> > colors", so we should differentiate from the start. > >> > > >> That sounds like a reasonable name, especially with the possibility of > >> multiple LED brightness levels (which I also think I remember seeing > >> something about) > > > > comment below > > > >> >> + > >> >> /* 8 bit, 6 values, rel wheel up, rel wheel down, abs wheel up, abs > >> >> wheel down, abs wheel 2 up, abs wheel 2 down > >> >> OR > >> >> Atom, 6 values , rel wheel up, rel wheel down, abs wheel up, abs > >> >> wheel down, abs wheel 2 up, abs wheel 2 down > >> >> diff --git a/man/xsetwacom.man b/man/xsetwacom.man > >> >> index dc0995f..97da416 100644 > >> >> --- a/man/xsetwacom.man > >> >> +++ b/man/xsetwacom.man > >> >> @@ -201,6 +201,13 @@ sets the max distance from tablet to stop > >> >> reporting movement for cursor in > >> >> relative mode. Default for Intuos series is 10, for Graphire series > >> >> (including > >> >> Volitos) is 42. Only available for the cursor/puck device. > >> >> .TP > >> >> +\fBLED0\fR status > >> >> +Set the right LED status of an Intuos4/Cintiq 21UX/Cintiq 24HD. > >> >> Default: 0, > >> >> +range of 0 to 3. > >> > > >> > what do those numbers refer to? > >> These numbers refer to the LED number that should be lit. At most one > >> LED in a bank may be lit at a time (both a hardware and sysfs > >> interface limitation). I haven't run the code myself, but it looks > >> like running "xsetwacom set <id> LED0 2" on an Intuos4 would result in > >> the third LED lighting up. Running "xsetwacom set <id> LED1 2" should > >> have no effect since the Intuos4 has only one bank of LEDs. It should > >> be noted that the 24HD is an odd case. All other tablets have 4 LEDs > >> per bank and one of them will always be lit. The 24HD has three LEDs, > >> and trying to set the 4th LED actually results in all the LEDs in that > >> bank turning off since the "lit" LED is non-existent. > > > > whoah, imo that exposes too much of the implementation. fwiw, I read the > > code as "the tablet has 2 LEDs with 4 brightness levels from 0..3". > > hence my "Luminosity" suggestion. > > > > how about a nice interface of one byte per LED, especially if we have 128 > > levels? Plus, I'd even argue to map the 0..128 range into 0.255, just to > > provide less-random scaling. But this exposes the main issue with this - > > it's again a driver-specific property that all clients need to know the > > exact details about. Because when range-mapped, a binary LED won't actually > A linear array with one (scaled) byte per LED is probably the easiest > interface we can provide and has a lot going for it. The main problem > I see is that its fairly misleading since the hardware isn't nearly as > flexible as the interface. That's not really a bad thing, just > annoying from the client's point of view since there's no way to know > beforehand which of your settings will actually "stick". > > > switch on for values 128+. What we really need here is a proper device class > > that also provides ranges and the ability to change the value. XI 2.3 > > anyone? > > > Its funny to think of LEDs being an "input" device, but I don't > suppose X really has a notion of "output" devices that act in remotely > the same manner. :(
true, output devices in X are devices to render to. if you look at the XI 1. specification, there is the notion of LED _feedback_ classes that do pretty much the above. They didn't get added to XI2 because they had virtually no users (keyboard LEs don't count here, they're handled differently). But, since the server still supports them it would be reasonably trivial to add some protocol exposure to XI2 and hook them up again. (note: "reasonaly trivial" means something else entirely when it comes to protocol additions) > >> > We'll likely have more LEDs in the future, so an interface of > >> > xsetwacom set ... LED 1 <status> seems better, similar to the Button > >> > interface. > >> > > >> I'd actually argue for "xsetwacom set <id> LED <bank> <led number>" > >> rather than a linear mapping. > > > > will the LEDs always be in banks? i've got a wireles I4 here and presumably > > the two LEDs that signal connection could one day be used for driver control > > too (hypothetical case). > > > > Also note that the property itself doesn't need to be the same format as the > > xsetwacom interface, e.g. property linearly, xsetwacom supports banks if > > given. > > > Those two LEDs would easily be a bank of their own, being both in > physical proximity to each other and being logically related. While I > like the idea of having xsetwacom allow for bank selection, there's no > reason we couldn't expose both banks and a linear array. The down side > to storing the LEDs as a linear array though is that the client > (xsetwacom or otherwise) has to have knowledge about the hardware to > realize that "bank N" starts at LED X and ends at LED Y. imo, this is what libwacom should provide, the knowledge which LED is on which bank in which phys. location. Cheers, Peter > > > Cheers, > > Peter > > > >> > also, IIRC at some point we talked about 255 levels for LEDs? > >> > > >> The kernel appears to support 128 levels through sysfs (see > >> "status0_luminance" and "status1_luminance"), so that could be added > >> as well. This would have to be done in a patch of its own though since > >> I don't have enough time to do the development and testing... > > > > Jason > > --- > Day xee-nee-svsh duu-'ushtlh-ts'it; > nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. > Huu-chan xuu naa~-gha. > ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
