Hi Ping. 2011/9/27 Ping Cheng <pingli...@gmail.com>: > On Mon, Sep 26, 2011 at 4:04 PM, Eduard Hasenleithner > <ehase...@gmail.com> wrote: >> 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. >> >> 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.
Wow, for several reasons, this discussion turns out to be more complicated than one would assume. If I would be in a situation like this at my workplace, I'd call for a meeting. Since we are several time zones apart, I think we have to stick with e-mail ;) So, I try first to establish a common ground for the (technical) discussion: The Intous4 has one so-called "touch ring". In xf86-input-wacom it behaves similar to a mouse scroll wheel in the sense of generating UP and DOWN events. So when I rotate it, I can scroll up and down a document. But this is not exactly what the touch ring was designed for. It was designed for things like zooming in/out, cycle layers in photoshop, change the brush size, etc. In order to avoid the need for multiple touch rings, four functions can be "shared" by the touch ring. Lets call this four functions the "function set". The center button of the touch ring is used for iterating functions of the function set. In order for the user to know which function is selected, one out of four leds is lit. To add some confusion, the manual calls them "status leds" since the led also indicates if the tabled is powered, and if the stylus touches the tablet surface (i.e. a stylus button is "pressed"). Apparently, the Cintiq 21ux2 has two independent sets of this control. Instead of "touch ring", it is called "touch strip" (yes, it has a different shape). And each of this strip has four status (i.e. function) leds. So you have always selected two functions from two different function sets. How the Cintiq 24HD fits into this discussion is unknown to me, since I couldn't download its manual. So, now we come to our design questions: 1) Where do we put the "function iterator button" handling 2) How (and if) do we expose the selected function to the X11 client 3) Do we keep the kernel driver like it is now, or do we add the "fake" ABS_LED_STATUS axis. My current answers to these design questions 1) The handling should be put in the X11 input driver 2) I'd suggest that we offer virtual "scroll wheel axis" to the X11 client. For the Intuos4 this would be 4 axis, for the Cintiq this would be 8 axis. Depending on which function is selected, only the corresponding virtual scroll wheel moves when the touch ring/strip is moved. The "function indicator" is not exposed to the X11 client. 3) I propose to keep the function selector(s) in the X11 input driver. Set the function selector to the first function at X11 server startup (i.e. X11 input driver load). > But, that is only my thought. I am not sure how the other developers > and you will take it. The main objection I have currently is to the kernel driver modification. But don't take that as a "veto". My only real interest is in the "Button Images". Aside from doing the roughly same as the windows driver, I have no Idea on what to do with the "function selector led". The main reason for being against a kernel change is, that kernel changes take much longer, and need much more coordination, than "only" changes in the X11 input driver. >> 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. So this means, we would need to remove the wacom_led/status_led_select sysfs control from the kernel driver, right? >> 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. Ok, the way you describe it, it doesn't make sense to handle the function selector led on the X11 client side. As mentioned, we need to discuss if we handle it either in the kernel or the X11 input driver. Eduard ------------------------------------------------------------------------------ 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
