From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eduard Hasenleithner Subject: Re: [PATCH] Wacom Intuos4 LED and OLED control Date: Fri, 06 May 2011 19:32:11 +0200 Message-ID: <4DC4309B.9080605@hasenleithner.at> References: <1302303254-3062-1-git-send-email-eduard@hasenleithner.at> <20110506155204.GA4754@core.coreip.homeip.net> <4DC421BF.9020204@hasenleithner.at> <20110506164301.GA27419@core.coreip.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mail.ftw.at ([213.235.244.131]:59776 "EHLO mail.ftw.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754925Ab1EFRcP (ORCPT ); Fri, 6 May 2011 13:32:15 -0400 In-Reply-To: <20110506164301.GA27419@core.coreip.homeip.net> Sender: linux-input-owner@vger.kernel.org List-Id: linux-input@vger.kernel.org To: Dmitry Torokhov Cc: linux-input@vger.kernel.org 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.