[RFC] Multitouch support, step one
Alrighty, I've been thinking some more about multitouch and here's my current proposal: Good news first - we can probably make it work. Bad news second - not quite just yet, not without kludges. Preamble: Multi-touch as defined in this proposal is limited to single input-point multi-touch. This is suitable for indirect touch devices (e.g. touchpads) and partially suited for direct touch devices provided a touch is equivalent to a single-gesture single-application input. true multitouch, i.e. multiple independent input points across multiple client is not covered here, at this point this problem is unsolved. The trick is to get us the former, without limiting future use of the latter. Disclaimer: I believe this is pretty much what Win 7 or OS X do so I won't bother claiming this being innovative. This isn't exactly my idea either, I'm just writing up what I got from talking to Benjamin, Bradley, Henrik, Stephane, and many more. Details: The data we get from the (Linux) kernel includes essentially all the ABS_MT events, x, y, w, h, etc. We can pack this data into valuators on the device. In the simplest case, a device with two touchpoints would thus send 4 valuators - the first two being the coordinate pair for the first touch point, the latter two the coordinates for the second touch point. XI2 provides us with axis labels, so we can label the axes accordingly. Clients that don't read axis labels are left guessing what the fancy values mean, which is exactly what they're doing already anyway. XI2 DeviceEvents provide a bitmask for the valuators present in a device. Hence, a driver can dynamically add and remove valuators from events, thus providing information about the presence of these valuators. e.g. DeviceEvent with valuators [1-4] means two touchpoints down, if the next event only includes valuators [3-4], the first touchpoint has disappeared. Core requires us to always send x/y, hence for core emulation we should always include _some_ coordinates that are easily translated. While the server does caching of absolute values, I think it would be worthwile to always have an x/y coordinate _independent of the touchpoints_ in the event. The driver can decide which x/y coordinates are chosen if the first touchpoint becomes invalid. Hence, the example with 4 valuators above becomes a device with 6 valuators instead. x/y and the two coordinate pairs as mentioned above. If extra data is provided by the kernel driver, these pairs are simple extended into tuples of values, appropriately labeled. Core clients will ignore the touchpoints and always process the first two coordinates. XI1 clients will have to guess what the valuators mean or manually set it up in the client. XI2 clients will automagically work since the axes are labeled. Note that any client that receives such an event always has access to _all_ touchpoints on the device. This works fine for say 4-finger swipes on a touchpad but isn't overly useful for the multiple client case, see above. Since additional touchpoints are valuators only, grabs work as if the touches belong to a single device. If any client grabs this device, the others will miss out on the touchpoints. XI2 allows devices to change at runtime. Hence a device may add or remove valuators on-the-fly as touchpoints appear and disappear. There is a chance of a race condition here. If a driver decides to add/remove valuators together with the touchpoints, a client that skips events may miss out. e.g. if a DeviceChanged event that removes an axis is followed by one that adds an axis, a client may only take the second one as current, thus thinking the axis was never removed. There is nothing in the XI2 specs that prohibits this. Anyways, adding removing axes together with touchpoints seems superfluous if we use the presence of an axis as indicator for touch. Rather, I think a device should be set up with a fixed number of valuators describing the default maximum number of touchpoints. Additional ones can be added at runtime if necessary. Work needed: - drivers: updated to parse ABS_MT_FOO and forward it on. - X server: the input API still uses the principle of first + num_valuators instead of the bitmask that the XI2 protocol uses. These calls need to be added and then used by the drivers. - Protocol: no protocol changes are necessary, though care must be taken in regards to XI1 clients. Although the XI2 protocol does allow device changes, this is not specified in the XI1 protocol, suggesting that once a device changes, potential XI1 clients should be either ignored or limited to the set of axes present when they issued the ListInputDevices request. Alternatively, the option is to just encourage XI1 clients to go the way of the dodo. Corner cases: We currently have a MAX_VALUATORS define of 32. This may or may not be arbitrary and interesting things may or may not happen if we increase that. A device exposing several axes _and_ multitouch axes will need to be
Re: [RFC] Multitouch support, step one
On Mon, 15 Mar 2010 16:56:05 +1000 Peter Hutterer peter.hutte...@who-t.net said: cool - no comment here means ok :) so just comments on the questioney bits. Alrighty, I've been thinking some more about multitouch and here's my current proposal: Good news first - we can probably make it work. Bad news second - not quite just yet, not without kludges. Preamble: Multi-touch as defined in this proposal is limited to single input-point multi-touch. This is suitable for indirect touch devices (e.g. touchpads) and partially suited for direct touch devices provided a touch is equivalent to a single-gesture single-application input. true multitouch, i.e. multiple independent input points across multiple client is not covered here, at this point this problem is unsolved. The trick is to get us the former, without limiting future use of the latter. Disclaimer: I believe this is pretty much what Win 7 or OS X do so I won't bother claiming this being innovative. This isn't exactly my idea either, I'm just writing up what I got from talking to Benjamin, Bradley, Henrik, Stephane, and many more. Details: The data we get from the (Linux) kernel includes essentially all the ABS_MT events, x, y, w, h, etc. We can pack this data into valuators on the device. In the simplest case, a device with two touchpoints would thus send 4 valuators - the first two being the coordinate pair for the first touch point, the latter two the coordinates for the second touch point. XI2 provides us with axis labels, so we can label the axes accordingly. Clients that don't read axis labels are left guessing what the fancy values mean, which is exactly what they're doing already anyway. ok. here is where i ask.. what are these labels to be?pointless knowing there are labels - unless we know what they should be to indicate what is what. it's still guessing if we don't know what they should be :) XI2 DeviceEvents provide a bitmask for the valuators present in a device. Hence, a driver can dynamically add and remove valuators from events, thus providing information about the presence of these valuators. e.g. DeviceEvent with valuators [1-4] means two touchpoints down, if the next event only includes valuators [3-4], the first touchpoint has disappeared. Core requires us to always send x/y, hence for core emulation we should always include _some_ coordinates that are easily translated. While the server does caching of absolute values, I think it would be worthwile to always have an x/y coordinate _independent of the touchpoints_ in the event. The driver can decide which x/y coordinates are chosen if the first touchpoint becomes invalid. hmm so ok. i press 1 finger down - i get a xi2 event with N*2 valuators (N being the maximum # of touch points supported lets say). bitmask tells me which are active. what about core events? i press 1 finger down - i'll get a xi2 event AND a core event. how do i know this for sure? how do i know even though xi2 claims to have an input device for mt input - that it may not send events (it's used differently). now i press a 2nd finger - no problems. core events and xi2 events keep coming - now i release my first finger. what happens to core events. from the above i gather that the driver will keep sending core events now - but for the remaining pressed finger. right? Hence, the example with 4 valuators above becomes a device with 6 valuators instead. x/y and the two coordinate pairs as mentioned above. If extra data is provided by the kernel driver, these pairs are simple extended into tuples of values, appropriately labeled. Core clients will ignore the touchpoints and always process the first two coordinates. first 2 that are active of first 2 - if not active then no core events? XI1 clients will have to guess what the valuators mean or manually set it up in the client. XI2 clients will automagically work since the axes are labeled. Note that any client that receives such an event always has access to _all_ touchpoints on the device. This works fine for say 4-finger swipes on a touchpad but isn't overly useful for the multiple client case, see above. Since additional touchpoints are valuators only, grabs work as if the touches belong to a single device. If any client grabs this device, the others will miss out on the touchpoints. aaah but as above.. no automagic working without knowing these labels :) XI2 allows devices to change at runtime. Hence a device may add or remove valuators on-the-fly as touchpoints appear and disappear. There is a chance of a race condition here. If a driver decides to add/remove valuators together with the touchpoints, a client that skips events may miss out. e.g. if a DeviceChanged event that removes an axis is followed by one that adds an axis, a client may only take the second one as current, thus thinking the axis was never removed. There is nothing in the XI2 specs that prohibits this. Anyways,
Re: [RFC] Multitouch support, step one
On Mon, Mar 15, 2010 at 06:36:15PM +1100, Carsten Haitzler wrote: On Mon, 15 Mar 2010 16:56:05 +1000 Peter Hutterer peter.hutte...@who-t.net said: cool - no comment here means ok :) so just comments on the questioney bits. Alrighty, I've been thinking some more about multitouch and here's my current proposal: Good news first - we can probably make it work. Bad news second - not quite just yet, not without kludges. Preamble: Multi-touch as defined in this proposal is limited to single input-point multi-touch. This is suitable for indirect touch devices (e.g. touchpads) and partially suited for direct touch devices provided a touch is equivalent to a single-gesture single-application input. true multitouch, i.e. multiple independent input points across multiple client is not covered here, at this point this problem is unsolved. The trick is to get us the former, without limiting future use of the latter. Disclaimer: I believe this is pretty much what Win 7 or OS X do so I won't bother claiming this being innovative. This isn't exactly my idea either, I'm just writing up what I got from talking to Benjamin, Bradley, Henrik, Stephane, and many more. Details: The data we get from the (Linux) kernel includes essentially all the ABS_MT events, x, y, w, h, etc. We can pack this data into valuators on the device. In the simplest case, a device with two touchpoints would thus send 4 valuators - the first two being the coordinate pair for the first touch point, the latter two the coordinates for the second touch point. XI2 provides us with axis labels, so we can label the axes accordingly. Clients that don't read axis labels are left guessing what the fancy values mean, which is exactly what they're doing already anyway. ok. here is where i ask.. what are these labels to be?pointless knowing there are labels - unless we know what they should be to indicate what is what. it's still guessing if we don't know what they should be :) See Benjamin's commit a34812b09000db2ff2a1dc6182602839123edd4e on master. The idea is that your 2-touchpoint device provides the following labels, Abs X, Abs Y, Abs MT Position X, Abs MT Position Y, Abs MT Position X, Abs MT Potision Y. Having said that, I now realise that it's hard to tell them apart this way, you can only look for repetition in axes. This is a fair assumption I guess, I'm not sure if any devices have different capabilities on different touchpoints. XI2 DeviceEvents provide a bitmask for the valuators present in a device. Hence, a driver can dynamically add and remove valuators from events, thus providing information about the presence of these valuators. e.g. DeviceEvent with valuators [1-4] means two touchpoints down, if the next event only includes valuators [3-4], the first touchpoint has disappeared. Core requires us to always send x/y, hence for core emulation we should always include _some_ coordinates that are easily translated. While the server does caching of absolute values, I think it would be worthwile to always have an x/y coordinate _independent of the touchpoints_ in the event. The driver can decide which x/y coordinates are chosen if the first touchpoint becomes invalid. hmm so ok. i press 1 finger down - i get a xi2 event with N*2 valuators (N being the maximum # of touch points supported lets say). bitmask tells me which are active. what about core events? i press 1 finger down - i'll get a xi2 event AND a core event. Any event is only ever sent as _either_ XI, XI2 or core. Besides, are you listening for core events and XI2 at the same time? If so, why? The idea of XI2 was that once a client acknowledges XI2 exists, core events should be a thing of the past for this client. If it's listening to both it'll have to magically find out which events are caused by the same device. how do i know this for sure? how do i know even though xi2 claims to have an input device for mt input - that it may not send events (it's used differently). now i press a 2nd finger - no problems. core events and xi2 events keep coming - now i release my first finger. what happens to core events. from the above i gather that the driver will keep sending core events now - but for the remaining pressed finger. right? nearly correct, yes. Drivers don't send core events. They send events, and some of these events may be delivered as core events depending on the position of the pointer, etc. A driver has no say over what is a core event or not (this has changed with 1.6 but even before that it wasn't strictly enforcable). Your example is why I suggested to always add x/y to the touch points, the driver is the most likely thing to know which point should be chosen when the first finger leaves the area. This may be either the second touchpoint or the logical centre of the remaining touchpoints, or... Hence, the example with 4 valuators above becomes a
Re: [RFC] Multitouch support, step one
Peter, I did not found the time last week to respond, so I will do now Le 15/03/2010 09:50, Peter Hutterer a écrit : On Mon, Mar 15, 2010 at 06:36:15PM +1100, Carsten Haitzler wrote: On Mon, 15 Mar 2010 16:56:05 +1000 Peter Huttererpeter.hutte...@who-t.net said: cool - no comment here means ok :) so just comments on the questioney bits. Alrighty, I've been thinking some more about multitouch and here's my current proposal: Good news first - we can probably make it work. Bad news second - not quite just yet, not without kludges. Preamble: Multi-touch as defined in this proposal is limited to single input-point multi-touch. This is suitable for indirect touch devices (e.g. touchpads) and partially suited for direct touch devices provided a touch is equivalent to a single-gesture single-application input. true multitouch, i.e. multiple independent input points across multiple client is not covered here, at this point this problem is unsolved. The trick is to get us the former, without limiting future use of the latter. And I think this would be very a good point for linux to say that we can have real multitouch with different application. Disclaimer: I believe this is pretty much what Win 7 or OS X do so I won't bother claiming this being innovative. This isn't exactly my idea either, I'm just writing up what I got from talking to Benjamin, Bradley, Henrik, Stephane, and many more. Details: The data we get from the (Linux) kernel includes essentially all the ABS_MT events, x, y, w, h, etc. We can pack this data into valuators on the device. In the simplest case, a device with two touchpoints would thus send 4 valuators - the first two being the coordinate pair for the first touch point, the latter two the coordinates for the second touch point. As Carsten said, we could send all the MT-valuators for each touch. Thus, having the description of valuators as: Val0_not_mt, Val1_not_mt, ... Val_i_not_mt, TrackingID0, ABS_MT_X0, ABS_MT_Y0, other_mt_0, TrackingID1, ABS_MT_X1, etc XI2 provides us with axis labels, so we can label the axes accordingly. Clients that don't read axis labels are left guessing what the fancy values mean, which is exactly what they're doing already anyway. ok. here is where i ask.. what are these labels to be?pointless knowing there are labels - unless we know what they should be to indicate what is what. it's still guessing if we don't know what they should be :) See Benjamin's commit a34812b09000db2ff2a1dc6182602839123edd4e on master. The idea is that your 2-touchpoint device provides the following labels, Abs X, Abs Y, Abs MT Position X, Abs MT Position Y, Abs MT Position X, Abs MT Potision Y. agree, but remember to send the other axes. Having said that, I now realise that it's hard to tell them apart this way, you can only look for repetition in axes. This is a fair assumption I guess, I'm not sure if any devices have different capabilities on different touchpoints. I never seen such a device, and I don't understand how could it be. The most strange device I get is the Apple Magic Mouse, which is both relative and absolute, but all the touch points are the same. By the way I don't think that the kernel could handle such a device as it serializes the valuators, and if a touch does not report an axe, it will have its value at 0. XI2 DeviceEvents provide a bitmask for the valuators present in a device. Hence, a driver can dynamically add and remove valuators from events, thus providing information about the presence of these valuators. e.g. DeviceEvent with valuators [1-4] means two touchpoints down, if the next event only includes valuators [3-4], the first touchpoint has disappeared. I made a few test yesterday (involuntary though) with the magic mouse. As we can send only part of the valuators, why not packing the different available touches at the beginning. It will require to move some valuators, but if we keep sending the trackingID, it won't hurt the client. An other point for keeping the valuator trackingID. Some device (stantum and magicmouse) send a trackingID different than touch point. i.e. the trackingID is between 1 and 255 on the stantum, and between 1 and 16 on the magic mouse. I don't know if the user app should use this, or a higher level id could do the job. Core requires us to always send x/y, hence for core emulation we should always include _some_ coordinates that are easily translated. While the server does caching of absolute values, I think it would be worthwile to always have an x/y coordinate _independent of the touchpoints_ in the event. The driver can decide which x/y coordinates are chosen if the first touchpoint becomes invalid. hmm so ok. i press 1 finger down - i get a xi2 event with N*2 valuators (N being the maximum # of touch points supported lets say). bitmask tells me which are active. what about core events? i press 1 finger down - i'll get a xi2 event AND a core event. Any event
Re: [RFC] Multitouch support, step one
Peter Hutterer writes: [snip] Details: The data we get from the (Linux) kernel includes essentially all the ABS_MT events, x, y, w, h, etc. We can pack this data into valuators on the device. In the simplest case, a device with two touchpoints would thus send 4 valuators - the first two being the coordinate pair for the first touch point, the latter two the coordinates for the second touch point. Short comment: There will be more valuators; a max of 32 is not enough. Long version: I think this undersells the number of valuators that MT devices will provide. I am only really familiar with Apple's Magic Mouse, but I understand Apple's other MT devices report similar data (except for not having actual, touch-independent X/Y/button data). The Magic Mouse has hardware touch tracking, and reports the orientation, semi-major axis length, semi-minor axis length, touch area and a state or event bitmask for each touch. The tracking ID will probably be the most useful for applications, followed by touch area (the mouse can report a touch before physical contact occurs). I am not sure how gesture recognition would use the ellipse data, but I am pretty sure that some applications will want them. The interpretation of the state/event bitmask is currently unclear, so it could be reasonably omitted. With the standard X/Y valuators and buttons as a base, and a likely desire to emulate vertical and horizontal scroll wheels outside the application, the Magic Mouse needs ~5 + 7*N valuators for N touches -- with a 32 valuator limit, it will only be able to pass some of the hardware fields to applications. So, as a non-X developer, I would like that limit to go up. Barring that, I would like some notional plan on what the long-term solution will look like if the short-term solution involves truncated event reports. Michael Poole ___ 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] dix: be more verbose when we run out of opcodes
Em Sex, 2010-03-12 às 23:06 +0100, Julien Cristau escreveu:
On Fri, Mar 12, 2010 at 12:01:41 -0300, Paulo Ricardo Zanoni wrote:
From: Paulo Ricardo Zanoni pzan...@mandriva.com
Date: Thu, 11 Mar 2010 14:28:18 -0300
Subject: [PATCH] dix: be more verbose when we run out of opcodes
If we run out of opcodes, nothing is print on the log, making the
problem hard to debug. In the current Xserver, if you enable some
extensions like multibuffer (+2 events) and use nvidia binary driver (+5
events) you can run out of opcode numbers.
Signed-off-by: Paulo Ricardo Zanoni pzan...@mandriva.com
---
dix/extension.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/dix/extension.c b/dix/extension.c
index fb83af1..30dc313 100644
--- a/dix/extension.c
+++ b/dix/extension.c
@@ -83,8 +83,11 @@ AddExtension(char *name, int NumEvents, int NumErrors,
if (!MainProc || !SwappedMainProc || !MinorOpcodeProc)
return((ExtensionEntry *) NULL);
if ((lastEvent + NumEvents LAST_EVENT) ||
- (unsigned)(lastError + NumErrors LAST_ERROR))
+ (unsigned)(lastError + NumErrors LAST_ERROR)) {
+ LogMessage(X_ERROR, Not enabling extension %s: maximum number of
+ events or errors exceeded.\n, name);
funky whitespace on the LogMessage (not the same as the return below).
I'm not sure if this is what you meant, but the attached version
replaces tabs with whitespaces. It applies fine with
--whitespace=error-all
Btw, the whole file is not consistent about the usage of whitespaces or
tabs... Open it with vim and do set list listchars=tab:_ to see the
result. In most of the cases, tab is used when possible.
return((ExtensionEntry *) NULL);
+}
ext = xalloc(sizeof(ExtensionEntry));
if (!ext)
With that fixed,
Reviewed-by: Julien Cristau jcris...@debian.org
Cheers,
Julien
From c54afc8805dbc9482a1b6c8b85caf0aad2820fe9 Mon Sep 17 00:00:00 2001
From: Paulo Ricardo Zanoni pzan...@mandriva.com
Date: Thu, 11 Mar 2010 14:28:18 -0300
Subject: [PATCH] dix: be more verbose when we run out of opcodes
If we run out of opcodes, nothing is print on the log, making the
problem hard to debug. In the current Xserver, if you enable some
extensions like multibuffer (+2 events) and use nvidia binary driver (+5
events) you can run out of opcode numbers.
Signed-off-by: Paulo Ricardo Zanoni pzan...@mandriva.com
---
dix/extension.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/dix/extension.c b/dix/extension.c
index fb83af1..30dc313 100644
--- a/dix/extension.c
+++ b/dix/extension.c
@@ -83,8 +83,11 @@ AddExtension(char *name, int NumEvents, int NumErrors,
if (!MainProc || !SwappedMainProc || !MinorOpcodeProc)
return((ExtensionEntry *) NULL);
if ((lastEvent + NumEvents LAST_EVENT) ||
- (unsigned)(lastError + NumErrors LAST_ERROR))
+ (unsigned)(lastError + NumErrors LAST_ERROR)) {
+LogMessage(X_ERROR, Not enabling extension %s: maximum number of
+ events or errors exceeded.\n, name);
return((ExtensionEntry *) NULL);
+}
ext = xalloc(sizeof(ExtensionEntry));
if (!ext)
--
1.6.4.4
___
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: [RFC] Multitouch support, step one
Hi Peter,
Alrighty, I've been thinking some more about multitouch and here's my
current proposal:
Good news first - we can probably make it work.
Bad news second - not quite just yet, not without kludges.
I hope this feedback will be taken the right way, as a friendly injection into
the multitouch discussion. :-)
Preamble:
Multi-touch as defined in this proposal is limited to single input-point
multi-touch. This is suitable for indirect touch devices (e.g. touchpads)
and partially suited for direct touch devices provided a touch is equivalent
to a single-gesture single-application input.
User-space applications need tools to *use* MT devices, not route raw data from
the devices to the application. The latter is not much more complicated than
opening a file, and everyone can do that already. Thus, unless there is a model
for how MT devices work and interact with other MT devices, I see little point
in having an X protocol at all.
Details:
The data we get from the (Linux) kernel includes essentially all the ABS_MT
events, x, y, w, h, etc. We can pack this data into valuators on the device.
In the simplest case, a device with two touchpoints would thus send 4
valuators - the first two being the coordinate pair for the first touch
point, the latter two the coordinates for the second touch point.
XI2 provides us with axis labels, so we can label the axes accordingly.
Clients that don't read axis labels are left guessing what the fancy values
mean, which is exactly what they're doing already anyway.
The idea of a wide set of dimensions to describe a set of fingers for instance,
was considered and dropped for the kernel MT interface. There is a definite
difference between having three things and having two more of the same kind.
The number of dimensions also increases dramatically, as pointed out by Mr.
Poole. It makes much more sense to define contacts as multiple instances of the
same thing, than to define each new contact as potentially something completely
different.
XI2 DeviceEvents provide a bitmask for the valuators present in a device.
Hence, a driver can dynamically add and remove valuators from events, thus
providing information about the presence of these valuators.
e.g. DeviceEvent with valuators [1-4] means two touchpoints down, if the
next event only includes valuators [3-4], the first touchpoint has
disappeared.
The idea of adding and removing contacts dynamically I believe is a good idea. A
contact has a set of attributes (x, y, etc). Why not provide a clean interface
for the contacts as a concept, rather than mapping the not-so-independent x and
y values into separate dynamic entities? As an example of the smallest
meaningful dynamic entity:
struct Contact {
int tracking_id;
float x, y;
etc etc...
};
Core requires us to always send x/y, hence for core emulation we should
always include _some_ coordinates that are easily translated. While the
server does caching of absolute values, I think it would be worthwile to
always have an x/y coordinate _independent of the touchpoints_ in the event.
The driver can decide which x/y coordinates are chosen if the first
touchpoint becomes invalid.
Seconded, but the single-touch x/y coordinates are properties of a contact
group, not of a single contact. Example:
struct ContactGroup {
int group_id;
float x, y;
ContactList list;
etc etc...
};
Hence, the example with 4 valuators above becomes a device with 6 valuators
instead. x/y and the two coordinate pairs as mentioned above. If extra data
is provided by the kernel driver, these pairs are simple extended into
tuples of values, appropriately labeled.
Core clients will ignore the touchpoints and always process the first two
coordinates.
XI1 clients will have to guess what the valuators mean or manually set it up
in the client.
XI2 clients will automagically work since the axes are labeled. Note that
any client that receives such an event always has access to _all_
touchpoints on the device. This works fine for say 4-finger swipes on a
touchpad but isn't overly useful for the multiple client case, see
above.
This is at the heart of the problem, I believe. In addition to being able to
work with a set of ContactGroups, like ContactGroupList, one needs the
possibility to dynamically regroup them, based on geometric information and what
not. Partitioning is the word. A toolset consisting of at least these functions:
ContactGroupList partition_contacts_geometrically(ContactList all_contacts);
ContactGroupList partition_contacts_by_user(ContactList all_contacts);
ContactGroupList find_contact_groups_in_window(ContactGroupList all_groups);
etc etc
ought to be the minimum requirement on the interface, such that applications can
do something meaningful with the information at hand.
Since additional touchpoints are valuators only, grabs work as if the
touches belong to a single device. If any
Re: [PULL] Minor bug-fixes discovered by static analysis.
On Tue, 09 Mar 2010 12:56:33 +0200, Oliver McFadden oliver.mcfad...@nokia.com wrote: Yeah, okay; my bad then. I will resend the patches individually. Were you going to post these patches so we can finish up the review process? -- keith.pack...@intel.com pgpKngsde70L6.pgp Description: PGP signature ___ 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: [PULL] Cygwin build fixes, XF8Bigfont warnings
On Thu, 11 Mar 2010 14:53:21 -0600, Yaakov (Cygwin/X) yselkow...@users.sourceforge.net wrote: These patches were all previously sent to this list, but some were ignored. The following changes since commit f2eacb4646beb25d055de22868f93e6b24f229b6: Peter Hutterer (1): Revert dix: Use DeliverGrabbedEvent for implicit passive grabs (#25400) are available in the git repository at: git://anongit.freedesktop.org/~yselkowitz/xserver.git master Yaakov Selkowitz (8): Cygwin/X: Fix make dist after 11252ed82e1f361b99e86521ac9314f868bd1a3a Cygwin/X: Fix windres rule for automake silent rules Use libtool -export-dynamic flag for portability Rename xdmx client to dmxinfo These all seem fine to me Reviewed-by: Keith Packard kei...@keithp.com Xext: fix prototype warnings in xf86bigfont.c dix: fix XF86Bigfont declaration warnings in dixfonts.c os: fix XF86Bigfont declaration warnings in log.c mi: remove deprecated #include X11/extensions/xf86bigfstr.h in miinitext.c These all put function declarations in .c files instead of headers where they belong. You can't exactly get function signature typechecking if the definition and declaration are never compared by the compiler... Also, please don't mix reviewed and unreviewed patches in a single PULL request. -- keith.pack...@intel.com pgpG2KdAlvaq6.pgp Description: PGP signature ___ 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: [PATCHv10 4/5] dri2: Support the DRI2InvalidateBuffers event.
I want to get this patch sequence merged, can someone point me at a repository that I can pull it in from? -- keith.pack...@intel.com pgpblwPFW8OPQ.pgp Description: PGP signature ___ 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] DRI2: fixup handling of last_swap_target
I've got a few more fixes to land, I'll ask Kristian and Mario for final review this week, then send you a pull req. Thanks, Jesse Keith Packard kei...@keithp.com wrote: Is this patch sequence ready to be merged now? The email thread doesn't seem to be resolved yet Also, make sure patches are reviewed before asking for them to be merged... -- keith.pack...@intel.com ___ 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: [RFC] Multitouch support, step one
Simon Thum wrote: Henrik, if I'm anywhere near understanding this, then probably your're missing an important point. This is _step one_. Getting information to where you need it and giving it a basic structure, roughly. That is indeed the whole point -- giving it a basic structure. I am suggesting the basic structure is built around the concept of contacts. The things you're talking about are more suited as a step two: Making sense of the information. Along those lines, you're probably right, though I'd go even further. But ATM concensus is needed how to transport MT information in a suitable and forward-compatible manner. The first step is an important one. I doubt the solution will be forward-compatible unless the basic concept is put in place from the start. The basic concept is point contacts appearing and disappearing, so why not formulate the interface in such terms. Henrik ___ 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: [RFC] Multitouch support, step one
On Mar 15, 2010, at 09:01, Simon Thum wrote: Henrik, if I'm anywhere near understanding this, then probably your're missing an important point. This is _step one_. Getting information to where you need it and giving it a basic structure, roughly. The things you're talking about are more suited as a step two: Making sense of the information. Along those lines, you're probably right, though I'd go even further. But ATM concensus is needed how to transport MT information in a suitable and forward-compatible manner. The sooner this is nailed down, the sooner more abstract concepts can be tackled. Cheers, Simon I agree that application developers want something higher level. The structure that Henrik describes will be more beneficial to application developers. The point now is to determine who actually provides that data. Do we want tracking and grouping to be handled by the Xserver and sent to the client as such, or do we want to send the raw data to the client and have a library interpret these data and provide the client with these pretty structures? It seems like the latter can make use of the already-existing XI2 protocol. If we try to do this all in the server and package it up for the user, will we be looking at yet another bump of XI? Can we do it in a way that will be compatible with XI2? I actually like the idea of using the valuators to send the data over the wire. Why not use the valuators to also send data like: valuator 0 = core X valuator 1 = core Y valuator 2 = multi-touch 0 tracking id valuator 3 = multi-touch 0 group id valuator 4 = multi-touch 0 x valuator 5 = multi-touch 0 y valuator 6 = multi-touch 0 pressure valuator 7 = multi-touch 1 tracking id valuator 8 = multi-touch 1 group id valuator 9 = multi-touch 1 x valuator 10 = multi-touch 1 y valuator 11 = multi-touch 1 pressure More complex data management could then be handled by a client-side library. This still does not solve the valuator limit of 32. How difficult will it be to eliminate that maximum and have no limit? --Jeremy smime.p7s Description: S/MIME cryptographic signature ___ 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: Confusing or confused code
On Thu, 2010-03-11 at 12:59 +0100, Michael Thayer wrote: Hello, I suspect that this code: http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/common/xf86Mode.c?id=326429badfc76885e4652ddc72860810c0e8d102#n1300 until line 1313 is supposed to be freeing the old list at scrp-clockRanges, duplicating the user supplied list and storing it there. If that is right, then it looks to me though like it will not work unless scrp-clockRanges is initially NULL AFAICT yes; if -clockRanges is not initially NULL, then we will not store the duplicated list there. Which seems goofy. and the user only supplies a list with a single element. In that, after the first memcpy, storeClockRanges-next and cp-next will point to the same place, so subsequent copies will just be lost in space, yeah. Did I miss something important there? I think your analysis is right, that code's garbage. At least in the case of virtual drivers like vboxvideo, I think we should reasonably allow you to just pass in NULL for clockRanges. But it's trivial to set up just one range that's sufficient to cover everything. Gross, but sufficient. - ajax signature.asc Description: This is a digitally signed message part ___ 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: [RFC] Multitouch support, step one
Jeremy Huddleston wrote: I actually like the idea of using the valuators to send the data over the wire. Why not use the valuators to also send data like: valuator 0 = core X valuator 1 = core Y valuator 2 = multi-touch 0 tracking id valuator 3 = multi-touch 0 group id valuator 4 = multi-touch 0 x valuator 5 = multi-touch 0 y valuator 6 = multi-touch 0 pressure valuator 7 = multi-touch 1 tracking id valuator 8 = multi-touch 1 group id valuator 9 = multi-touch 1 x valuator 10 = multi-touch 1 y valuator 11 = multi-touch 1 pressure If this is the way you want to go, you might want to consider splitting the data into a stream of events, such that you only need to define valuators for one contact, then send the information for each each contact sequentially. I would also consider using a lower-level protocol such as a buffered device stream, to avoid the semantic multiplexing introduced by the above approach. Henrik ___ 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: [PULL] Minor bug-fixes discovered by static analysis.
On Mon, 2010-03-15 at 16:23 +0100, ext Keith Packard wrote: On Tue, 09 Mar 2010 12:56:33 +0200, Oliver McFadden oliver.mcfad...@nokia.com wrote: Yeah, okay; my bad then. I will resend the patches individually. Were you going to post these patches so we can finish up the review process? Sorry about the delay; I was traveling and currently on vacation. I'm sending them now. -- Oliver. ___ 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/5] parser: xf86readConfigFile: unreachable: This code cannot be reached: free(val.str);
Signed-off-by: Oliver McFadden oliver.mcfad...@nokia.com
---
hw/xfree86/parser/read.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/parser/read.c b/hw/xfree86/parser/read.c
index 1091be5..4e42b24 100644
--- a/hw/xfree86/parser/read.c
+++ b/hw/xfree86/parser/read.c
@@ -219,15 +219,15 @@ xf86readConfigFile (void)
}
else
{
- Error (INVALID_SECTION_MSG, xf86tokenString ());
free(val.str);
val.str = NULL;
+ Error (INVALID_SECTION_MSG, xf86tokenString ());
}
break;
default:
- Error (INVALID_KEYWORD_MSG, xf86tokenString ());
free(val.str);
val.str = NULL;
+ Error (INVALID_KEYWORD_MSG, xf86tokenString ());
}
}
--
1.6.1
___
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 2/5] fb: fbFinishScreenInit: leaked_storage: Variable (visuals|depths) goes out of scope
Signed-off-by: Oliver McFadden oliver.mcfad...@nokia.com
Reviewed-by: Matt Turner matts...@gmail.com
---
fb/fbscreen.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/fb/fbscreen.c b/fb/fbscreen.c
index 24eadde..53e2ada 100644
--- a/fb/fbscreen.c
+++ b/fb/fbscreen.c
@@ -228,7 +228,11 @@ fbFinishScreenInit(ScreenPtr pScreen,
rootdepth = 0;
if (!fbInitVisuals (visuals, depths, nvisuals, ndepths, rootdepth,
defaultVisual,((unsigned long)1(imagebpp-1)), 8))
+{
+ xfree (visuals);
+ xfree (depths);
return FALSE;
+}
if (! miScreenInit(pScreen, pbits, xsize, ysize, dpix, dpiy, width,
rootdepth, ndepths, depths,
defaultVisual, nvisuals, visuals))
--
1.6.1
___
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 5/5] Xext: IdleTimeBlockHandler: unsigned_compare: Comparing unsigned less than zero is never true. timeout 0UL
Signed-off-by: Oliver McFadden oliver.mcfad...@nokia.com
---
Xext/sync.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/Xext/sync.c b/Xext/sync.c
index ce65314..cf78cdc 100644
--- a/Xext/sync.c
+++ b/Xext/sync.c
@@ -2329,10 +2329,8 @@ IdleTimeBlockHandler(pointer env, struct timeval **wt,
pointer LastSelectMask)
} else {
for (list = IdleTimeCounter-pTriglist; list; list = list-next) {
trig = list-pTrigger;
- if (trig-CheckTrigger(trig, old_idle)) {
- timeout = min(timeout, 0);
+ if (trig-CheckTrigger(trig, old_idle))
break;
- }
}
}
--
1.6.1
___
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
Minor bug-fixes discovered by static analysis.
Hi, This is the same as the pull request, but in easier to review patch format. I have added Matt Turner's Reviewed-by lines to the patches he checked as OK. [PATCH 1/5] exa: exaFinishAccess: Overrun of static array pExaScr-access of size 6 at position 6 with index variable i [PATCH 2/5] fb: fbFinishScreenInit: leaked_storage: Variable (visuals|depths) goes out of scope [PATCH 3/5] parser: xf86readConfigFile: unreachable: This code cannot be reached: free(val.str); [PATCH 4/5] common: xf86Configure: alloc_strlen: Allocated memory does not have space for the terminating NUL of the string [PATCH 5/5] Xext: IdleTimeBlockHandler: unsigned_compare: Comparing unsigned less than zero is never true. timeout 0UL I think the last one (IdleTimeBlockHandler: unsigned_compare) might not be enough, but then that's the whole point of the review process. P.S. I am on vacation currently so please accept my apologies if my replies are delayed. Regards, -- Oliver. ___ 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 1/5] exa: exaFinishAccess: Overrun of static array pExaScr-access of size 6 at position 6 with index variable i
Signed-off-by: Oliver McFadden oliver.mcfad...@nokia.com --- exa/exa.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/exa/exa.c b/exa/exa.c index c5ac7de..590d9a5 100644 --- a/exa/exa.c +++ b/exa/exa.c @@ -417,8 +417,8 @@ exaFinishAccess(DrawablePtr pDrawable, int index) /* Catch unbalanced Prepare/FinishAccess calls. */ if (i == EXA_NUM_PREPARE_INDICES) - EXA_FatalErrorDebug((EXA bug: FinishAccess called without PrepareAccess for pixmap 0x%p.\n, -pPixmap)); + EXA_FatalErrorDebugWithRet((EXA bug: FinishAccess called without PrepareAccess for pixmap 0x%p.\n, + pPixmap),); pExaScr-access[i].pixmap = NULL; -- 1.6.1 ___ 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: Confusing or confused code
Le lundi 15 mars 2010 à 14:52 -0400, Adam Jackson a écrit : On Thu, 2010-03-11 at 12:59 +0100, Michael Thayer wrote: http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/common/xf86Mode.c?id=326429badfc76885e4652ddc72860810c0e8d102#n1300 until line 1313 is supposed to be freeing the old list at scrp-clockRanges, duplicating the user supplied list and storing it there. If that is right, then it looks to me though like it will not work unless scrp-clockRanges is initially NULL [snip] I think your analysis is right, that code's garbage. At least in the case of virtual drivers like vboxvideo, I think we should reasonably allow you to just pass in NULL for clockRanges. But it's trivial to set up just one range that's sufficient to cover everything. Gross, but sufficient. Certainly, and it's never caused me any pain - I just wanted to point it out in case it caught someone else at some point. And sorry for not trying a fix or anything, but I don't actually build the X server very often, just our own drivers. Regards, Michael -- Sun Microsystems GmbHMichael Thayer Werkstrasse 24 VirtualBox engineer 71384 Weinstadt, Germany mailto:michael.tha...@sun.com Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder ___ 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/5] parser: xf86readConfigFile: unreachable: This code cannot be reached: free(val.str);
Are you sure you're not freeing the value that Error will be printing?
val.str is unfortunately a global, that seems to be set at least some times
to the same pointer that xf86tokenString() may return.
(Does it even matter if we free or not? Does returning an error from
config file parsing ever not cause the server to exit?)
-alan-
Oliver McFadden wrote:
Signed-off-by: Oliver McFadden oliver.mcfad...@nokia.com
---
hw/xfree86/parser/read.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/parser/read.c b/hw/xfree86/parser/read.c
index 1091be5..4e42b24 100644
--- a/hw/xfree86/parser/read.c
+++ b/hw/xfree86/parser/read.c
@@ -219,15 +219,15 @@ xf86readConfigFile (void)
}
else
{
- Error (INVALID_SECTION_MSG, xf86tokenString ());
free(val.str);
val.str = NULL;
+ Error (INVALID_SECTION_MSG, xf86tokenString ());
}
break;
default:
- Error (INVALID_KEYWORD_MSG, xf86tokenString ());
free(val.str);
val.str = NULL;
+ Error (INVALID_KEYWORD_MSG, xf86tokenString ());
}
}
--
-Alan Coopersmith- alan.coopersm...@sun.com
Oracle Solaris Platform Engineering: X Window System
___
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] xkb: Check and load precompiled .xkm during startup if available
New 'precompiled' subdir is added to xkb data dir, allowing to pre-compile
keymaps to be loaded when server starts and hence avoid running xkbcomp, saving
a bit of time.
Signed-off-by: Mikhail Gusarov dotted...@dottedmag.net
---
xkb/ddxLoad.c | 53 +++--
1 files changed, 47 insertions(+), 6 deletions(-)
diff --git a/xkb/ddxLoad.c b/xkb/ddxLoad.c
index 4ccddda..939835f 100644
--- a/xkb/ddxLoad.c
+++ b/xkb/ddxLoad.c
@@ -174,6 +174,35 @@ OutputDirectory(
}
}
+/*
+ * Returns True if precompiled keymap is found and conveys keymap name in
+ * keymapName variable.
+ *
+ * Returns False if no precompiled keymap is found or keymapName buffer is too
+ * small.
+ */
+static Bool
+XkbDDXGetPrecompiledKeymap(XkbComponentNamesPtr names,
+ char *keymapName,
+ int keymapNameLen)
+{
+if (!XkbBaseDirectory)
+return FALSE;
+
+int ret = snprintf(keymapName, keymapNameLen,
+ %s/precompiled/%s-%s-%s-%s-%s.xkm,
+ XkbBaseDirectory,
+ names-keycodes ? names-keycodes : def,
+ names-types ? names-types : def,
+ names-compat ? names-compat : def,
+ names-symbols ? names-symbols : def,
+ names-geometry ? names-geometry : def);
+if (ret == keymapNameLen)
+return FALSE;
+
+return access(keymapName, R_OK) == 0;
+}
+
static Bool
XkbDDXCompileKeymapByNames(XkbDescPtr xkb,
XkbComponentNamesPtrnames,
@@ -336,6 +365,7 @@ XkbDDXLoadKeymapByNames(DeviceIntPtrkeybd,
XkbDescPtr xkb;
FILE * file;
char fileName[PATH_MAX];
+Bool unlinkFile;
unsigned missing;
*xkbRtrn = NULL;
@@ -349,12 +379,22 @@ unsigned missing;
keybd-name ? keybd-name : (unnamed keyboard));
return 0;
}
-else if (!XkbDDXCompileKeymapByNames(xkb,names,want,need,
- nameRtrn,nameRtrnLen)){
- LogMessage(X_ERROR, XKB: Couldn't compile keymap\n);
- return 0;
+
+if (XkbDDXGetPrecompiledKeymap(names, nameRtrn, nameRtrnLen)) {
+unlinkFile = FALSE;
+strncpy(fileName, nameRtrn, PATH_MAX);
+file = fopen(nameRtrn, rb);
+} else {
+unlinkFile = TRUE;
+
+if (!XkbDDXCompileKeymapByNames(xkb, names, want, need,
+nameRtrn, nameRtrnLen)) {
+LogMessage(X_ERROR, XKB: Couldn't compile keymap\n);
+return 0;
+}
+file= XkbDDXOpenConfigFile(nameRtrn,fileName,PATH_MAX);
}
-file= XkbDDXOpenConfigFile(nameRtrn,fileName,PATH_MAX);
+
if (file==NULL) {
LogMessage(X_ERROR, Couldn't open compiled keymap file %s\n,fileName);
return 0;
@@ -370,7 +410,8 @@ unsignedmissing;
DebugF(Loaded XKB keymap %s,
defined=0x%x\n,fileName,(*xkbRtrn)-defined);
}
fclose(file);
-(void) unlink (fileName);
+if (unlinkFile)
+unlink(fileName);
return (need|want)(~missing);
}
--
1.6.3.3
___
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] Make APM support optional
Add new --disable-apm configure switch to compile out APM
support in xfree86 and kdrive.
Signed-off-by: Mikhail Gusarov dotted...@dottedmag.net
---
configure.ac |2 +
hw/kdrive/linux/Makefile.am |5 +
hw/kdrive/linux/apm.c | 121 +
hw/kdrive/linux/apm.h |8 ++
hw/kdrive/linux/linux.c | 92 +++---
hw/xfree86/os-support/bsd/Makefile.am | 10 ++-
hw/xfree86/os-support/linux/Makefile.am |2 +
hw/xfree86/os-support/solaris/Makefile.am |8 ++-
8 files changed, 163 insertions(+), 85 deletions(-)
create mode 100644 hw/kdrive/linux/apm.c
create mode 100644 hw/kdrive/linux/apm.h
diff --git a/configure.ac b/configure.ac
index 3e8ea10..f911f98 100644
--- a/configure.ac
+++ b/configure.ac
@@ -631,6 +631,7 @@ AC_ARG_ENABLE(xaa,
AS_HELP_STRING([--enable-xaa], [Build XAA (defa
AC_ARG_ENABLE(vgahw, AS_HELP_STRING([--enable-vgahw], [Build Xorg
with vga access (default: enabled)]), [VGAHW=$enableval], [VGAHW=yes])
AC_ARG_ENABLE(vbe,AS_HELP_STRING([--enable-vbe], [Build Xorg with
VBE module (default: enabled)]), [VBE=$enableval], [VBE=yes])
AC_ARG_ENABLE(int10-module, AS_HELP_STRING([--enable-int10-module], [Build
Xorg with int10 module (default: enabled)]), [INT10MODULE=$enableval],
[INT10MODULE=yes])
+AC_ARG_ENABLE(apm, AS_HELP_STRING([--enable-apm], [Build Xorg with APM support
(default: enabled)]), [APM=$enableval], [APM=yes])
dnl DDXes.
AC_ARG_ENABLE(xorg, AS_HELP_STRING([--enable-xorg], [Build
Xorg server (default: auto)]), [XORG=$enableval], [XORG=auto])
@@ -1129,6 +1130,7 @@ AM_CONDITIONAL(XF86UTILS, test x$XF86UTILS = xyes)
AM_CONDITIONAL(XAA, test x$XAA = xyes)
AM_CONDITIONAL(VGAHW, test x$VGAHW = xyes)
AM_CONDITIONAL(VBE, test x$VBE = xyes)
+AM_CONDITIONAL(APM, test x$APM = xyes)
AM_CONDITIONAL(INT10MODULE, test x$INT10MODULE = xyes)
AC_DEFINE(SHAPE, 1, [Support SHAPE extension])
diff --git a/hw/kdrive/linux/Makefile.am b/hw/kdrive/linux/Makefile.am
index 93e5d2f..e9f311f 100644
--- a/hw/kdrive/linux/Makefile.am
+++ b/hw/kdrive/linux/Makefile.am
@@ -10,6 +10,11 @@ liblinux_la_SOURCES =
liblinux_la_SOURCES += linux.c
+if APM
+AM_CFLAGS += -DHAVE_APM
+liblinux_la_SOURCES += apm.c apm.h
+endif
+
if KDRIVE_KBD
liblinux_la_SOURCES += keyboard.c
endif
diff --git a/hw/kdrive/linux/apm.c b/hw/kdrive/linux/apm.c
new file mode 100644
index 000..bc51e04
--- /dev/null
+++ b/hw/kdrive/linux/apm.c
@@ -0,0 +1,121 @@
+/*
+ * Copyright © 1999 Keith Packard
+ * Copyright © 2010 Mikhail Gusarov dotted...@dottedmag.net
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that
+ * copyright notice and this permission notice appear in supporting
+ * documentation, and that the name of Keith Packard not be used in
+ * advertising or publicity pertaining to distribution of the software without
+ * specific, written prior permission. Keith Packard makes no
+ * representations about the suitability of this software for any purpose. It
+ * is provided as is without express or implied warranty.
+ *
+ * KEITH PACKARD DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL KEITH PACKARD BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ * PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include kdrive-config.h
+#endif
+#include kdrive.h
+
+#include errno.h
+#include sys/ioctl.h
+#include linux/apm_bios.h
+
+#include apm.h
+
+#ifdef FNONBLOCK
+#define NOBLOCK FNONBLOCK
+#else
+#define NOBLOCK FNDELAY
+#endif
+
+static int LinuxApmFd = -1;
+static Bool LinuxApmRunning;
+
+static void
+LinuxApmBlock (pointer blockData, OSTimePtr pTimeout, pointer pReadmask)
+{
+}
+
+static void
+LinuxApmWakeup (pointer blockData, int result, pointer pReadmask)
+{
+fd_set *readmask = (fd_set *) pReadmask;
+
+if (result 0 LinuxApmFd = 0 FD_ISSET (LinuxApmFd, readmask))
+{
+ apm_event_t event;
+ Boolrunning = LinuxApmRunning;
+ int cmd = APM_IOC_SUSPEND;
+
+ while (read (LinuxApmFd, event, sizeof (event)) == sizeof (event))
+ {
+ switch (event) {
+ case APM_SYS_STANDBY:
+ case APM_USER_STANDBY:
+ running = FALSE;
+ cmd = APM_IOC_STANDBY;
+ break;
+ case APM_SYS_SUSPEND:
+ case APM_USER_SUSPEND:
+ case APM_CRITICAL_SUSPEND:
+ running =
[PATCH 1/2] kdrive: Bump evdev maxKeycode
There are keycodes 193 in evdev, e.g. KEY_WIMAX which is 246 . Signed-off-by: Mikhail Gusarov dotted...@dottedmag.net --- hw/kdrive/linux/evdev.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/kdrive/linux/evdev.c b/hw/kdrive/linux/evdev.c index 485a2b5..946d5c1 100644 --- a/hw/kdrive/linux/evdev.c +++ b/hw/kdrive/linux/evdev.c @@ -362,7 +362,7 @@ readMapping (KdKeyboardInfo *ki) return; ki-minScanCode = 0; -ki-maxScanCode = 193; +ki-maxScanCode = 0xff; } static void -- 1.6.3.3 ___ 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] xkb: Check and load precompiled .xkm during startup if available
On Tue, Mar 16, 2010 at 04:45:51AM +0600, Mikhail Gusarov wrote:
New 'precompiled' subdir is added to xkb data dir, allowing to pre-compile
keymaps to be loaded when server starts and hence avoid running xkbcomp,
saving
a bit of time.
Good idea. Do you have any numbers on how much time this actually saves?
IIRC we only run xkbcomp once at the moment and then re-used the cached
values. Is skipping this one run beneficial?
What happens if xkeyboard-config is updated after an xkm has been
precompiled? Do the users need to recompile? This is my main worry, it'll
make triaging of nonworking keyboard layouts quite tricky.
Cheers,
Peter
Signed-off-by: Mikhail Gusarov dotted...@dottedmag.net
---
xkb/ddxLoad.c | 53 +++--
1 files changed, 47 insertions(+), 6 deletions(-)
diff --git a/xkb/ddxLoad.c b/xkb/ddxLoad.c
index 4ccddda..939835f 100644
--- a/xkb/ddxLoad.c
+++ b/xkb/ddxLoad.c
@@ -174,6 +174,35 @@ OutputDirectory(
}
}
+/*
+ * Returns True if precompiled keymap is found and conveys keymap name in
+ * keymapName variable.
+ *
+ * Returns False if no precompiled keymap is found or keymapName buffer is
too
+ * small.
+ */
+static Bool
+XkbDDXGetPrecompiledKeymap(XkbComponentNamesPtr names,
+ char *keymapName,
+ int keymapNameLen)
+{
+if (!XkbBaseDirectory)
+return FALSE;
+
+int ret = snprintf(keymapName, keymapNameLen,
+ %s/precompiled/%s-%s-%s-%s-%s.xkm,
+ XkbBaseDirectory,
+ names-keycodes ? names-keycodes : def,
+ names-types ? names-types : def,
+ names-compat ? names-compat : def,
+ names-symbols ? names-symbols : def,
+ names-geometry ? names-geometry : def);
+if (ret == keymapNameLen)
+return FALSE;
+
+return access(keymapName, R_OK) == 0;
+}
+
static Bool
XkbDDXCompileKeymapByNames( XkbDescPtr xkb,
XkbComponentNamesPtrnames,
@@ -336,6 +365,7 @@ XkbDDXLoadKeymapByNames( DeviceIntPtrkeybd,
XkbDescPtr xkb;
FILE * file;
char fileName[PATH_MAX];
+Bool unlinkFile;
unsigned missing;
*xkbRtrn = NULL;
@@ -349,12 +379,22 @@ unsignedmissing;
keybd-name ? keybd-name : (unnamed keyboard));
return 0;
}
-else if (!XkbDDXCompileKeymapByNames(xkb,names,want,need,
- nameRtrn,nameRtrnLen)){
- LogMessage(X_ERROR, XKB: Couldn't compile keymap\n);
- return 0;
+
+if (XkbDDXGetPrecompiledKeymap(names, nameRtrn, nameRtrnLen)) {
+unlinkFile = FALSE;
+strncpy(fileName, nameRtrn, PATH_MAX);
+file = fopen(nameRtrn, rb);
+} else {
+unlinkFile = TRUE;
+
+if (!XkbDDXCompileKeymapByNames(xkb, names, want, need,
+nameRtrn, nameRtrnLen)) {
+LogMessage(X_ERROR, XKB: Couldn't compile keymap\n);
+return 0;
+}
+file= XkbDDXOpenConfigFile(nameRtrn,fileName,PATH_MAX);
}
-file= XkbDDXOpenConfigFile(nameRtrn,fileName,PATH_MAX);
+
if (file==NULL) {
LogMessage(X_ERROR, Couldn't open compiled keymap file %s\n,fileName);
return 0;
@@ -370,7 +410,8 @@ unsigned missing;
DebugF(Loaded XKB keymap %s,
defined=0x%x\n,fileName,(*xkbRtrn)-defined);
}
fclose(file);
-(void) unlink (fileName);
+if (unlinkFile)
+unlink(fileName);
return (need|want)(~missing);
}
--
1.6.3.3
___
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 1/2] kdrive: Bump evdev maxKeycode
On Tue, Mar 16, 2010 at 04:48:30AM +0600, Mikhail Gusarov wrote: There are keycodes 193 in evdev, e.g. KEY_WIMAX which is 246 . Signed-off-by: Mikhail Gusarov dotted...@dottedmag.net --- hw/kdrive/linux/evdev.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/kdrive/linux/evdev.c b/hw/kdrive/linux/evdev.c index 485a2b5..946d5c1 100644 --- a/hw/kdrive/linux/evdev.c +++ b/hw/kdrive/linux/evdev.c @@ -362,7 +362,7 @@ readMapping (KdKeyboardInfo *ki) return; ki-minScanCode = 0; -ki-maxScanCode = 193; +ki-maxScanCode = 0xff; the other kdrive servers use 255 instead of 0xff, it'd be nice to use the same for consistency. With that change Reviewed-by: Peter Hutterer peter.hutte...@who-t.net 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] Atomic query requests
On Mon, Mar 15, 2010 at 12:06:15PM -0400, Adam Jackson wrote:
Signed-off-by: Adam Jackson a...@redhat.com
---
fixesproto.txt | 57 +--
xfixesproto.h | 54 +
xfixeswire.h |7 -
3 files changed, 113 insertions(+), 5 deletions(-)
diff --git a/fixesproto.txt b/fixesproto.txt
index 5ef8153..9d0547f 100644
--- a/fixesproto.txt
+++ b/fixesproto.txt
@@ -1,7 +1,7 @@
The XFIXES Extension
- Version 4.0
- Document Revision 2
- 2006-12-14
+ Version 5.0
+ Document Revision 1
+ 2010-03-15
Keith Packard
kei...@keithp.com
@@ -160,6 +160,7 @@ current cursor and provides a way to identify cursor
images to avoid
refetching the image each time it changes to a previously seen cursor.
7.1 Types
+
CURSOREVENT { DisplayCursor }
7.2 Events
@@ -566,6 +567,56 @@ ShowCursor
Servers supporting the X Input Extension Version 2.0 or higher show
all visible cursors in response to a ShowCursor request.
+* XFIXES VERSION 5 OR BETTER ***
+
+12. Atomic queries
+
+Some core protocol requests return information about only a few windows,
+when the application often wants information about the hierarchy all the
+way to the root. In order to get consistent information this has to be
+done under a server grab, which is impolite when the client is remote.
+
+12.1 Types
+
+ POINTERWINDOW { Window w,
+ CARD16 x,
+ CARD16 y }
+
+12.2 Requests
+
+QueryPointer
+
+ -
+
+ mask: SETofKEYBUTMASK
+ pointer_windows:LISTofPOINTERWINOW
+
+ This request returns the list of windows that contain the cursor,
+ from leafmost to rootmost, and the cursor's offset within each.
+ It also returns the current button mask for the pointer.
+
+ Unlike the core QueryPointer request, this does not take a root
+ window argument a priori; the client simply receives the cursor
+ state for whichever root window the cursor happens to be on. If
+ the cursor is on no screen (for example, in a dead area between
+ screens, or owned by a native window system) a zero-sized list
+ is returned.
I think this one should leave room for the device ID. Gtk is being ported to
XI2 already, so not including a device specifier is likely to bite us quite
soon. Having said that, this makes the mask more complex as well since the
XI2 mask usage is more verbose than the core one.
Cheers,
Peter
+
+QueryAncestors
+
+ window: WINDOW
+
+ -
+
+ windows:LISTofWINDOW
+
+ This request returns the list of ancestors of the named window,
+ from nearest to rootmost. If the named window is a root window,
+ a zero-sized list is returned.
+
+ If the window argument does not name a defined window, BadWindow
+ is generated.
+
99. Future compatibility
This extension is not expected to remain fixed. Future changes will
diff --git a/xfixesproto.h b/xfixesproto.h
index 545e325..9b745bb 100644
--- a/xfixesproto.h
+++ b/xfixesproto.h
@@ -500,6 +500,60 @@ typedef struct {
#define sz_xXFixesShowCursorReq sizeof(xXFixesShowCursorReq)
+typedef struct {
+CARD8 reqType;
+CARD8 xfixesReqType;
+CARD16 length B16;
+} xXFixesQueryPointerReq;
+
+#define sz_xXFixesQueryPointerReq sizeof(xXFixesQueryPointerReq)
+
+typedef struct {
+Window window B32;
+CARD16 x B16;
+CARD16 y B16;
+} xXFixesPointerWindow;
+
+typedef struct {
+BYTEtype; /* X_Reply */
+BYTEpad1;
+CARD16 sequenceNumber B16;
+CARD32 length B32;
+CARD16 mask B16;
+CARD16 pad2 B16;
+CARD32 numWindows B32;
+CARD32 pad3 B32;
+CARD32 pad4 B32;
+CARD32 pad5 B32;
+CARD32 pad6 B32;
+} xXFixesQueryPointerReply;
+
+#define sz_xXFixesQueryPointerReply 32
+
+typedef struct {
+CARD8 reqType;
+CARD8 xfixesReqType;
+CARD16 length B16;
+Window window B32;
+} xXFixesQueryAncestorsReq;
+
+#define sz_xXFixesQueryAncestorsReq sizeof(xXFixesQueryAncestorsReq)
+
+typedef struct {
+BYTEtype; /* X_Reply */
+BYTEpad1;
+CARD16 sequenceNumber B16;
+CARD32 length B32;
+CARD32 numWindows B32;
+CARD32 pad3 B32;
+CARD32 pad4 B32;
+CARD32 pad5 B32;
+CARD32 pad6 B32;
+CARD32 pad7 B32;
+} xXFixesQueryAncestorsReply;
+
+#define sz_xXFixesQueryAncestorsReply 32
+
#undef Region
#undef
Re: [RFC] Multitouch support, step one
On Mon, Mar 15, 2010 at 08:15:14AM -0400, Michael Poole wrote: Peter Hutterer writes: [snip] Details: The data we get from the (Linux) kernel includes essentially all the ABS_MT events, x, y, w, h, etc. We can pack this data into valuators on the device. In the simplest case, a device with two touchpoints would thus send 4 valuators - the first two being the coordinate pair for the first touch point, the latter two the coordinates for the second touch point. Short comment: There will be more valuators; a max of 32 is not enough. I expect so too. Right now, MAX_VALUATORS is a simple #define that can be arbitrarily changed. Except that like so many defines we need to ensure that actually changing it doesn't cause regression in code that expects it to be exactly 36 (I just checked again, it's actually 36, not 32) The only hard limit I can think of is 256 which is what the XI1 protocol limits it to. Cheers, Peter Long version: I think this undersells the number of valuators that MT devices will provide. I am only really familiar with Apple's Magic Mouse, but I understand Apple's other MT devices report similar data (except for not having actual, touch-independent X/Y/button data). The Magic Mouse has hardware touch tracking, and reports the orientation, semi-major axis length, semi-minor axis length, touch area and a state or event bitmask for each touch. The tracking ID will probably be the most useful for applications, followed by touch area (the mouse can report a touch before physical contact occurs). I am not sure how gesture recognition would use the ellipse data, but I am pretty sure that some applications will want them. The interpretation of the state/event bitmask is currently unclear, so it could be reasonably omitted. With the standard X/Y valuators and buttons as a base, and a likely desire to emulate vertical and horizontal scroll wheels outside the application, the Magic Mouse needs ~5 + 7*N valuators for N touches -- with a 32 valuator limit, it will only be able to pass some of the hardware fields to applications. So, as a non-X developer, I would like that limit to go up. Barring that, I would like some notional plan on what the long-term solution will look like if the short-term solution involves truncated event reports. Michael Poole ___ 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 evdev] When labeling a device as touchpad, only check for LMR buttons.
Touchpads that have physical buttons have either LMR or BTN_TOOL_FINGER.
Other buttons in the range evdev recognises shouldn't be taken into account
here - they skew the detection towards touchpads and away from touchscreens.
Fedora Bug 571639
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/evdev.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index 3051462..b532639 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1767,6 +1767,7 @@ static int
EvdevProbe(InputInfoPtr pInfo)
{
int i, has_rel_axes, has_abs_axes, has_keys, num_buttons, has_scroll;
+int has_lmr; /* left middle right */
int kernel24 = 0;
int ignore_abs = 0, ignore_rel = 0;
EvdevPtr pEvdev = pInfo-private;
@@ -1809,6 +1810,7 @@ EvdevProbe(InputInfoPtr pInfo)
has_abs_axes = FALSE;
has_keys = FALSE;
has_scroll = FALSE;
+has_lmr = FALSE;
num_buttons = 0;
/* count all buttons */
@@ -1823,6 +1825,10 @@ EvdevProbe(InputInfoPtr pInfo)
}
}
+has_lmr = TestBit(BTN_LEFT, pEvdev-key_bitmask) ||
+TestBit(BTN_MIDDLE, pEvdev-key_bitmask) ||
+TestBit(BTN_RIGHT, pEvdev-key_bitmask);
+
if (num_buttons)
{
pEvdev-flags |= EVDEV_BUTTON_EVENTS;
@@ -1895,7 +1901,7 @@ EvdevProbe(InputInfoPtr pInfo)
}
} else if (TestBit(ABS_PRESSURE, pEvdev-abs_bitmask) ||
TestBit(BTN_TOUCH, pEvdev-key_bitmask)) {
-if (num_buttons || TestBit(BTN_TOOL_FINGER,
pEvdev-key_bitmask)) {
+if (has_lmr || TestBit(BTN_TOOL_FINGER, pEvdev-key_bitmask)) {
xf86Msg(X_INFO, %s: Found absolute touchpad.\n,
pInfo-name);
pEvdev-flags |= EVDEV_TOUCHPAD;
memset(pEvdev-old_vals, -1, sizeof(int) *
pEvdev-num_vals);
--
1.6.6.1
___
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: [RFC] Multitouch support, step one
On Mon, Mar 15, 2010 at 03:41:24PM +0100, Henrik Rydberg wrote: Preamble: Multi-touch as defined in this proposal is limited to single input-point multi-touch. This is suitable for indirect touch devices (e.g. touchpads) and partially suited for direct touch devices provided a touch is equivalent to a single-gesture single-application input. User-space applications need tools to *use* MT devices, not route raw data from the devices to the application. The latter is not much more complicated than opening a file, and everyone can do that already. Thus, unless there is a model for how MT devices work and interact with other MT devices, I see little point in having an X protocol at all. The main reason is that applications, for better or worse, use X as their input source. Our job is to get the data to the right client, without too much processing going on. For clients to go around the server by opening the kernel device files directly will cause issues in the long run, especially when you have multiple applications running. And you're right, what we would be doing here is essentially opening a file and forwarding the data as-is to a client where it can then be processed. Interpretation of the data needs to happen in the client, that goes for gestures as well as simple things like doubleclicks. I think I wasn't clear enough in the original email so I'll try to spell it out in more detail here: Assume a device that provides the following info by the kernel. BTN_LEFT BTN_RIGHT BTN_MIDDLE ABS_RX ABS_TILT_X ABS_TILT_Y ABS_MT_POSITION_X ABS_MT_POSITION_Y ABS_MT_TRACKING_ID ABS_MT_ORIENTATION The evdev driver would then set up a device based on this info. Assuming that we go with a default MT max range of 3, the device in X would look like this (using abbreviated xinput --list format). Multitouch deviceid=6[slave pointer (2)] Reporting 14 classes: Class originated from: 6 Buttons supported: 3 Button labels: Button Left Button Middle Button Right Button state: Class originated from: 6 Detail for Valuator 0: Label: Abs X Range: 0 - 1000 Resolution: 1 units/m Mode: relative Class originated from: 6 Detail for Valuator 1: Label: Abs Y Range: 0 - 1000 Resolution: 1 units/m Mode: relative Class originated from: 6 Detail for Valuator 2: Label: Abs Rx ... Detail for Valuator 3: Label: Abs Tilt X ... Detail for Valuator 4: Label: Abs Tilt Y ... Detail for Valuator 5: Label: Abs MT Position X ... Detail for Valuator 6: Label: Abs MT Position Y ... Detail for Valuator 7: Label: Abs MT Orientation ... Detail for Valuator 8: Label: Abs MT Position X ... Detail for Valuator 9: Label: Abs MT Position Y ... Detail for Valuator 10: Label: Abs MT Orientation ... Detail for Valuator 11: Label: Abs MT Position X ... Detail for Valuator 12: Label: Abs MT Position Y ... Detail for Valuator 13: Label: Abs MT Orientation ... I used 3 as MT default to keep the email short :) First thing to notice here is that the tracking ID is missing. AIUI, this is to identify a touchpoint on the device for as long as it persists. Since we have distinct valuators, we can use the tracking ID more to identify where to push the data and we do not have the need of sending it to the client. Hence, a MT event from the kernel of the likes of (fake evtest output) Event: time 1268716779.969270, -- Report Sync Event: time 1268716780.214151, type 3 (Abs), code 53 (Abs MT Position X), value 1 Event: time 1268716780.214151, type 3 (Abs), code 54 (Abs MT Position Y), value 2 Event: time 1268716780.214151, type 3 (Abs), code 52 (Abs MT Orienation), value 3 Event: time 1268716780.214151, ---Report MT Sync - Event: time 1268716780.214151, type 3 (Abs), code 53 (Abs MT Position X), value 14 Event: time 1268716780.214151, type 3 (Abs), code 54 (Abs MT Position Y), value 15 Event: time 1268716780.214151, type 3 (Abs), code 52 (Abs MT Orienation), value 16 Event: time 1268716780.214151, ---Report MT Sync - Event:
Re: [RFC] Multitouch support, step one
On Mon, Mar 15, 2010 at 11:40:19AM -0700, Jeremy Huddleston wrote: On Mar 15, 2010, at 09:01, Simon Thum wrote: Henrik, if I'm anywhere near understanding this, then probably your're missing an important point. This is _step one_. Getting information to where you need it and giving it a basic structure, roughly. The things you're talking about are more suited as a step two: Making sense of the information. Along those lines, you're probably right, though I'd go even further. But ATM concensus is needed how to transport MT information in a suitable and forward-compatible manner. The sooner this is nailed down, the sooner more abstract concepts can be tackled. Cheers, Simon I agree that application developers want something higher level. The structure that Henrik describes will be more beneficial to application developers. The point now is to determine who actually provides that data. Do we want tracking and grouping to be handled by the Xserver and sent to the client as such, or do we want to send the raw data to the client and have a library interpret these data and provide the client with these pretty structures? I'd vouch for the client. At least at this point we do not have enough information from the devices to do grouping fo contacts - that is where I think the context-specific stuff comes in. It seems like the latter can make use of the already-existing XI2 protocol. If we try to do this all in the server and package it up for the user, will we be looking at yet another bump of XI? Can we do it in a way that will be compatible with XI2? As I said, there are no protocol changes needed for this, so we don't need an API bump. I'd like to leave the actual protocol changes and more complex features for the general multitouch case - if we ever figure out how to do it. I actually like the idea of using the valuators to send the data over the wire. Why not use the valuators to also send data like: valuator 0 = core X valuator 1 = core Y valuator 2 = multi-touch 0 tracking id valuator 3 = multi-touch 0 group id valuator 4 = multi-touch 0 x valuator 5 = multi-touch 0 y valuator 6 = multi-touch 0 pressure valuator 7 = multi-touch 1 tracking id valuator 8 = multi-touch 1 group id valuator 9 = multi-touch 1 x valuator 10 = multi-touch 1 y valuator 11 = multi-touch 1 pressure More complex data management could then be handled by a client-side library. This still does not solve the valuator limit of 32. How difficult will it be to eliminate that maximum and have no limit? in theory a simple sed will do. In practice, this is software we're talking about... 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
