On 2011-05-06 18:43, Dmitry Torokhov wrote:
I think it just complicates the interface. Even though all
3 values are transmitted to the device at the same time we can let
userspace set them individually and when sending data to the device use
cached values to complement the newly set one.
Ok, will be implemented this way.
* "status_select":
specifies the id (0..3) of the status led, -1 = none
I think we should create 4 separate groups led0 .. led3 each containing
the attributes above instead of implementing the selector which is
inherently racy.
It selects the led which is "on", the others are implicitly off. So
for the status led, there are five different settings, either 0..3,
or -1 for all LEDs to be off. Maybe "selector" is not the best
naming?
Hmm, my understanding of the device is hazy then. So you can select a
LED that will be activated/deactivated when user presses a certain
button on the device and the rest are staying off?
Apparently, for a device having only four LEDs wacom managed to
implement a behaviour, which is not easy to explain. These four LEDs
have two functions, one is the "status" LED function, the other is what
I call the "wheel function indicator" LED function.
Devices before Intuos4 just had a single status LED with three luminance
levels "high" and "low" and "off". When "off" it means that the device
is not ready for use (e.g driver not loaded, or device not connected).
When "low", this LED just says to the user "Driver loaded, ready for
input". When the stylus then touches the tablet surface, it lights with
the "high" level. The same behavior is also obvserved when the stylus is
in proximity to the tablet, and a button on the stylus is pressed. In
the end, having the status-LED at "high" level means that logically at
least one stylus "button" is pressed, including the vitual "stylus has
contact with tablet surface" button.
The Intuos4 adds the possibility to set the luminance levels for "high"
and "low" states, with values from 0..127. low=32 and high=64 means that
the status led will brighten during stylus contact, low=64 and high=32
will cause the status LED to dim during stylus contact.
With Intuos4 wacom also added a touch wheel to the tablet. In the
windows-driver it is possible to control four different "axes" with the
single touch wheel. In order to know which axis is controlled, they
could have simply added another four LEDs, with one of them being "on",
giving a total of five leds. But they saved one LED, and put the status
information to the one LED which shows the current wheel function
"selection".
The wheel selection function is only implemented in the driver. Changing
which LED is "on", does not change the events generated by the tabled.
So in the end, there are four "wheel function indicator" LEDs on the
device, with the active wheel function LED being also the status LED of
the device.
I was already planning to add this to this patch, but hesitated to
do it because the "README" tells to add the documentation when
"interfaces are felt to be stable as the main development of this
interface has been completed". Since we are still discussing the
interface, I got the feeling it is not yet "stable".
OK, fair enough, but then there will be an extra roundrip at the time
when I feel I am ready to apply the patch.
So, as you are fine with it, I will add the ABI documentation with the
next patch.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
