On Mon, Sep 26, 2011 at 05:01:00PM -0700, Ping Cheng wrote: > On Mon, Sep 26, 2011 at 4:04 PM, Eduard Hasenleithner > <ehase...@gmail.com> wrote: > > Hi Ping > > > > Thanks for the ACK. > > > > 2011/9/27 Ping Cheng <pingli...@gmail.com>: > >> On Sun, Sep 25, 2011 at 1:23 PM, Eduard Hasenleithner > >> <edu...@hasenleithner.at> wrote: > >>> TODO: > >>> * Add function for setting the status led > >> > >> I am working on patches to support this function as well as retrieving > >> the LED status from the kernel. The code is for linuxwacom, the older > >> X servers, right now. I need to submit the kernel patch that adds > >> ABS_LED_STATUS before making patches for xf86-input-wacom.
I'm struggling understanding this. How would ABS_LED_STATUS work? absolute axes just have a min/max range (which I guess would be luminance?). Wouldn't this be limited to one single LED then? > > This brings us back to a previous discussion. Is this ABS_LED_STATUS > > really needed while already having the new wacom_led sysfs controls? > > I understand your point. If the sysfs is readable and writable, we > could retrieve the status from the sysfsctl directly. My design is > only for LED support and I want to control the LED through the round > button inside the X driver. > > I feel making the sysfs writable only and retrieving the status from > the EV_ABS ioctl as we do for all the other ABS values is more > intuitive. I don't plan to allow end users to switch the LED through > xsetwacom. That is, xsetwacom LED will be a read-only option. > > But, that is only my thought. I am not sure how the other developers > and you will take it. > > > If yes, doesn't it interfere with the status led selector of sysfs? > > No, it won't. The ABS_LED_STATUS will be updated inside the selector > and it can only be updated there. > > > I'm also asking, since I need to know if I should skip this point of > > the TODO list, or not. > > I don't know. My design is mainly for end users since they don't > need/want to know which bit controls which led. Yours makes sense to > those savvy users who know what they are doing. > > The tablet (Cintiq 21UX2) I am supporting has two sets of leds v.s. > Intuos4 only has one set. The Cintiq 24HD has two sets of different > leds setup, allowing users to switch led from xsetwacom requires that > they know the protocol/interface for each model. That defeats the > purpose of the driver. The feedback I got from the end users and > application developers is that they want the driver to provide a > generic way to switch the led for them. Huh? why can't this be done independently? If the I4 has 4 leds and the Cintiq has 8, why don't we just make the propery 4 or 8 values, depending on the model? How the LEDs are set doesn't matter to the user or xsetwacom, they just tweak the property. Cheers, Peter ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
