Re: [PATCH 3/6] dix: when converting to XI 1.x events, use the first_valuator's device mode
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. Cheers, Peter ___ 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
Re: [PATCH 3/6] dix: when converting to XI 1.x events, use the first_valuator's device mode
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. 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? -- 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
Re: [PATCH 3/6] dix: when converting to XI 1.x events, use the first_valuator's device mode
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 ___ 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
Re: [PATCH 3/6] dix: when converting to XI 1.x events, use the first_valuator's device mode
On 11/29/2010 08:31 PM, Peter Hutterer wrote: On Mon, Nov 29, 2010 at 08:21:26PM -0500, Chase Douglas wrote: 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 Ok, so this patch should be NACK'd and the other ACK'd. -- 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
Re: [PATCH 3/6] dix: when converting to XI 1.x events, use the first_valuator's device mode
On Mon, Nov 29, 2010 at 08:49:00PM -0500, Chase Douglas wrote: On 11/29/2010 08:31 PM, Peter Hutterer wrote: On Mon, Nov 29, 2010 at 08:21:26PM -0500, Chase Douglas wrote: 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 Ok, so this patch should be NACK'd and the other ACK'd. or both on top of each other (the other one is already on master, see 048e93593e3f7a99a7d2a219e1ce2bdc9d407807 :) Cheers, Peter ___ 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
[PATCH 3/6] dix: when converting to XI 1.x events, use the first_valuator's device mode
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.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
dix/eventconvert.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/dix/eventconvert.c b/dix/eventconvert.c
index b92169e..dd17898 100644
--- a/dix/eventconvert.c
+++ b/dix/eventconvert.c
@@ -324,14 +324,16 @@ countValuators(DeviceEvent *ev, int *first)
for (i = 0; i sizeof(ev-valuators.mask) * 8; i++)
{
-/* Assume mode of 0th valuator matches XI1 device mode. Stop when the
- * event mode changes since XI1 can't handle mixed mode devices.
- */
-if (BitIsOn(ev-valuators.mode, i) != BitIsOn(ev-valuators.mode, 0))
-break;
-
if (BitIsOn(ev-valuators.mask, i))
{
+/* Assume mode of first_valuator matches XI1 device mode. Stop
when the
+ * event mode changes since XI1 can't handle mixed mode devices.
+ */
+if (first_valuator -1
+ BitIsOn(ev-valuators.mode, i) !=
+ BitIsOn(ev-valuators.mode, first_valuator))
+break;
+
if (first_valuator == -1)
first_valuator = i;
last_valuator = i;
--
1.7.3.2
___
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
