On Wed, Sep 28, 2011 at 08:36:47PM +0200, Eduard Hasenleithner wrote: > Hi > > 2011/9/28 Ping Cheng <pingli...@gmail.com>: > > On Wed, Sep 28, 2011 at 4:10 AM, Peter Hutterer > > <peter.hutte...@who-t.net> wrote: > >> sorry, I'm just going to reply to this message here instead of each of them > >> in the thread because otherwise my answers would be too split up. Also, I'm > >> a bit confused because some of the msgs in this thread seem contradictory. > >> > >> One important thing that I want to point out: xf86-input-wacom is an X > >> input > >> driver. It's point is to _enable_ access to functionality abstracting the > >> device-specifics away. It is not there to implement policy, that is up to > >> the client. > >> > >> So the LED should be controlled by the driver but only on request. > >> The client changes a driver property, the driver then goes off and changes > >> the LED. The driver doesn't have any function magic about what each button > >> does when the LED changes, it is up to the client to re-load the > >> configuration at the same time as the LED change. > >> The X driver will keep _one_ configuration for the button only. > > > > We can make the "xsetwacom led" a get and set command (instead of > > get-only). If end users can set led status, the following may happen: > > one user/app may change the status while the other wants it unchanged. > > How do we avoid this kind of conflict? > > > > We can also retrieve the status directly from sysfsctl without adding > > a new *_LED_* event. But this means the second user above won't be > > informed of the led switch. How does the second user know the status > > has been changed? Set a timer to retrieve the status isn't a good > > suggestion, is it? > > > > We don't have to implement policy. But it would be the driver's > > responsibility to make sure the car is safe. We want peace instead of > > conflicts. > > Ah, finally I understand the whole picture which Ping wanted me (us) > to tell. I see it similar. When looking at the 4 leds, I'm seeing > something like a software settable "rotary selection switch". > Applications want to be informed immediately when the value changes. > If not, the user would see the switch is on position B, while the > software thinks its still on A, and behave wrongly.
That's a software bug then. Clients will get notified about LED changes. > And on the Cintiqs, there are two of these virtual "rotary selection > switches". For me, reporting this as one (or in case of Cintiq two) > axis to X11 is reasonable. Having axes also gives the advantages of > being able to query the range. > > My current opinion is that this functionality should (if possible) be > implemented in the wacom X11 driver, not the wacom kernel driver. But > maybe having it in kernel is be better, since then the timing is even > more close to the led change. Again, the drivers should not have any policy about when to change the LED. Leave it up to the clients. 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
