Re: preparing multitouch support - request for tests
On Wed, Dec 16, 2015 at 12:59:00PM -0500, Ted Unangst wrote: > Tati Chevron wrote: > > But I don't see that touch-based devices are ever going to become the most > > common devices to run OpenBSD, that's not realistic. Even ignoring servers > > and headless devices, and only counting devices that are used interactively > > in some way, I just don't see tablet devices becoming the most widely used. > > Progress is not made by people saying they don't like progress. > +1 what Ted said here.
Re: preparing multitouch support - request for tests
On Wed, Dec 16, 2015 at 04:11:21PM +, Tati Chevron wrote: > > The touchscreen interfaces I have to use, principally on mobile phones, > are cumbersome and irritate me no end. Multitouch support is not only about touchscreens. There are also modern touchpads (and not only the Apple one) which recognise multi-touch events can be used to generate gestures like pinch, zoom, swipe... Those are useful with many applications. OTOH, I agree that Pure touchscreen interfaces need more work to be useable, even under Linux. -- Matthieu Herrb signature.asc Description: PGP signature
Re: preparing multitouch support - request for tests
On Wed, Dec 16, 2015 at 02:47:10PM -0500, Ted Unangst wrote: Tati Chevron wrote: On Wed, Dec 16, 2015 at 11:13:36AM -0700, Theo de Raadt wrote: >Your emails only contain opinions. "Questions, comments, suggestions and any kind of help would also be welcome". Sorry if I mis-understood the purpose of a mailing list. Your suggestions aren't helpful. Quoting the mailling list rules isn't making them more helpful. I was quoting Ulf's original post! -- Tati Chevron Perl and FORTRAN specialist. SWABSIT development and migration department. http://www.swabsit.com
Re: preparing multitouch support - request for tests
On Wed, Dec 16, 2015 at 02:32:44AM +0100, Ulf Brosziewski wrote: > Ping? No further thoughts on this, no tests? Do I have to conclude that > most people are happy with wsmouse as it is? Yes and no. As I told you earlier, I think your diffs contain some very good work and are required for further improvements and progress. The question is how to get them integrated. Further isolated work is probably the wrong way. You should try to get things (in small pieces) into the tree, though likely to late in current cycle. > I'm aware that the diff isn't small, but anything smaller would make > some of the remaining parts void and possibly blur the concept. It depends, for example you can commit the new file additions separately without hooking them, giving people a chance to view and play with them in tree. > ... > > There is a second point concerning compat mode that I would like to > change: it could be made useful. Because of the arbitrary scaling and > the unpredictable pointer movement, I cannot use it with wsmoused at the > console. Do touchpads exist where it works? Recently Thierry Deval > posted a diff here which proved that we could easily do something about > that, but that is a different story. In my diff, wsmouseinput hooks its > "touchpad extension" (wstpad) into the compat-mode conversion function, > which works well with ws for all touchpads that are available to me. I tend to agree that this is probably the right direction.
Re: preparing multitouch support - request for tests
On Wed, Dec 16, 2015 at 06:29:23PM +0100, Stefan Sperling wrote: On Wed, Dec 16, 2015 at 05:10:45PM +, Tati Chevron wrote: why does it have to be integrated into the same mouse driver that everybody else uses? Since you seem to care about this topic enough to actually contend with what Ulf has been working on for months, let's phrase it this way: Ulf's mails have diffs attached, and yours don't. Easy choice. I don't see the connection. I don't agree with the idea, nor see any real-world use or benefit to this change. Response of any kind on the list has been very limited too. Even Ulf has commented that maybe people are happy with things the way they are. What diffs would you expect to see from anyone who wanted no change? I've had several input layer diffs in my own personal tree for over four years that were rejected by Miod as not having a general use case. No problem. I maintain them, because I use them. If you and Ulf have a use for these changes, but nobody else is interested enough to even test and comment, why are you so worried? As much as we'd like to keep things stable, we need to make progress, too. But it has to be progress in a useful direction, surely? And why can't this all be done in a separate driver that doesn't touch wsmouse? And of course the community is not going to accept diffs (from anyone) which cause major regressions. So I don't see why you're so worried. To me, the extra and unnecessary code running on every machine that just has a PS/2 mouse, is a regression. If we did this with everything, we'd be Linux. The good thing about OpenBSD for me is that it supports a few things very well, rather than trying to support every possible use case regardless of it's state of readiness or if it has a real value. -- Tati Chevron Perl and FORTRAN specialist. SWABSIT development and migration department. http://www.swabsit.com
Re: preparing multitouch support - request for tests
On Wed, Dec 16, 2015 at 12:59:00PM -0500, Ted Unangst wrote: Tati Chevron wrote: But I don't see that touch-based devices are ever going to become the most common devices to run OpenBSD, that's not realistic. Even ignoring servers and headless devices, and only counting devices that are used interactively in some way, I just don't see tablet devices becoming the most widely used. Progress is not made by people saying they don't like progress. I'm all for progress, but I don't see any being made, here, or in the world of touch devices in general. -- Tati Chevron Perl and FORTRAN specialist. SWABSIT development and migration department. http://www.swabsit.com
Re: preparing multitouch support - request for tests
> >Ulf's mails have diffs attached, and yours don't. Easy choice. > > I don't see the connection. I definately see a connection. Your emails only contain opinions.
Re: preparing multitouch support - request for tests
On Wed, Dec 16, 2015 at 11:13:36AM -0700, Theo de Raadt wrote: Your emails only contain opinions. "Questions, comments, suggestions and any kind of help would also be welcome". Sorry if I mis-understood the purpose of a mailing list. -- Tati Chevron Perl and FORTRAN specialist. SWABSIT development and migration department. http://www.swabsit.com
Re: preparing multitouch support - request for tests
Tati Chevron wrote: > But I don't see that touch-based devices are ever going to become the most > common devices to run OpenBSD, that's not realistic. Even ignoring servers > and headless devices, and only counting devices that are used interactively > in some way, I just don't see tablet devices becoming the most widely used. Progress is not made by people saying they don't like progress.
Re: preparing multitouch support - request for tests
> >Tati Chevron wrote: > >> But I don't see that touch-based devices are ever going to become the most > >> common devices to run OpenBSD, that's not realistic. Even ignoring > >> servers and headless devices, and only counting devices that are used > >> interactively in some way, I just don't see tablet devices becoming the > >> most widely used. > > > >Progress is not made by people saying they don't like progress. > > I'm all for progress, but I don't see any being made, here, or in the > world of touch devices in general. words words words words Are you done?
Re: preparing multitouch support - request for tests
On 12/16/2015 03:11 PM, Matthieu Herrb wrote: On Wed, Dec 16, 2015 at 02:32:44AM +0100, Ulf Brosziewski wrote: Ping? No further thoughts on this, no tests? Do I have to conclude that most people are happy with wsmouse as it is? Hi, I'd like to see things move forward, but I currently lack time to do anything serious on this. One thing is not clear to me after looking (quickly) at your patch and trying it: how does this work integrate with the libinput port ? I hope it keeps various options open. Something like the wsmouseinput part, which tracks input states and produces events, is necessary anyway, would you agree with that? Quite generally, there might be three strategies for porting libinput: 1) We could try to make a port with a minimal change of the libinput sources. I'm afraid this would require making our input framework "libinput-compatible" and trying to rebuild at least a half of evdev. 2) We could try to separate the "reusable" parts of the libinput code and replace the rest with new developments. I don't know what the ratio would be, and whether the advantages would outweigh the difficulties. 3) We provide a "thin" libinput layer that supports its API and is backed by extended kernel functionality. This might be the most flexible solution. Various mixtures of 3) and 2) will also be possible. Some work on a port that aims at 3) has already been done, and the "touchpad extension" in my diff (wstpad) could support such a solution. With or without wstpad, it will be necessary to extend the event system, and probably not only with a zoo of new (MT) type codes. The wsmouse_configure() function and the struct wsmousehw might be a base for handling extended informations about the devices. Perhaps it isn't well-structured, and it will change in the future; but both the basic MT suppport as well as wstpad already needed more than wsconsio provides. Using ws with touchpads isn't intended to be the end of the story in this form. An unchanged ws isn't ideal, e.g., with respect to things like acceleration and deceleration (I had to add a "deceleration" feature because least the default acceleration profiles don't work well with touchpads; but this means that similar and related operations are scattered between distinct layers). From what I understand from libinput, it moves a lot of the code that maps low-level events to higher-level X events (for multi-touch, but also for features like 2 fingers scrolling or side scrolling) from the kernel to libinput itself. With libinput, xf86-input-ws should be replaced by xf86-input-libinput and there is no need to hack on xf86-input-ws anymore. I've the impression that here you're adding this code to the kernel. Please correct me if I'm wrong. There is also the fact that I'm conviced that xinput (and libinput) needs more information about the individual input device than what is currently exposed through wsconsio. This is probably even more true for multi-touch devices, since they have such a large set of possible features.. I'm aware that the diff isn't small, but anything smaller would make some of the remaining parts void and possibly blur the concept. The core of the approach is actually quite simple: wsmouse_input() will be replaced by a set of functions for reporting state, and by wsmouse_input_sync(), which generates the wscons events (please note that it doesn't produce MT events yet; there are no userland drivers that could use them). Running mice, and tablets and touchpads that can only track a single contact wouldn't need much more. MT support needs some bits of configuration: the number of touches that might be tracked simultaneously, and the information whether a buffer for "MT tracking" is required. For use with the synaptics driver, MT input from touchpads must be converted into a single-touch representation, and this conversion is based on a mechanism that selects a "pointer-controlling" slot. The implementation generalizes the method currently applied by the Elantech-v4 packet handler in pms. Single-touch representations are also the base for handling "compat-mode" of touchpads in wsmouse. Currently, each hardware driver tracks absolute coordinates in its device data, and has a compat-mode branch in its packet handler that computes relative coordinates, applies a more or less arbitrary scaling to them, and calls wsmouse_input() with the "DELTA" flags. This is not only ugly, it would be even more ugly for touchpad drivers that use the new MT functions: It would still require a driver-internal representation of the input, a driver-internal selection of the pointer-controlling touch, etc. That's obviously nonsense, compat mode should be handled by wsmouse. However, it requires some configuration. There is a second point concerning compat mode that I would like to change: it could be made useful. Because of the arbitrary scaling and the unpredictable pointer movement, I cannot use it with wsmoused at the console. Do touchpads
Re: preparing multitouch support - request for tests
On Wed, Dec 16, 2015 at 12:55:03PM +, Tati Chevron wrote: > Sorry to be negative, but I just don't see the perceived value in this. You wouldn't want to use OpenBSD on a trouchscreen computer if you had one? Where windows can be moved or resized depending on how many fingers you use to touch them? I would. I already have a machine capable of this but even if I wrote a driver for its wacom touchsceen today I could not pass all possible input events to OpenBSD's input subsystem. Looking forward, such devices will probably become the norm in general purpose computing. So I believe this work is important. The only downside I see here is that Ulf has been working in too much isolation, and that it's proabably too late for the result of his work to go into the tree for the 5.9 release cycle. I hope it will go into the tree in one form or another during the 6.0 cycle. And I didn't take time for testing Ulf's changes yet either, to be honest. Not because I wouldn't want to, but because I've been too busy with other things.
Re: preparing multitouch support - request for tests
On Wed, Dec 16, 2015 at 02:32:44AM +0100, Ulf Brosziewski wrote: > Ping? No further thoughts on this, no tests? Do I have to conclude that > most people are happy with wsmouse as it is? Hi, I'd like to see things move forward, but I currently lack time to do anything serious on this. One thing is not clear to me after looking (quickly) at your patch and trying it: how does this work integrate with the libinput port ? From what I understand from libinput, it moves a lot of the code that maps low-level events to higher-level X events (for multi-touch, but also for features like 2 fingers scrolling or side scrolling) from the kernel to libinput itself. With libinput, xf86-input-ws should be replaced by xf86-input-libinput and there is no need to hack on xf86-input-ws anymore. I've the impression that here you're adding this code to the kernel. Please correct me if I'm wrong. There is also the fact that I'm conviced that xinput (and libinput) needs more information about the individual input device than what is currently exposed through wsconsio. This is probably even more true for multi-touch devices, since they have such a large set of possible features.. > > I'm aware that the diff isn't small, but anything smaller would make > some of the remaining parts void and possibly blur the concept. The core > of the approach is actually quite simple: wsmouse_input() will be > replaced by a set of functions for reporting state, and by > wsmouse_input_sync(), which generates the wscons events (please note > that it doesn't produce MT events yet; there are no userland drivers > that could use them). Running mice, and tablets and touchpads that can > only track a single contact wouldn't need much more. MT support needs > some bits of configuration: the number of touches that might be tracked > simultaneously, and the information whether a buffer for "MT tracking" > is required. > > For use with the synaptics driver, MT input from touchpads must be > converted into a single-touch representation, and this conversion is > based on a mechanism that selects a "pointer-controlling" slot. The > implementation generalizes the method currently applied by the > Elantech-v4 packet handler in pms. > > Single-touch representations are also the base for handling > "compat-mode" of touchpads in wsmouse. Currently, each hardware driver > tracks absolute coordinates in its device data, and has a compat-mode > branch in its packet handler that computes relative coordinates, applies > a more or less arbitrary scaling to them, and calls wsmouse_input() with > the "DELTA" flags. This is not only ugly, it would be even more ugly for > touchpad drivers that use the new MT functions: It would still require a > driver-internal representation of the input, a driver-internal selection > of the pointer-controlling touch, etc. That's obviously nonsense, compat > mode should be handled by wsmouse. However, it requires some > configuration. > > There is a second point concerning compat mode that I would like to > change: it could be made useful. Because of the arbitrary scaling and > the unpredictable pointer movement, I cannot use it with wsmoused at the > console. Do touchpads exist where it works? Recently Thierry Deval > posted a diff here which proved that we could easily do something about > that, but that is a different story. In my diff, wsmouseinput hooks its > "touchpad extension" (wstpad) into the compat-mode conversion function, > which works well with ws for all touchpads that are available to me. > > The internal configuration of wstpad may cause headaches, it seems to be > easy to make a mess out if it. This is one of the reasons why there are > no ioctl mechanisms yet for a configuration from userland. > > Up to now, I had less headaches with the input-processing parts of > wstpad, and I don't believe that a decent driver necessarily looks like > the synaptics driver, or the touchpad module of libinput. Its tapping > handler, for example, seems to be built on a somewhat unlucky > abstraction (I mean the "state machine", where states mirror input > states and sequences of input states; in wstpad, the "states" of the > handler correspond the kind of decision that is to be taken next). Of > course I don't want to suggest that this is children's play; e.g., I > haven't worked seriously on the palm detection part up to now (I cannot > do that, because I don't have "real" problems with accidental touches). > Many things that may sound trivial first may turn out to be intricate > (e.g., how do you distinguish a two-finger click from a click-and-drag > action? This might need a timeout. Perhaps Mac users can help here ...) > > > On 12/03/2015 12:20 AM, Ulf Brosziewski wrote: > >The diffs below contain a complete and extensive rewrite of the > >input-processing parts of wsmouse and the interface it provides to > >the hardware drivers. It prepares the support for various kinds of > >multitouch input, as well as an
Re: preparing multitouch support - request for tests
On Wed, Dec 16, 2015 at 04:11:21PM +, Tati Chevron wrote: > >So I believe this work is important. > > I think it's much more important to look at the impact on existing use cases, > before making changes and introducing a lot of new code that the end user > can't easily disable, and potentially affects such basic things as a mouse. Your use case is as much important to me as it is to you. I also prefer keyboards for development and will still be using mice and touchpads. I'd like to run OpenBSD on a tablet to *use a tablet*. And I don't want to use a tablet running an OS I don't trust.
Re: preparing multitouch support - request for tests
Ping? No further thoughts on this, no tests? Do I have to conclude that most people are happy with wsmouse as it is? I'm aware that the diff isn't small, but anything smaller would make some of the remaining parts void and possibly blur the concept. The core of the approach is actually quite simple: wsmouse_input() will be replaced by a set of functions for reporting state, and by wsmouse_input_sync(), which generates the wscons events (please note that it doesn't produce MT events yet; there are no userland drivers that could use them). Running mice, and tablets and touchpads that can only track a single contact wouldn't need much more. MT support needs some bits of configuration: the number of touches that might be tracked simultaneously, and the information whether a buffer for "MT tracking" is required. For use with the synaptics driver, MT input from touchpads must be converted into a single-touch representation, and this conversion is based on a mechanism that selects a "pointer-controlling" slot. The implementation generalizes the method currently applied by the Elantech-v4 packet handler in pms. Single-touch representations are also the base for handling "compat-mode" of touchpads in wsmouse. Currently, each hardware driver tracks absolute coordinates in its device data, and has a compat-mode branch in its packet handler that computes relative coordinates, applies a more or less arbitrary scaling to them, and calls wsmouse_input() with the "DELTA" flags. This is not only ugly, it would be even more ugly for touchpad drivers that use the new MT functions: It would still require a driver-internal representation of the input, a driver-internal selection of the pointer-controlling touch, etc. That's obviously nonsense, compat mode should be handled by wsmouse. However, it requires some configuration. There is a second point concerning compat mode that I would like to change: it could be made useful. Because of the arbitrary scaling and the unpredictable pointer movement, I cannot use it with wsmoused at the console. Do touchpads exist where it works? Recently Thierry Deval posted a diff here which proved that we could easily do something about that, but that is a different story. In my diff, wsmouseinput hooks its "touchpad extension" (wstpad) into the compat-mode conversion function, which works well with ws for all touchpads that are available to me. The internal configuration of wstpad may cause headaches, it seems to be easy to make a mess out if it. This is one of the reasons why there are no ioctl mechanisms yet for a configuration from userland. Up to now, I had less headaches with the input-processing parts of wstpad, and I don't believe that a decent driver necessarily looks like the synaptics driver, or the touchpad module of libinput. Its tapping handler, for example, seems to be built on a somewhat unlucky abstraction (I mean the "state machine", where states mirror input states and sequences of input states; in wstpad, the "states" of the handler correspond the kind of decision that is to be taken next). Of course I don't want to suggest that this is children's play; e.g., I haven't worked seriously on the palm detection part up to now (I cannot do that, because I don't have "real" problems with accidental touches). Many things that may sound trivial first may turn out to be intricate (e.g., how do you distinguish a two-finger click from a click-and-drag action? This might need a timeout. Perhaps Mac users can help here ...) On 12/03/2015 12:20 AM, Ulf Brosziewski wrote: The diffs below contain a complete and extensive rewrite of the input-processing parts of wsmouse and the interface it provides to the hardware drivers. It prepares the support for various kinds of multitouch input, as well as an extended support for touchpads by wsmouse. Tests for regression with all kinds of "pointing devices" would be welcome. Only a small set of touchpads and USB mice is available to me, which is a somewhat uncomfortable situation when you are working on things like this. Please note that the first diff is for the synaptics driver in xenocara, the rest is for the kernel. Patching that driver will be necessary if you test with touchpads (and compiling it requires the modified version of wsconsio.h in /usr/include/dev/wscons/). In most drivers I have made only short and trivial changes, the Elantech-v4 part of pms is the only one that makes full use of the new MT functions. Unlike the basic input layer, which I hope is already fairly stable, the in-kernel touchpad support is in a more experimental stage. If you have a Synaptics, ALPS, or Elantech-v4 touchpad, you could test it by adding this xorg.conf to /etc: Section "InputClass" Identifier "wstpad" Driver "ws" MatchIsTouchPad "true" EndSection Only a default configuration will be available with this. It enables two-finger-scrolling and a lower soft-button area for clickpads, and two-finger- or edge-scrolling for
Re: preparing multitouch support - request for tests
On Thu, Dec 03, 2015 at 12:20:15AM +0100, Ulf Brosziewski wrote: > The diffs below contain a complete and extensive rewrite of the > input-processing parts of wsmouse and the interface it provides to > the hardware drivers. It prepares the support for various kinds of > multitouch input, as well as an extended support for touchpads by > wsmouse. > Hi, it looks like the diff got some white space mangled somewhere on the path to my mailbox. Would you have a version available somewhere with a more reliable transport than email ? Thank you. -- Matthieu Herrb pgpD4R376sQfx.pgp Description: PGP signature
Re: preparing multitouch support - request for tests
Hi, here are the diffs again, as tgz archive (it's the version I posted last week, which doesn't include the latest bug fix: hilms is incomplete in that version and won't work with tablets, only with mice). On 12/07/15 15:59, Matthieu Herrb wrote: On Thu, Dec 03, 2015 at 12:20:15AM +0100, Ulf Brosziewski wrote: The diffs below contain a complete and extensive rewrite of the input-processing parts of wsmouse and the interface it provides to the hardware drivers. It prepares the support for various kinds of multitouch input, as well as an extended support for touchpads by wsmouse. Hi, it looks like the diff got some white space mangled somewhere on the path to my mailbox. Would you have a version available somewhere with a more reliable transport than email ? Thank you. wsmouseinput.tgz Description: Binary data
preparing multitouch support - request for tests
The diffs below contain a complete and extensive rewrite of the
input-processing parts of wsmouse and the interface it provides to
the hardware drivers. It prepares the support for various kinds of
multitouch input, as well as an extended support for touchpads by
wsmouse.
Tests for regression with all kinds of "pointing devices" would be
welcome. Only a small set of touchpads and USB mice is available to
me, which is a somewhat uncomfortable situation when you are working
on things like this.
Please note that the first diff is for the synaptics driver in
xenocara, the rest is for the kernel. Patching that driver will be
necessary if you test with touchpads (and compiling it requires
the modified version of wsconsio.h in /usr/include/dev/wscons/).
In most drivers I have made only short and trivial changes, the
Elantech-v4 part of pms is the only one that makes full use of the
new MT functions.
Unlike the basic input layer, which I hope is already fairly stable,
the in-kernel touchpad support is in a more experimental stage. If
you have a Synaptics, ALPS, or Elantech-v4 touchpad, you could test
it by adding this xorg.conf to /etc:
Section "InputClass"
Identifier "wstpad"
Driver "ws"
MatchIsTouchPad "true"
EndSection
Only a default configuration will be available with this. It enables
two-finger-scrolling and a lower soft-button area for clickpads, and
two-finger- or edge-scrolling for touchpads (support for tapping and
upper soft-button areas is implemented, but it won't be enabled by
the automatic configuration). If this works, it would also be
interesting for me to know whether the defaults for pointer speed
and acceleration are decent.
Of course I'm not only interested in tests. Questions, comments,
suggestions, and any kind of help would also be welcome.
Index: src/wsconscomm.c
===
RCS file: /cvs/xenocara/driver/xf86-input-synaptics/src/wsconscomm.c,v
retrieving revision 1.13
diff -u -p -r1.13 wsconscomm.c
--- src/wsconscomm.c29 Aug 2015 08:48:28 - 1.13
+++ src/wsconscomm.c1 Dec 2015 22:40:15 -
@@ -215,45 +215,29 @@ WSConsReadHwState(InputInfoPtr pInfo,
hw->y = priv->maxy - event->value + priv->miny;
hw->cumulative_dy = hw->y;
break;
-case WSCONS_EVENT_MOUSE_ABSOLUTE_Z:
+case WSCONS_EVENT_TOUCH_PRESSURE:
hw->z = event->value;
break;
-case WSCONS_EVENT_MOUSE_ABSOLUTE_W:
-if (priv->model == MODEL_ELANTECH) {
-/* Elantech touchpads report number of fingers directly. */
-hw->fingerWidth = 5;
-hw->numFingers = event->value;
-break;
-}
-/* XXX magic number mapping which is mirrored in pms driver */
-switch (event->value) {
-case 0:
-hw->fingerWidth = 5;
-hw->numFingers = 2;
-break;
-case 1:
+case WSCONS_EVENT_TOUCH_FINGERS:
+hw->numFingers = event->value;
+if (hw->numFingers == 0)
+hw->fingerWidth = 0;
+else if (hw->fingerWidth == 0)
hw->fingerWidth = 5;
-hw->numFingers = 3;
-break;
-case 4 ... 5:
-hw->fingerWidth = event->value;
-hw->numFingers = 1;
-break;
-}
+break;
+case WSCONS_EVENT_TOUCH_WIDTH:
+hw->fingerWidth = event->value;
+break;
+case WSCONS_EVENT_TOUCH_UPDATE:
+/*
+ * The finger count or the active MT-slot has changed.
+ * Suppress pointer motion and two-finger scrolling.
+ */
+priv->count_packet_finger = 0;
+priv->vert_scroll_twofinger_on = FALSE;
+priv->horiz_scroll_twofinger_on = FALSE;
break;
case WSCONS_EVENT_SYNC:
-if (hw->z == 0) {
-hw->fingerWidth = 0;
-hw->numFingers = 0;
-} else if (hw->numFingers == 0) {
-/*
- * Because W may be 0 already, a two-finger touch on a
- * Synaptics touchpad doesn't necessarily produce an update
- * event for W.
- */
-hw->fingerWidth = 5;
-hw->numFingers = 2;
-}
hw->millis = 1000 * event->time.tv_sec +
event->time.tv_nsec / 100;
SynapticsCopyHwState(hwRet, hw);
Index: arch/i386/isa/lms.c
===
RCS file: /cvs/src/sys/arch/i386/isa/lms.c,v
retrieving revision 1.20
diff -u -p -r1.20 lms.c
--- arch/i386/isa/lms.c 10 Apr 2007 22:37:17 - 1.20
+++ arch/i386/isa/lms.c 1 Dec 2015 22:17:41 -
@@ -36,6 +36,7 @@
#include
#include
+#include
#define
