On Tue, Sep 27, 2011 at 09:58:56AM -0700, Ping Cheng 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? > > The main purpose of ABS_LED_STATUS is to make the LED status device > independent to the user-land, which includes the X server driver. What > I wanted is for the client to be able to tell how many sets of LEDs > they expect without checking into the tablet ID. I thought that was > what you would like too. > > > absolute axes just have a min/max range (which I guess would be luminance?). > > You are right on the range ability. We need the max to tell the > userland how many LEDs are going to be reported. For I4, the max would > be 0x07: one set of 4 leds. The first 3 bits report the led number. > The forth bit indicates on/off. > > Then, for C21UX, it's 0x077 (2 sets of 4); and for C24HD 0x66 (two sets of 3).
urgh. this would make ABS_LED_STATUS be the only ABS_* axis where the values aren't values but are bitfields with semantic meaning. I don't think that's a good idea. It ruins any generic treatment of absolute axis since any user-space program would then have special treatment for this axis. > We do not report the brightness/luminance through ABS_LED_STATUS. It > is a status only value. Plus, brightness is not supported for Cintiq > tablets. > > > Wouldn't this be limited to one single LED then? > > Yes and the firmware only provides one LED on at one time. > > >> 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? > > That would require client to check the device ID. Or maybe I missed your > point? not really. the client would simply see a property with N values, where N is the number of status LEDs on the device. > > 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. > > In fact, I was trying to report the LED in such a way that X driver > doesn't even need to know the device model. > > There are two ways to implement this: > > 1. through sysfsctl: since the current interface doesn't provide the > set and number of LEDs info. We'll need to add new interface(s) for > it. The interface would be specific to Wacom driver only. > > 2. through ioctl: we need to add ABS_LED_STATUS. But once we have > that axis, the information can be reported and retrieved through the > standard ioctl interface as we do for the other ABS events. > > I choice option 2 since I think we should limit the customized > interface as much as we can. IMO at least as described above ABS_LED_STATUS is even more customized than the sysfs approach. Out of interest, can the LED_* interface not be changed? Why not add a LED_STATUS, LED_0, LED_1, etc to this interface? 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
