On Mon, Oct 03, 2011 at 09:55:52AM +0200, Michal Suchanek wrote: > On 3 October 2011 01:58, Peter Hutterer <peter.hutte...@who-t.net> wrote: > > On Fri, Sep 30, 2011 at 07:54:10PM +0200, Michal Suchanek wrote: > >> On 29 September 2011 23:12, Peter Hutterer <peter.hutte...@who-t.net> > >> wrote: > >> > 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. > >> > >> However, 90+ % of properties are numeric and have a simple integer or > >> float range. Also you can get the tablet into usable state by setting > >> up only numeric properties. > > > > not if you have a multi-screen setup. then you need the transformation > > matrix. Which technically is a numeric property but you still have to do the > > screen calculations to figure out what percentage you're mapping to. > > I have no damn transformation matrix because it is not possible to set > with the current tools. No matter what I do I have some default > slightly skewed matrix.
how comes? MapToOutput should work. define "skewed" > Also this is not what I would call a simple property. You have to know > what the transformation matrix is to set any reasonable value in it. that is the case with _any_ property. Setting PressureThreshold to some random value just becuase it's a simple property won't give you the behaviour you're looking for. > Still you need a value that is afaik not available through any > interface whatsoever: the tablet size. And that, for one, would be > available as a limit for other simple numeric property. The matrix is screen size related, not tablet size related. You don't need the tablet size to set the matrix. Either way, XIQueryDevice gives you the resolution and the min/max value of the x and y axis, from that you can calculate the physical size of the tablet. > I am not saying that *every* property can be set without any knowledge > in the client but still like 90% can if the can present the user with > the property name and the limits even if the property is new and the > client was not written with some inherent knowledge of it. > > > > >> It might be also helpful to set button actions separately for each > >> button so that you could tell which one failed but that's something > >> the client can do by reading the current actions and then changing > >> them one by one. > > > > We do the right thing in xsetwacom, including error reporting (I think). But > > the argument above was about xinput/generic tools where this breaks down. If > > The argument was mainly that since you know what and why is wrong with > the value the user set it would be useful if the knowledge did not > need to be in both the client and the driver. Why can't the driver > report the error by something but generic BadValue? the X protocol allows only for 32 byte errors. You can probably extend XGE to work for errors too but that's quite a chunk of work. So the more sensible approach would be to extend XIChangeProperty to reply with the status code. That needs to be done backwards-compatible and you need to figure out the protocol encoding for the errors you do want to return. of course, you won't cover all properties, so you'll end up with BadValue for some of them anyway. you can't also easily encode the dependency properties. so there are a few holes in this problem already where you end up just doing BadValue anyway. But another thing is that even if you can write the generic tool that copes with all properties - you _still_ require the user to read the documentation so they know what they're actually setting. at which point - well, you might as well return BadValue because that also forces to user to read what value was invalid and why this was the case. We have documentation for the properties in wacom-properties.h. If you want to move that over to the man pages please do so, I'll happily merge such patches. > > a device reports N properties, which one do you set one-by-one and which one > > do you set in bulk? Made more difficult by some devices where you may not > > You can hopefully decide by the type of the property. I think all properties in all input drivers together have either XA_INT, FLOAT or XA_ATOM as type. Neither of them is helpful in picking this. > > set property A to value X unless property B has value Y, or where property A > > cannot be set to X unless the second value in the property is also set to Y > > at the same time. > > This is really bad. Are properties like that really necessary? sometimes. 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
