On 03/28/2012 10:30 PM, Peter Hutterer wrote: > On Wed, Mar 28, 2012 at 08:19:00PM -0700, Chase Douglas wrote: >> On 03/28/2012 05:09 PM, Peter Hutterer wrote: >> * Are we going to pay later for having variables like "want_scroll_axes" >> that configure axes like REL_DIAL? The variable is essentially >> controlling a whitelist. > > Yes, but not too badly I hope. Changes in scroll axes are few, so I think we > can live with this for now. Given how more and more devices move towards > touch-based interfaces, I doubt we'll see any new axes that are dedicated > towards scrolling in the near future.
How about going with the variable name "want_wheel_axes"? I just don't like it controlling a "dial" non-scroll axis too. >> Would we be better off having a default >> blacklist to disable REL_X and REL_Y if ABS_X and ABS_Y are supported, >> and letting everything else through? > > evdev has a either rel or absolute axis policy for largely historical > reasons. And the main reason is that I've seen devices that have both, > usually (but not always!) at least one set of axes are partially mute. > This is the main reason for the whole mess in evdev, I'd be glad to get rid > of it. > > Current servers _should_ be able to deal with relative events on > absolute axes and vice versa, though this needs more testing and I haven't > found the time to implement this yet. > The next step then is to figure out if clients can deal with it correctly, > having axis ranges for some axes but receiving values outside of it (my > guess is 'yes' since synaptics has been doing this for a while now, but > again this needs testing). > > So yeah, this is a hack, but it fixes a serious problem in server 1.12 + > evdev 2.7.0 and the only other solution is quite costly to implement. Ok, sounds good to me. [snip] >>> @@ -1852,12 +1940,16 @@ static void >>> EvdevInitAnyValuators(DeviceIntPtr device, EvdevPtr pEvdev) >>> { >>> InputInfoPtr pInfo = device->public.devicePrivate; >>> + int rel_success = FALSE; >>> >>> if (pEvdev->flags & EVDEV_RELATIVE_EVENTS && >>> EvdevAddRelValuatorClass(device) == Success) >>> + { >>> + rel_success = TRUE; >> >> The variable "rel_success" doesn't carry much connotation by itself. I >> think "has_rel_axes" would be better. > > I'll think of something, thanks. > has_rel_axes is used elsewhere with a different meaning and I don't want to > overload it either. this one here is really "relative axes successfully > initialised?" I worried about the name clash with has_rel_axes elsewhere too, but this is a small function and it would be a local variable. My personal opinion is that it's ok to clash like this. However, I understand if you disagree :). Maybe "rel_initialized"? -- Chase _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel