On Wed, Jan 14, 2009 at 03:25:04AM -0800, Matt Helsley wrote: > On Sun, Jan 11, 2009 at 8:01 PM, Peter Hutterer <[email protected]> > wrote: > > Some comments purely related to your comments, not your code. I won't be > > able to look at your code today. > > > > On Sun, Jan 11, 2009 at 07:37:49PM -0800, Matt Helsley wrote: > >> Currently X, Y, and PRESSURE are special case axes in xf86-input-evdev. > >> This patch supports axes in a more general way. There are a few open > >> questions and TODOs: > >> > >> TODO: > >> Add REL axes. Since we currently limit evdev devices to > >> exclusively REL or ABS axes we can reuse the same vals > >> buffer in the device structure. > > > > This is actually a bit tricky. If we allow rel and abs for the same axis, we > > have to convert all relative events to absolute ones in the driver. Reason > > being that once the abs axes are set up, the server caps at the ranges. > > Based on this and the XI2 protocol spec discussion it looks like each axis > has a > separate mode (Absolute, Relative). I wasn't expecting that -- I figured it > would apply to the "whole device".
yes. XI2 will have, XI 1.x doesn't. But even if, this problem doesn't go away with XI2 either. Trying to paraphrase: the problem is devices trying to post two different axes through the same axis. In evdev, we "know" it's different because one comes up through ABS_X and one through REL_X but once we forward it through the server as X axis, we have to limit to the axis range. Example: Assuming that you set up an axis range 0..100 and you post a absolute event on 90/90, and then a relative event on the same device with 50/50 the axis is clipped to 100/100. > > > This is made slightly more complicated by the fact that a few devices (some > > popular mouse/keyboard combos) announce an ABS_X range of 256/256, so any > > relative X axis movement would get scaled to that range. > > For those we could look at the corresponding axis in rel_bitmask and, if it > exists, > we don't set up any corresponding abs axis in the server. Then we ignore any > input_events for ABS_<axis>. Of course we're then assuming that events from > the two > axes are in fact related to the same user action... this is basically what evdev currently does, although it does it with a sledgehammer and per-axis fine-tuning is needed. > Perhaps the really clever thing to do would be to compare the values coming in > during a "sample" input period. If the REL_ and ABS_ values correspond then we > know the axes are related. > > Unless there's something totally obvious I'm missing I don't think it's a > problem > we can cleanly solve. correct, and I would opt for giving relative abs precedence for now and (at a later point) adding configuration options to override this precedence. > One other thing that occured to me: the EV_SYN events are largely ignored. > This > means that a "pair" of X,Y movements are reported with as two X events -- > movement along X then movement along Y for example -- rather than one, > correct? > This is likely unnoticeable since the relative distance between these points > are > likely too small -- especially on reliable and modern devices. However it > still seems > like these input events should be accumulated in the pEvdev device and only > Post'ed when we see an EV_SYN. Has anyone ever tried this at some point? I thought that's what we did but we obviously don't. go for it :) Cheers, Peter _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
