From: Peter H. <pet...@wh...> - 2009-10-12 03:00:20
|
On Sat, Oct 10, 2009 at 12:22:30PM -0700, Ping wrote: > On Wed, Oct 7, 2009 at 11:55 PM, Thomas Jaeger <thj...@gm...> wrote: > > > On Wed, Oct 7, 2009 at 10:10 PM, Peter Hutterer <pet...@wh...>wrote: > > > Sorry for the delay, bit flooded here. > > > Is it necessary to split those two up? I named it "Extra buttons" because > > I > > > couldnt really think of something better but they seem connected enough > > to > > > justify a single property. > > > > > > As Ping said in the other email, properties don't need to be > > human-readable > > > beyond a certain extent and I'd like to avoid having dozens of > > single-value > > > properties that all enable or disable a feature. To me it seemed that > > touch > > > and TPCButton are both a kind of button so they go well together. I'm > > happy > > > to be convinced otherwise. > > TPCButton isn't really a button, it rather controls when a button press > > is sent: If the option is disabled the driver sends a click as soon as > > the side switch is pressed, otherwise it is necessary to tap the pen to > > get a click. This applies to all wacom devices, I think. > > > > Tom is right. TPCButton can be applied to all tablet models (default to on > for TabletPC's and off for all the others). It is a common option, i.e., it > turns on/off for all tools that are associated with the same tablet. Due to > its common feature, maybe we can group it with a few other common options > (commonDBG, Suppress, Threshold? They don't belong together, I feel). So, > Peter, do you have any rules/preference for grouping them together? no hard rules, I'm just trying to group them as they make sense. If they don't make sense in a group just split them up. There's nothing wrong with having properties that only have a single value, I'm just trying to avoid the case where we have too many properties that affect more or less the same thing. the closest thing I can come to a hard rule is that if you look at the list of properties exported by a device, you should know immediately which property the setting you want to change belongs to. so with the examples you mentioned, Suppress and Threshold are related enough that they could be grouped (if you want to). commonDBG definitely in its own property (though I'm not a big fan of that property anyway, this should be a DIX property). I'm happy to apply the patches Tom sent, his explanations where enough to convince me. > > Touch seems to (I don't actually have a device that supports touch) just > > enable or disable touch events. So we might be able to kill the > > property altogether and use the DEVICE_ENABLE control on the touch > > device instead. > > How do we use the DEVICE_ENABLE control? Is it a generic property defined > by evdev or other low level driver/module? Can we enable/disable at our > wish from the driver? When we disable a device, do we just stop it from > sending data to Xinput or something else? Sorry for asking you instead of > searching for the answer myself. I am hoping to catch up with a shortcut. DEVICE_ENABLE is a control provided by XI (XChangeDeviceControl), but since server 1.6 we have a "Device Enabled" property that achieves the same effect. so instead of wacom having its own property it's better to re-use this property from the client-side tools. you don't actually have to do anything special inside the driver to support this property, if a client toggles it, the DEVICE_OFF/DEVICE_ON control proc is called. If you need to toggle it from within the driver (I don't think this is the case here?) you can use XIChangeDeviceProperty. Cheers, Peter |