On Mon, Oct 03, 2011 at 11:06:32AM +0200, Michal Suchanek wrote: > On 3 October 2011 10:13, Peter Hutterer <[email protected]> wrote: > > On Mon, Oct 03, 2011 at 09:55:52AM +0200, Michal Suchanek wrote: > >> On 3 October 2011 01:58, Peter Hutterer <[email protected]> wrote: > >> > On Fri, Sep 30, 2011 at 07:54:10PM +0200, Michal Suchanek wrote: > >> >> On 29 September 2011 23:12, Peter Hutterer <[email protected]> > >> >> wrote: > >> >> > On 29/09/11 22:31 , Michal Suchanek wrote: > >> >> >> > >> >> >> On 29 September 2011 13:50, Peter Hutterer<[email protected]> > >> >> >> wrote: > >> >> >>> > >> >> >>> On 29/09/11 21:41 , Michal Suchanek wrote: > >> >> >>>> > >> >> >>>> On 29 September 2011 13:16, Peter > >> >> >>>> Hutterer<[email protected]> > >> >> >>>> wrote: > >> >> >>>>> > >> >> >>>>> On 29/09/11 20:55 , Michal Suchanek wrote: > >> >> >>>>>> > >> >> >>>>>> On 29 September 2011 11:19, Peter > >> >> >>>>>> Hutterer<[email protected]> > >> >> >>>>>> wrote: > >> >> >>>>>>> > >> >> >>>>>>> On Thu, Sep 29, 2011 at 10:49:40AM +0200, Michal Suchanek wrote: > >> >> >>>>>>>> > >> >> >>>>>>>> On 29 September 2011 07:52, Peter > >> >> >>>>>>>> Hutterer<[email protected]> > >> >> >>>>>>>> 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. > > > > Ok, so you say that the X protocol is utterly broken and useless and > the driver cannot be feasibly configured over X protocol.
no, I didn't say that. The driver can be configured over the X protocol without issues. What I'm saying is that you can't write a generic client that knows the allowed values for every single property. > Let it attach to to dbus or something with reasonable semantics and use > that for configuring the driver and use X protocol only for reporting > events then. no. I'm not going to introduce another (incompatible) api connection to solve a nonexisting problem. 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
