On Wed, Sep 28, 2011 at 11:05:35AM -0700, Ping Cheng wrote: > On Wed, Sep 28, 2011 at 4:10 AM, Peter Hutterer > <[email protected]> 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?
how do we currently avoid one app setting the tip button to 1 and another app changing it to 3? We don't, it's not our problem. > 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? If the desktop is running, we assume that we control the device. So if anyone changes the LED through the driver properties, any client will get notified. We could put inotify watches on the sysfsctls but until we see other processes manipulate the sysfs this is a nonissue. Likewise, if anyone changes the button mapping through the properties, any client is notified. > 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. We're not the ones tasked with resolvinge conflicts. If you want to continue with the car analogy, we make sure that the car goes left when you turn the steering wheel. If two people fight over the steering wheel this is not something we need to care about. FYI read up on XKillClient(3). Any X client can issue this call and kill any other client. This isn't a problem because, well, any application that misuses this will feel the wrath of its user base quite quickly. The X desktop is a cooperative one already. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
