On Tue, Sep 27, 2011 at 5:30 AM, Eduard Hasenleithner <ehase...@gmail.com> wrote: > 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.
We are on the page here. Besides the touch ring, the leds also tell users which set of expresskey functions they can use though. > 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"). This is true for Intuos 4. Not for Cintiqs. To make the leds work consistently across models, we will keep at least one LED on, i.e., "all LEDs off" is not an option. > 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. You are 50% right here. Two sets of control is right. Touch strip is wrong. There is no touch strip for C21UX2. So, for C21UX2, the LEDs are for expresskeys only. > 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 Agree. That is what my code does too. > 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. I don't think we need to introduce new axes for the strips/rings. Application developers can decide which set of strip/ring/expresskey functions to set/send based on the status of the LED. One led value tells everything instead of repeating the same information in each ring/strip/expresskey is much clean and simple, I think. > 3) I propose to keep the function selector(s) in the X11 input driver. To some sense, I agree. In fact, I do not think we need to worry about the function selector(s) at all. It is up to the client to decide which function set to use for each led. We, I mean the X driver, only need to provide one set of default functions. That's the set we have now. > 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". I know ;). You are interested in the "fancy" features. But, the "function selector led" is the real function that client can use. That's why I am interested in 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. I am not planning to change your kernel code. I am suggesting to add a new event type (ABS_LED_STATUS) to the kernel so we can retrieve the led status in an unified way. Once the update is in the kernel, we can carry the support forward easily. >>> 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? No. Your kernel code will be 98% (if not 99% ;) unchanged. I will only update the interface to support 2 sets of LEDs and add ABS_LED_STATUS to report the status. >>> 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. I don't think we are on the same page here. There are two steps in handling the LEDs - gathering user action and switching the physical led status. The first step is in the X driver; the second step stays in the kernel as your code does. So, most new changes are in the X driver, instead of in the kernel. Are we getting closer now? Ping ------------------------------------------------------------------------------ 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
