On 29/09/11 22:31 , Michal Suchanek wrote: > On 29 September 2011 13:50, Peter Hutterer<peter.hutte...@who-t.net> wrote: >> On 29/09/11 21:41 , Michal Suchanek wrote: >>> >>> On 29 September 2011 13:16, Peter Hutterer<peter.hutte...@who-t.net> >>> wrote: >>>> >>>> On 29/09/11 20:55 , Michal Suchanek wrote: >>>>> >>>>> On 29 September 2011 11:19, Peter Hutterer<peter.hutte...@who-t.net> >>>>> wrote: >>>>>> >>>>>> On Thu, Sep 29, 2011 at 10:49:40AM +0200, Michal Suchanek wrote: >>>>>>> >>>>>>> On 29 September 2011 07:52, Peter Hutterer<peter.hutte...@who-t.net> >>>>>>> wrote: >>> >>>>>> No, xinput is device-independent and supposed to be generic. Some >>>>>> functions >>>>>> that are not specific to the wacom driver have been moved to xinput. >>>>>> There's >>>>>> a use fo xsetwacom as a simpler interface. e.g. xsetwacom set<device> >>>>>> TabletDebugLevel 3 is a lot simpler than xinput set-prop "device name" >>>>>> "propery name" 3 1 (you also have to know each property in full) >>>>>> >>>>> >>>>> You have to know (or list) the property with either tool. I don't see >>>>> why it's set to 3 in xsetwacom and 3 1 in xinput. AFAICT xinput is >>>>> very capable of setting device-specific properties exposed by the >>>>> driver. >>>> >>>> not every configuration option maps to a single property. Some properties >>>> contain multiple options. e.g. the debug property contains >>>> TabletDebugLevel >>>> and ToolDebugLevel. In order to set either, you need to set all (that's >>>> how >>>> xinput set-prop currently works) >>>> >>>> Besides, xinput does not do range checking in the client, it will simply >>>> return BadValue to the caller. xsetwacom will provide useful debug >>>> messages >>>> and a slightly improved UI (e.g. allowing for "on" or "off" instead of >>>> 0/1) >>> >>> Maybe the fact that xinput does not provide useful debug messages is a >>> bug in xinput then. >> >> uhm. have you read the X protocol specification? xinput sends off the >> property values. If they're good, nothing (visible to xinput) happens. If >> they're bad, xinput gets back a BadValue error that contains (iirc either >> the property or the invalid value, can't remember). >> xinput _cannot_ know why something is BadValue without knowing what the >> valid format, type and value range for a property is. And that requires >> driver-specific knowledge which xinput as generic tool doesn't have (and >> won't get). >> >> yes, the X protocol is bad for error reporting. we know that but we're stuck >> with it. > > They keep adding to XInput yet such basic thing as querying the valid > values of properties is still missing.
FWIW, when it comes to the XI protocol, "they" is mostly me. Anyway, properties are extremely flexible and that is also their drawback. It is not trivial to add range checking. Yes, for things like debug levels or behaviour on/off switches it's easy. But compare that to our button actions. The property for button actions is a list of atoms (where nitems == number of buttons) and each atom refers to another atom that must be a specific sequence of button action flags, depending on which keys and buttons are in use. I'm not sure how you could tell a generic client valid values for this property. 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
