[PATCH 3/6] dix: when converting to XI 1.x events, use the first_valuator's device mode

Peter Hutterer peter.hutterer at who-t.net
Mon Nov 29 17:31:17 PST 2010


On Mon, Nov 29, 2010 at 08:21:26PM -0500, Chase Douglas wrote:
> On 11/29/2010 07:14 PM, Peter Hutterer wrote:
> > On Mon, Nov 29, 2010 at 11:14:02AM -0500, Chase Douglas wrote:
> >> On 11/22/2010 10:35 PM, Peter Hutterer wrote:
> >>> Don't stop processing events when a valuator's mode doesn't match the 0th
> >>> valuator's mode. Instead, start with the first_valuator in the event and
> >>> keep stacking them on until the first valuator with a different mode is hit.
> >>
> >> In XI 1.x, a device has one mode. My implementation assumed that the
> >> generated events must only have valuators that match that mode.
> >>
> >> What is supposed to occur when the XI 1 device is absolute, the first
> >> two valuators are absolute, the third is relative, and we are generating
> >> an event with only the third valuator changed?
> >>
> >> My understanding is that we shouldn't expose different mode valuators to
> >> XI 1.x clients at all. Thus, the event shouldn't be sent at all if it's
> >> sent as an XI 1.x event. However, I believe this patch would send the
> >> third axis.
> > 
> > this is a bit of an ambiguous issue in the XI1 specs and I should have
> > spotted that when reviewing your patches. this effort just isn't needed.
> > Let's just have a few clarifications first, because there is two
> > modes that we can perceive.
> > 
> > valuator mode can mean: does the axis send relative events to the client.
> > i.e. does the event contain -1/-1 or 123/424 when the pointer moved. in XI1,
> > there is no relative data in any event, all data sent to the client is
> > absolute.
> > 
> > device mode, which is in the XI specs, is "how does the device react to
> > input". this is best explained with a touchpad. by default, it is in
> > relative mode. although the data you get from the device itself is in
> > absolute coordinates, the driver converts it over to relative coordinates
> > and then posts this to the server. Thus, if you touch and move, you are
> > moving the cursor from its current position. If the touchpad was in absolute
> > mode, the cursor would first jump to the position representing the finger
> > position.
> > 
> > what happened with the mixed valuator patch set is that we mixed those two
> > but that's incorrect.
> > since the events are always absolute anyway, we can keep processing the
> > event. so even with XI1 clients, if we get the data -1/4833/+10/2828 from
> > the device the event contains <pointer pos + 1>/4833/<last.valuator[2] +
> > 10>/2828.
> > 
> > the only confusion that may arise in XI1 is that a device that announces
> > itself to be Relative still has some axes that _behave_ absolute, though
> > that is not obvious from the data.
> 
> So it sounds like XI 1.x device mode is just an indication of how the
> device behaves. The mode does not represent how data is actually
> transformed in the server other than in an abstract way of how movement
> on the device maps to cursor movement on screen.

correct. a device in relative mode may still post absolute coordinates to
the server and vice versa. the server does not take the mode into account.

> If I've got this right, then it sounds like XI 1.x mode and XI 2.x
> per-valuator modes are orthogonal. If so, then do we need any of this
> type of check in CountValuators at all?

no, hence
http://lists.freedesktop.org/archives/xorg-devel/2010-November/016029.html

Cheers,
  Peter


More information about the xorg-devel mailing list