nce filter in the configuration options.
However, if a default value is derived from the length of the touchpad
diagonal, it might be too high for over-sized touchpads. If that turns
out to be a problem, the proper place to fix it is the hardware driver.
OK?
On 2/21/23 20:10, Ulf Brosziewski wrote:
&
Sorry for being so late with my reply.
Checking SYNAPTICS_CAP_MULTIFINGER is not sufficient. There are Synaptics
touchpads that don't report this capability but do provide contact counts
(and that's not a rare case).
Adding a test for AGM support seems to be a viable workaround, see
I do not expect users to find that field, or play around with it
if they don't know what they do. It's "hidden" in wsconsctl for a
reason. And plainly, I had no time for the wsconsctl part.
On 2/23/23 17:25, joshua stein wrote:
> On Thu, 23 Feb 2023 at 17:05:53 +0100, Tobias Heider wrote:
>>
This diff is an extension of Tobias Heider's proposal, which aims at
providing "Apple-like" button inputs on clickpads. I have added some
things in order to approximate the behaviour of other input drivers.
It's a quick shot, and I have no idea whether it is sufficient in
practice, it certainly
n Tue, Feb 07, 2023 at 10:07:56PM +0100, Ulf Brosziewski wrote:
>> I wouldn't mind seeing such a feature in the driver, but I think there's more
>> to do than counting contacts. The start of a click-and-drag gesture may
>> involve
>> two contacts and a button-pre
://wayland.freedesktop.org/libinput/doc/1.22.0/clickpad-softbuttons.html
) as well as additional means for identifying "thumbs", but I'm not familiar
with the details.
On 2/7/23 14:12, Tobias Heider wrote:
> On Mon, Sep 19, 2022 at 11:16:51AM +0200, Ulf Brosziewski wrote:
>> Is there enough inter
Is there enough interest in this feature among OpenBSD users? I haven't
seen many requests for it, if any. Moreover, is it a good idea to configure
different input methods on this or that hardware just because another OS
has different defaults?
Just in case the answer to these questions turns
The diff below improves the way hidmt identifies clickpads, and
addresses the problems described in
https://marc.info/?l=openbsd-tech=165296530618617=2
and
https://marc.info/?l=openbsd-tech=165980534415586=2
If devices don't report a HUD_BUTTON_TYPE property, the driver checks
whether
Shouldn't the check of the button page remain in place, for identifying
plain old touchpads with external buttons? Looking for the "Pad Type"
feature (HUD_BUTTON_TYPE in hid.h) doesn't make much sense for these
devices because the feature report is optional:
"If the device has a non-button
On 5/3/22 10:03, Ulf Brosziewski wrote:
> The implementation of the tapping mechanism in wsmouse(4) has a bug
> concerning the transitions into the hold/drag state, see
> https://marc.info/...
> for details. The patch proposed in that message is obsolete. I've
>
... and this is the complete link:
https://marc.info/?l=openbsd-tech=165006255922269=2
On 5/3/22 10:03, Ulf Brosziewski wrote:
> The implementation of the tapping mechanism in wsmouse(4) has a bug
> concerning the transitions into the hold/drag state, see
> https://
The implementation of the tapping mechanism in wsmouse(4) has a bug
concerning the transitions into the hold/drag state, see
https://marc.info/...
for details. The patch proposed in that message is obsolete. I've
been made aware that there is another problem, the transition only
works with
The touchpad input driver of wsmouse(4) uses a flawed shortcut for
handling double taps, which has the effect that tap-and-drag inputs with
multiple taps before the final contact almost never work correctly when
the number of the taps is even:
On 3/23/21 10:39 PM, Klemens Nanni wrote:
> On Tue, Mar 23, 2021 at 09:29:09PM +0100, Ulf Brosziewski wrote:
>> In order to distinguish tap gestures from short movements, the touchpad
>> input driver in wsmouse checks whether the distance between the initial
>> and the las
On 3/23/21 8:31 PM, Klemens Nanni wrote:
> On Tue, Mar 23, 2021 at 05:52:10PM +0100, Ulf Brosziewski wrote:
>> Thanks for the report. The logging shows that the contacts are recognized,
>> so we have indeed to look at the filters of the driver. Two filters are
>> rele
In order to distinguish tap gestures from short movements, the touchpad
input driver in wsmouse checks whether the distance between the initial
and the last position of a touch exceeds the 'maxdist' limit. Some
touchpads provide unreliable coordinates when more than one contact is
being made
/23/21 12:26 PM, Klemens Nanni wrote:
> On Tue, Mar 23, 2021 at 02:00:43AM +0100, Ulf Brosziewski wrote:
>> On 3/22/21 10:19 PM, Klemens Nanni wrote:
>>> On Mon, Mar 22, 2021 at 08:18:45PM +0100, Klemens Nanni wrote:
>>>> I was too stupid to look at `wsconsctl' output (wh
On 3/22/21 10:19 PM, Klemens Nanni wrote:
> On Mon, Mar 22, 2021 at 08:18:45PM +0100, Klemens Nanni wrote:
>> I was too stupid to look at `wsconsctl' output (which needs root) and
>> only looked here.
>>
>> Mailing the diff for my lack of better wording, plus the knob atually
>> takes three values
wsmouse(4) doesn't free the memory allocated for the wstpad state
when an external touchpad is being unplugged. This patch fixes
the leak.
OK?
Index: wsmouse.c
===
RCS file: /cvs/src/sys/dev/wscons/wsmouse.c,v
retrieving revision
wsconsctl treats it as an error if a wsmouse device reports a touchpad
type in the WSMOUSEIO_GTYPE call but doesn't provide touchpad configuration
data. With revision 1.3 of ims.c, committed in January, ims devices show
this behaviour.
This patch splits the GETPARAMS call into two parts. If
Thanks for the good work!
I think this can and should go in,
OK?
On 2/28/21 11:03 PM, RJ Johnson wrote:
> I recently posted a patch which allowed enabling/disabling touchpad tap
> gestures [1]. After a lot of back and forth with bru@, I am now ready
> to submit an updated version.
>
> This
Hi,
I wouldn't mind to see such a feature in wsmouse, but there are two things
that I don't like about the patch in this form: 1) It breaks existing
configurations, and 2) it may bother the users who don't care about such an
extension - probably the majority of those who enable tapping.
A better
to not merge this patch if you don't want it; I will not be
> offended. As long as I have things working how I like on my own system :)
>
> On 10/14/20 5:16 PM, Ulf Brosziewski wrote:
>> I'm not convinced that this makes sense. While there are still a lot of
>> touchpads ar
I'm not convinced that this makes sense. While there are still a lot of
touchpads around that need deceleration, modern ones tend to be larger and
more precise, so maybe we want to drop it at some point in the future?
Given that up to now, nobody else reported a problem with it, I'd prefer
to
This patch addresses a bug in certain Elantech-V1 touchpads, which report
invalid position data at the start of single-finger touches.
The patch is derived from this proposal
https://marc.info/?l=openbsd-tech=159957752322249=2
This version also removes two bits of obsolete code. wsmouse
meouts when attempts are
made to enable or disable pms).
On 9/13/20 13:14, Ulf Brosziewski wrote:
> Not all PS/2-like controllers accept the AUXECHO command, and the test that
> pckbc applies in order to check for the presence of the auxiliary interface
> may yield false negatives, even on ne
Not all PS/2-like controllers accept the AUXECHO command, and the test that
pckbc applies in order to check for the presence of the auxiliary interface
may yield false negatives, even on newer hardware (see
https://marc.info/?l=openbsd-misc=158413132831425=2
).
This patch adds an alternative
Hi John,
you can slow down mice via wsconsctl, but this possibility is "hidden"
in a debug and testing interface.
You have seen the WSMOUSECFG_D*_SCALE parameters, two parameters in
*.12 fixed-point format that determine the scaling of DX- and DY-deltas.
You can read the values with
$
This patch makes two changes in the way pms(4) handles Synaptics touchpads.
It addresses problems that lead to this bug report:
https://marc.info/?l=openbsd-bugs=158278943515495=2
Tests for regressions and OKs would be welcome.
1) The patched version doesn't enable the so-called "extended
This patch adds a device configuration flag to pms. It disables the
protocol lookup - which leaves touchpads in mouse emulation mode and
may be useful for diagnostic purposes and as a workaround for
protocol errors.
OK?
Index: dev/pckbc/pms.c
With the introduction of precision scrolling, it is no longer possible to
reverse scroll directions for touchpads by means of button mappings in X.
This patch adds a configuration option to wsmouse and a boolean field
named
wsmouse*.reverse_scrolling
to wsconsctl. The option is valid for
With this patch, pms recognizes all elantech-v4 touchpads (see
https://marc.info/?l=openbsd-tech=156554256223597=2 ). Some
models may have external hardware buttons, they are identified by
checking a flag in the firmware version number.
OK?
Index: dev/pckbc/pms.c
Hi Alexander,
thanks for these hints and the diff. I think if we add those
ic types, pms should also identify the models with hardware
buttons properly (not all v4 models are clickpads). This looks
like a trivial extension, I will propose a patch soon.
On 8/11/19 6:55 PM, Alexander Cronheim
This is an updated version of the diff for precision scrolling. It
fixes a bug of the first one (which didn't check the synchronization
state properly), and it improves the filtering (when a scroll gesture
stops and the fingers remain on the touchpad, the first version
could too easily generate
Hi Joshua,
could you make a test with the updated diff below and check whether
the scroll speed is normal? (There are no changes in ws, it's just
the kernel part).
On 3/16/19 4:16 PM, joshua stein wrote:
> On Thu, 14 Mar 2019 at 00:48:33 +0100, Ulf Brosziewski wrote:
>> Much too fast?
On 3/13/19 4:49 PM, Martin Pieuchot wrote:
> On 13/03/19(Wed) 00:41, Ulf Brosziewski wrote:
>> The standard method of scrolling in X is tailored to mouse wheels and
>> proceeds in coarse steps. Wheel events are mapped to button events, and on
>> receiving such an event,
On 3/13/19 5:27 PM, joshua stein wrote:
> On Wed, 13 Mar 2019 at 00:41:12 +0100, Ulf Brosziewski wrote:
>> The standard method of scrolling in X is tailored to mouse wheels and
>> proceeds in coarse steps. Wheel events are mapped to button events, and on
>> receiving such an
The standard method of scrolling in X is tailored to mouse wheels and
proceeds in coarse steps. Wheel events are mapped to button events, and on
receiving such an event, an application moves the view of its data by some
fixed distance - usually the height of a line of text, or of a couple of
On 3/5/19 7:40 PM, Ted Unangst wrote:
> Ulf Brosziewski wrote:
>> BTW, reverting the scroll direction is also possible by configuring
>> a "ZAxisMapping" in ws(4), with an xorg.conf like this one:
>>
>> Section "InputClass"
>> Identifier &
Adding these options - switching the scroll direction and a
customizable button map for tapping - to wsmouse and wstpad would
not be a big deal. If there is interest, I could prepare a patch.
I doubt, however, that both should be included in the named and
visible wsmouse options of wsconsctl.
My last patch to wstpad has solved some problems by introducing two new
ones: The identification of thumb contacts in the bottom area of a
touchpad may be too slow, and too strict under certain circumstances.
This patch extends the test for stable movement. Touches moving at a
medium or high
This patch removes a loose end in the filter mechanisms of wstpad; it's
related to the one that was fixed a few weeks ago.
In order to determine whether a touch is moving stably, the driver counts
how often its position updates match, roughly, the same direction. The
method works as intended,
For a while now, wsmouse activates compatibility mode for touchpads by
default. There have been no complaints about wobbling pointers or
unstable pointer paths. I conclude that the default filtering is
sufficient and that the type of touchpad which could profit from the
"strong" variant of the
The touchpad input driver includes a function that identifies "stable"
movements. It is very simple, but seems to work sufficiently well with
most kinds of inputs. There is an exception: some touchpads regularly
report intermediate zero coordinate-deltas when a touch is moving very
slowly. The
Hi Joshua,
this patch breaks ubcmtp on the MacBook Pro 8.2. There is no problem
with the padding, but the pressure value is always 0, and wsmouse
doesn't register any touches. I believe only type4 models fill the
'pressure' field. At least for now, it's better to use the width
value
ok bru@ (but please see my comments on the second diff)
On 07/27/2018 09:59 PM, joshua stein wrote:
> Back when touchpad drivers were using the synaptics Xorg driver,
> they had to pretend to be Elantech devices in order to get
> particular packet processing.
>
> Since Ulf switched us to
Hi,
I have the vague impression that the feature isn't popular here, but
it makes sense if you are using a trackpoint, or a three-button mouse
without a wheel. According to the libinput documentation, it is enabled
by default for trackpoints. However, at first sight I'd think that such
a
This patch adds support for Elantech trackpoints to pms. They can be
treated like other secondary devices and require only minor extensions
in the initialization and input functions.
For now, the patch also extends the set of "IC types" that are accepted
for V4-touchpads from (6,8) to (6,8,15).
Looks fine to me. I made some tests on a T420, with explicitly
triggered resets, and the detection and the "reset task" worked
as expected. There are noticeable delays, but I don't think
optimizing would be worth the effort (if it happens too often,
you may want to repair or exchange your
This patch adapts the Elantech handlers in pms to the new touchpad
infrastructure of wsmouse. The changes concern models that use the older
protocol versions 1, 2, and 3. You don't find that hardware at the next
corner nowadays, so if you have a laptop with one of those models, your
help would
This patch adds the wsmouse_configure call to iatp. I haven't
seen it running, so it would be nice if someone could confirm that
the change doesn't introduce regressions, and check whether it
works with both synaptics(4) and ws(4).
Index: iatp.c
This patch adapts hidmt - which is used by imt(4) - to the multitouch
interface of wsmouse, and it adds the compat-mode configuration required
by the wsmouse-internal touchpad input driver.
Tests with both the synaptics driver and the internal driver would be
appreciated (see
This patch adds a query for the lower coordinate limits to the Synaptics
part of pms. Up to now, the driver always uses the "typical bezel
limits" as given in the "Synaptics PS/2 Interfacing Guide". These limits
are indeed typical and often work well, but they aren't exact and you
cannot control
This patch for ubcmtp makes it use the multitouch-input functions of
wsmouse. It's the first driver that would apply the "tracking" variant
(wsmouse_mtframe).
No wonders will result from the change, but the two-finger gestures that
involve movement - scrolling and click-and-drag with two fingers
While preparing and testing some changes in ubcmtp I found a bug in
wsconscomm that may affect two-finger touches on "noisy" MT devices, that
is, on devices that constantly report small deltas of the touch positions
even if there is no noticeable movement.
Whenever the contact count or the
Maybe one day I'll get it right:
s/wsmouse_input_sync()/wsmouse_input_sync(ms->sc_wsmousedev)/
On 09/07/2016 12:12 AM, Ulf Brosziewski wrote:
> Hi, I was a bit hasty, I should have mentioned that calling
> wsmouse_input_sync is required here. The equivalent of your
> code
Just a remark on your use of the wsmouse interface (which isn't well
known and documented yet): wsmouse_set is a function for uncommon
cases. To report a pair of absolute coordinates use wsmouse_position,
that is, instead of
wsmouse_set(ms->sc_wsmousedev, WSMOUSE_ABS_X, x, 0);
Ping?
On 07/14/2016 12:11 AM, Ulf Brosziewski wrote:
> Sorry for the repetition, it seems that single-touch state
> needs the same treatment as MT state when wsmouse is being
> reopened. Single-touch state "synchronizes" itself immediately
> when the first changes oc
Sorry for the repetition, it seems that single-touch state
needs the same treatment as MT state when wsmouse is being
reopened. Single-touch state "synchronizes" itself immediately
when the first changes occur, but it may happen that the first
touch after a restart with dirty state won't trigger
It seems that if an MT device is disabled and reenabled,
remnants of the previous MT state can lead to problems.
wsmouse_mt_init should always reset that state completely
(thanks to jcs@ for help).
OK?
Index: dev/wscons/wsmouse.c
The diff below adds a little improvement to the wsmouse_matching
function, which is the core of the MT tracking mechanism in wsmouse.
Sadly, that mechanism isn't in use up to now, but this also means
that OKs are riskless ;-)
With small matrices - roughly, of orders up to 300 or 400 - and most
The input functions of wsmouse have changed completely,
this also concerns ums/hidms. All tests are - and will
be - welcome ;-)
On 06/06/2016 11:31 PM, Edd Barrett wrote:
> On Mon, Jun 06, 2016 at 01:53:01PM +0200, Stefan Sperling wrote:
>> On Mon, Jun 06, 2016 at 12:40:24PM +0100, Edd Barrett
30 Mar 2016 23:34:12 - 1.29
+++ dev/wscons/wsmouse.c5 Jun 2016 21:44:58 -
@@ -72,6 +72,22 @@
*/
/*
+ * Copyright (c) 2015, 2016 Ulf Brosziewski
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted
Again, I think the risk is small. A test with hilms would have
been nice, of course (unfortunately, I didn't succeed in contacting
Miod).
On 06/05/16 10:38, Stefan Sperling wrote:
> On Sun, Jun 05, 2016 at 09:55:07AM +0200, Ulf Brosziewski wrote:
>> ok?
>
> Again, I can't test th
The changes are simple, the functions are already in use and
no regressions are known; if nobody insists on tests, I will
commit that soon.
On 06/05/16 10:36, Stefan Sperling wrote:
> On Sun, Jun 05, 2016 at 09:54:55AM +0200, Ulf Brosziewski wrote:
>> ok?
>>
>
> Looks g
ok?
On 06/01/2016 01:23 AM, Ulf Brosziewski wrote:
> zts, hilms, and uts are the drivers that still use wsmouse_input
> with absolute coordinates (or with both types of coordinates).
> The new, "flag-less" interface of wsmouse requires calls of
> wsmouse_position, and, poss
ok?
On 06/01/2016 01:21 AM, Ulf Brosziewski wrote:
> These diffs adapt various drivers to the new input functions of
> wsmouse, namely
> arch/i386/isa/lms.c,
> arch/i386/isa/mms.c,
> arch/luna88k/dev/lunaws.c,
> arch/sgi/hpc/z8530ms.c,
> dev/adb/ams.c,
zts, hilms, and uts are the drivers that still use wsmouse_input
with absolute coordinates (or with both types of coordinates).
The new, "flag-less" interface of wsmouse requires calls of
wsmouse_position, and, possibly, of wsmouse_touch in this case.
Questions, tests and OKs would be welcome.
These diffs adapt various drivers to the new input functions of
wsmouse, namely
arch/i386/isa/lms.c,
arch/i386/isa/mms.c,
arch/luna88k/dev/lunaws.c,
arch/sgi/hpc/z8530ms.c,
dev/adb/ams.c,
dev/sun/sunms.c, and
dev/usb/utpms.c.
Each of the diffs just replaces
Ping? Wouldn't it be nice if wsmouse were more coherent again
in the next release?
On 05/14/2016 04:46 PM, Ulf Brosziewski wrote:
> The new input-processing functions of wsmouse seem to work well
> for touchpads, and it might be time to update the mouse drivers
> now. I start with the tw
The new input-processing functions of wsmouse seem to work well
for touchpads, and it might be time to update the mouse drivers
now. I start with the two drivers that I could test myself, hidms
(ums) and pms.
Please note that hidms can mix, in principle, absolute and relative
coordinates. The new
Ping?
It isn't a severe bug and it doesn't concern a spectacular feature,
but shouldn't we fix it?
On 04/16/2016 06:01 PM, Ulf Brosziewski wrote:
> The changes I have introduced in wsconscomm.c recently can make the
> transition from two-finger scrolling to coasting somewhat dif
The changes I have introduced in wsconscomm.c recently can make the
transition from two-finger scrolling to coasting somewhat difficult.
Provided that you have scrolled quickly enough, coasting will start
if you finish the scroll gesture by lifting both fingers simultaneously,
but a short delay
On 03/25/2016 01:53 PM, Theo Buehler wrote:
> On Fri, Mar 25, 2016 at 01:47:07PM +0100, Matthieu Herrb wrote:
>> On Thu, Mar 24, 2016 at 10:34:12PM +0100, Ulf Brosziewski wrote:
>>> Are there any reviews, tests, OKs, or NOs pending? And if
>>> not, may I ask if someone
Again, my mail client insisted on the "flowed" text format,
sorry. Here is a clean version of the diff.
Index: src/wsconscomm.c
===
RCS file: /cvs/xenocara/driver/xf86-input-synaptics/src/wsconscomm.c,v
retrieving revision 1.13
diff
,
a lot of things remain that could and possibly should be done
soon, 6.0 isn't far away here.
On 03/20/2016 06:18 PM, Ulf Brosziewski wrote:
I have been asked to prepare a less invasive version of
the MT diffs I posted a week ago. Here it is. It doesn't
delete wsmouse_input(). The old and the new
I have been asked to prepare a less invasive version of
the MT diffs I posted a week ago. Here it is. It doesn't
delete wsmouse_input(). The old and the new infrastructure
coexist in wsmouse, and only the touchpad drivers have been
changed to use the new one. Except for a stylistic detail
iff could be removed. If this is what you want,
I could prepare it, but it would take a few days.
On 03/17/2016 01:58 PM, Martin Pieuchot wrote:
On 13/03/16(Sun) 18:37, Ulf Brosziewski wrote:
The diffs below are a rewrite of the input-processing part of wsmouse. It
adds support for multitouch
There are whitespace errors in the diffs. In case anyone
wants to test them, please use the new versions in the
attachment.
On 03/13/2016 06:37 PM, Ulf Brosziewski wrote:
The diffs below are a rewrite of the input-processing part of wsmouse. It
adds support for multitouch input
This patch adapts the synaptics driver to the changes described in 1/3 and
2/3.
wsconsio.h defines alternative names for the ABSOLUTE_Z and ABSOLUTE_W
events, namely
WSCONS_EVENT_TOUCH_PRESSURE and
WSCONS_EVENT_TOUCH_CONTACTS,
and wsmouse uses the latter exclusively for the plain contact
These diffs adapt the drivers that attach to wsmouse to its new interface.
Most changes are fairly trivial and replace wsmouse_input calls with the
WSMOUSE_INPUT/WSMOUSE_TOUCH macros. However, some cases may need a second
thought. hidms, for example, now permits, at least in principle, to mix
.h
diff -N dev/wscons/wsmouseinput.h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ dev/wscons/wsmouseinput.h 12 Mar 2016 20:42:48 -
@@ -0,0 +1,173 @@
+/*
+ * Copyright (c) 2015, 2016 Ulf Brosziewski
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose wi
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
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
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
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
This looks nice. Maybe someone else who is more familiar with wsdisplay
could also have a look at it?
I made a test with a USB mouse and an ALPS Glidepoint, which worked
well. Without the patch wsmoused is completely useless for that
touchpad. Out of curiosity, I made another test with an
On 08/29/2015 01:13 PM, Alexandr Shadchin wrote:
On Fri, Aug 28, 2015 at 10:04:51PM +0200, Ulf Brosziewski wrote:
Some weeks ago a change was made in pms to support Synaptics touchpads
that don't provide W mode. I assume that only fairly old models are
concerned, and that the variant
Some weeks ago a change was made in pms to support Synaptics touchpads
that don't provide W mode. I assume that only fairly old models are
concerned, and that the variant in the patch below is more accurate. It
only fakes W values where necessary.
The patch contains a second change, a check
On 08/22/2015 12:35 PM, Martin Pieuchot wrote:
On 15/08/15(Sat) 01:32, Ulf Brosziewski wrote:
The tap-and-drag gesture doesn't work reliably with the ALPS touchpads
supported by pms. To make it work, it is necessary to start dragging
immediately with the second touch, which doesn't always
The tap-and-drag gesture doesn't work reliably with the ALPS touchpads
supported by pms. To make it work, it is necessary to start dragging
immediately with the second touch, which doesn't always succeed.
Increasing the tap timeout helps, but doesn't change the principle. The
patch below solves
On 04/02/2015 03:39 AM, Fasse wrote:
On Wed, 01 Apr 2015 21:23:15 +0200
Ulf Brosziewskiulf.brosziew...@t-online.de wrote:
Yes, without some refactoring there won't be an elegant way.
pms_sync_elantech_v2 encodes some sync state in the 'flags' field
(ELANTECH_F_2FINGER_PACKET), but doing the
On 04/01/2015 08:46 PM, Fasse wrote:
On Wed, 01 Apr 2015 20:05:46 +0200
Ulf Brosziewskiulf.brosziew...@t-online.de wrote:
Hi,
there might be a problem. The Linux driver for that touchpad type also
accepts debounce packets, which have the same format as for the
non-crc version. I have no idea
Hi,
there might be a problem. The Linux driver for that touchpad type also
accepts debounce packets, which have the same format as for the
non-crc version. I have no idea whether that is correct and if those
packets do occur in practice, but if they do they wouldn't pass this
version of sync()
On 02/28/2015 09:38 AM, Martin Pieuchot wrote:
[moved to tech@]
On 27/02/15(Fri) 11:40, patrick keshishian wrote:
Hi,
On 2/26/15, Ulf Brosziewskiulf.brosziew...@t-online.de wrote:
On 02/27/2015 03:31 AM, Ulf Brosziewski wrote:
...
It might be that the following patch to wsmouse.c solves
On 01/30/2015 11:04 AM, Ulf Brosziewski wrote:
On 01/30/2015 07:15 AM, Martin Pieuchot wrote:
On 30/01/15(Fri) 01:25, Ulf Brosziewski wrote:
Probably I was too sceptical about synaptics.c. The bug I observed
with the ALPS touchpad seems to be due to a kind of mismatch between
the ALPS code
On 01/30/2015 07:15 AM, Martin Pieuchot wrote:
On 30/01/15(Fri) 01:25, Ulf Brosziewski wrote:
Probably I was too sceptical about synaptics.c. The bug I observed
with the ALPS touchpad seems to be due to a kind of mismatch between
the ALPS code in pms and the event handling in wsconscomm
Probably I was too sceptical about synaptics.c. The bug I observed
with the ALPS touchpad seems to be due to a kind of mismatch between
the ALPS code in pms and the event handling in wsconscomm. The patch
below contains the initial change as well as what was necessary to
fix this.
diff --git
On 01/25/2015 04:07 PM, Alexandr Shadchin wrote:
On Wed, Jan 14, 2015 at 12:23:13AM +0100, Ulf Brosziewski wrote:
Currently pms and the wsconscomm module of the synaptics driver offer a
somewhat limited support for Elantech clickpads with hardware version 4.
Above all, I missed the options
On 01/14/2015 02:03 AM, Alexey Suslikov wrote:
Ulf Brosziewskiulf.brosziewskiat t-online.de writes:
I have written two patches that provide these options (I'm using them
on an Acer V5-131 netbook with OpenBSD 5.6/amd64, the clickpad hardware
and firmware is identified as Elantech Clickpad,
1 - 100 of 101 matches
Mail list logo
