Re: let's get reference to state key back

[Alexandr Nedvedicky]

Hello,

sorry I have not test patch, which I've sent earlier.
I boot unpatched kernel...

this is the fix one need. updated patch is further below.

8<---8<-8<

diff -r 00f90fca186c src/sys/net/pf.c
--- a/src/sys/net/pf.c  Fri Mar 25 09:29:43 2016 +0100
+++ b/src/sys/net/pf.c  Fri Mar 25 21:06:11 2016 +0100
@@ -6566,7 +6566,8 @@
 * IP tunnels.
 */
KASSERT(pd.m->m_pkthdr.pf.statekey == NULL);
-   pd.m->m_pkthdr.pf.statekey = s->key[PF_SK_STACK];
+   pd.m->m_pkthdr.pf.statekey =
+   pf_state_key_ref(s->key[PF_SK_STACK]);
}
if (pd.dir == PF_OUT &&
pd.m->m_pkthdr.pf.inp && !pd.m->m_pkthdr.pf.inp->inp_pf_sk &&

8<---8<-8<


sorry for inconveniences.

regards
sasha


8<---8<-8<

Index: src/sys/kern/uipc_mbuf.c
===
RCS file: /cvs/src/sys/kern/uipc_mbuf.c,v
retrieving revision 1.220
diff -u -p -r1.220 uipc_mbuf.c
--- src/sys/kern/uipc_mbuf.c22 Mar 2016 06:17:00 -  1.220
+++ src/sys/kern/uipc_mbuf.c26 Mar 2016 00:12:07 -
@@ -72,6 +72,8 @@
  * Research Laboratory (NRL).
  */
 
+#include "pf.h"
+
 #include 
 #include 
 #include 
@@ -93,6 +95,10 @@
 #include 
 #endif
 
+#if NPF > 0
+#include 
+#endif /* NPF > 0 */
+
 struct mbstat mbstat;  /* mbuf stats */
 struct mutex mbstatmtx = MUTEX_INITIALIZER(IPL_NET);
 struct pool mbpool;/* mbuf pool */
@@ -261,6 +267,10 @@ m_resethdr(struct mbuf *m)
/* delete all mbuf tags to reset the state */
m_tag_delete_chain(m);
 
+#if NPF > 0
+   pf_pkt_unlink_state_key(m);
+#endif /* NPF > 0 */
+
/* like m_inithdr(), but keep any associated data and mbufs */
memset(>m_pkthdr, 0, sizeof(m->m_pkthdr));
m->m_pkthdr.pf.prio = IFQ_DEFPRIO;
@@ -350,8 +360,12 @@ m_free(struct mbuf *m)
if (n)
n->m_flags |= M_ZEROIZE;
}
-   if (m->m_flags & M_PKTHDR)
+   if (m->m_flags & M_PKTHDR) {
m_tag_delete_chain(m);
+#if NPF > 0
+   pf_pkt_unlink_state_key(m);
+#endif /* NPF > 0 */
+   }
if (m->m_flags & M_EXT)
m_extfree(m);
 
@@ -1201,6 +1215,10 @@ m_dup_pkthdr(struct mbuf *to, struct mbu
to->m_flags = (to->m_flags & (M_EXT | M_EXTWR));
to->m_flags |= (from->m_flags & M_COPYFLAGS);
to->m_pkthdr = from->m_pkthdr;
+
+#if NPF > 0
+   pf_pkt_state_key_ref(to);
+#endif /* NPF > 0 */
 
SLIST_INIT(>m_pkthdr.ph_tags);
 
Index: src/sys/net/if_pfsync.c
===
RCS file: /cvs/src/sys/net/if_pfsync.c,v
retrieving revision 1.227
diff -u -p -r1.227 if_pfsync.c
--- src/sys/net/if_pfsync.c 31 Jan 2016 00:18:07 -  1.227
+++ src/sys/net/if_pfsync.c 26 Mar 2016 00:12:08 -
@@ -523,6 +523,7 @@ pfsync_state_import(struct pfsync_state 
skw->port[0] = sp->key[PF_SK_WIRE].port[0];
skw->port[1] = sp->key[PF_SK_WIRE].port[1];
skw->rdomain = ntohs(sp->key[PF_SK_WIRE].rdomain);
+   PF_REF_INIT(skw->refcnt);
skw->proto = sp->proto;
if (!(skw->af = sp->key[PF_SK_WIRE].af))
skw->af = sp->af;
@@ -532,6 +533,7 @@ pfsync_state_import(struct pfsync_state 
sks->port[0] = sp->key[PF_SK_STACK].port[0];
sks->port[1] = sp->key[PF_SK_STACK].port[1];
sks->rdomain = ntohs(sp->key[PF_SK_STACK].rdomain);
+   PF_REF_INIT(sks->refcnt);
if (!(sks->af = sp->key[PF_SK_STACK].af))
sks->af = sp->af;
if (sks->af != skw->af) {
Index: src/sys/net/pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.966
diff -u -p -r1.966 pf.c
--- src/sys/net/pf.c4 Mar 2016 22:38:23 -   1.966
+++ src/sys/net/pf.c26 Mar 2016 00:12:09 -
@@ -231,6 +231,11 @@ int pf_step_out_of_anchor(int *, 
stru
 voidpf_counters_inc(int, struct pf_pdesc *,
struct pf_state *, struct pf_rule *,
struct pf_rule *);
+voidpf_state_key_link(struct pf_state_key *,
+   struct pf_state_key *);
+voidpf_inpcb_unlink_state_key(struct inpcb *);
+voidpf_state_key_unlink_reverse(struct pf_state_key *);
+
 #if NPFLOG > 0
 voidpf_log_matches(struct pf_pdesc *, struct pf_rule *,
struct pf_rule *, struct pf_ruleset *,
@@ -732,6 +737,7 @@ void
 pf_state_key_detach(struct pf_state *s, int idx)
 {
struct pf_state_item*si;
+   struct pf_state_key *sk;
 
if (s->key[idx] == NULL)
   

Re: www.openbsd.org/cgi-bin/man.cgi

[Miod Vallat]

> maybe we could provide MaaS (man as a service, copyright eric@)
>
> if user issues `man` and the man page is not found locally, man
> would transparently ssh to gu...@man.openbsd.org ? 

Doesn't Canonical own a patent on this?

Re: mpsafe aesni

[Mark Kettenis]

> From: Mike Belopuhov 
> Date: Thu, 24 Mar 2016 21:33:25 +0100
> 
> On 24 March 2016 at 20:53, Mark Kettenis  wrote:
> > Diff below makes aesni crypto "mpsafe".  It adds a CRYPTOCAP_F_MPSAFE
> > flag that makes the crypto framework dispatch to an mpsafe taskq if it
> > is set.  In order to make the aesni_process() function that does the
> > actual crypto work mpsafe, it moves the code over to a per-session
> > working buffer.  This obviously increases the cost of setting up a
> > session a bit.  Directly invoked crypto operations remain locked.  My
> > main laptop seem to do ipsec fine with this, but I'm not sure if there
> > is an actual performance gain.  So it would probably be good if
> > somebody could benchmark this.
> >
> > Comments?
> 
> It should be fairly simple to use SRP for the session list so that you
> don't have to take the mutex in the aesni_process.  Other than that I
> think this should go in once tests are made and people a happy with
> the results.

Actually, I'm not sure that's possible.  I think aesni_newsession()
and aesni_freesession() can be called from interrupt context, or at
least are not supposed to sleep.  They would call
SRPL_INSERT_HEAD_LOCKED() and SRPL_REMOVE_LOCKED(), which can only be
called from process context.

> Another question I have is why are you using an IPL_HIGH mutex?

The crypto code may be called from any subsystem, so that is the only
safe choice.

Re: www.openbsd.org/cgi-bin/man.cgi

[Alexander Hall]

Am I the only one that didn't take the proposal seriously?

/Alexander 

On March 25, 2016 5:13:52 PM GMT+01:00, Theo de Raadt  
wrote:
>> > $ ssh gu...@man.openbsd.org
>> > 
>> > Welcome guest user to OpenBSD's online manual library.
>> > 
>> > The only command available is 'man'.
>> > 
>> > (For help; type 'man man[ENTER]'.)
>> > 
>> > $
>
>So Craig, you think someone should take this risk?

Re: www.openbsd.org/cgi-bin/man.cgi

[Theo de Raadt]

> Am I the only one that didn't take the proposal seriously?

Craig's bank hands out anonymous unix shell accounts so that people
can read various public documents rather than using a web browser; I
am guessing that is where this proposal comes from.

Re: www.openbsd.org/cgi-bin/man.cgi

[Theo de Raadt]

> > $ ssh gu...@man.openbsd.org
> > 
> > Welcome guest user to OpenBSD's online manual library.
> > 
> > The only command available is 'man'.
> > 
> > (For help; type 'man man[ENTER]'.)
> > 
> > $

So Craig, you think someone should take this risk?

Re: multitouch support again

[Ulf Brosziewski]

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 knows a better way to make progress
>>> in this area? I'm at a loss here. As far as I can see, I
>>> cannot offer a smaller diff; this one contains the minimum
>>> that technically makes sense. And as it just adds the basics,
>>> a lot of things remain that could and possibly should be done
>>> soon, 6.0 isn't far away here.
>>
>> I've been running the previous version of your diff without problem.
>> However, on my laptop (X2240) I can't figure out if the
>> touchpad is supposed to support multitouch or not.
>>
> 
> Same here: I've been running the three patches you sent gzipped on my
> Thinkpad T450 since you posted them and didn't notice any regression so
> far. It just works as I expect it to.
> 
Thanks. Verifying that the new input functions and the modified wsconscomm
don't break anything is more or less all that can be done with these
versions of my diffs. Synaptics touchpads are running in a mode that
doesn't need the MT functions. Only Elantech-v4 models make use of them
currently. ubcmtp and hidmt could apply it, but I haven't adapted the
drivers, it is a bit less trivial than replacing the wsmouse_input call.
If someone wants to do that, or could do the tests for me, please let me
know (up to now, the wsmouse_mtframe and wsmouse_id_to_slot functions have
only been tested with special versions of the elantech handler).

>> I wanted to do more tests (comparing with Linux for instance) but I've
>> lacked time so far.
>>
>> If you have some small test programs (or recipes based on xinput)
>> to suggest I'll try that.
> 
> Yes, it would be very helpful if you could give some good test cases and
> instructions what to look for.
> 
I don't have a very systematic way of testing touchpads. Usually I check
"gestures" that involve changes of the contact count or - possibly -
pointer-control, like two-finger scrolling (with two, one, or alternating
fingers moving), click-and-drag actions with two fingers on clickpads (again,
with alternating fingers moving), tapping, tap-and-drag, and tap-and-drag
with "locked drags".
>> Again, your work on this is much appreciated, even if it's true that
>> we've not provided feedback...
> 
> Seconded.
> 
> 
Thanks again.

Re: www.openbsd.org/cgi-bin/man.cgi

[Bob Beck]

Now now, we can be more hipster than that.. a docker image that runs
the man command for you after downloading
all the openbsd man pages as a dependency - you can just deploy it
automatically with vagrant and run it in AWS.. etc.

After all, isn't there no simple command that can't be made better by
installing an os image someone else built to run?




On Fri, Mar 25, 2016 at 8:45 AM, Ingo Schwarze  wrote:
> Hi Gilles,
>
> Gilles Chehade wrote on Fri, Mar 25, 2016 at 03:34:02PM +0100:
>
>> maybe we could provide MaaS (man as a service, copyright eric@)
>>
>> if user issues `man` and the man page is not found locally, man
>> would transparently ssh to gu...@man.openbsd.org ?
>
> Hilarious on so many levels...  :-D
>   Ingo
>

Re: www.openbsd.org/cgi-bin/man.cgi

[Ingo Schwarze]

Hi Gilles,

Gilles Chehade wrote on Fri, Mar 25, 2016 at 03:34:02PM +0100:

> maybe we could provide MaaS (man as a service, copyright eric@)
> 
> if user issues `man` and the man page is not found locally, man
> would transparently ssh to gu...@man.openbsd.org ? 

Hilarious on so many levels...  :-D
  Ingo

Re: www.openbsd.org/cgi-bin/man.cgi

[Gilles Chehade]

On Fri, Mar 25, 2016 at 03:20:05PM +0100, Ingo Schwarze wrote:
> Hi Craig,
> 
> Craig Skinner wrote on Wed, Mar 23, 2016 at 10:07:10AM +:
> > On 2016-03-22 Tue 22:49 PM |, Bob Beck wrote:
> 
> >> A few years back, Ingo moved it to the new mandoc based man.cgi, and
> >> now we've actually moved this to a dedicated place - "man.openbsd.org"
> 
> > Superb.
> > 
> > What's next?
> > 
> > $ ssh gu...@man.openbsd.org
> > 
> > Welcome guest user to OpenBSD's online manual library.
> > 
> > The only command available is 'man'.
> > 
> > (For help; type 'man man[ENTER]'.)
> > 
> > $
> 
> Sounds like a bad idea to me.  The man(1) utility spawns less(1),
> and less can spawn editors and shells.  So that is hard to secure.
> 
> Even if it could be secured, i don't like the idea of handing out
> SSH access to an OpenBSD web server to the general public.  A web
> server is always a fragile beast, and attack surface ought to be
> minimized.
> 
> Even if it could the secured and even if there weren't concerns
> about expanding attack surface, it doesn't look like it could be
> worth the effort.  I don't think there are many people out there
> expecting to find public information on the Internet on anonymous
> SSH servers rather than on WWW servers, so it's not likely the
> service would see much real-world use.
> 
> And even if there were a few people who would use it, i don't
> quite see how it would be better for them than what we already
> have.  I mean, http://man.openbsd.org/ works with text browsers
> on text-only terminals.
> 

maybe we could provide MaaS (man as a service, copyright eric@)

if user issues `man` and the man page is not found locally, man
would transparently ssh to gu...@man.openbsd.org ? 


-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

Re: www.openbsd.org/cgi-bin/man.cgi

[Ingo Schwarze]

Hi Craig,

Craig Skinner wrote on Wed, Mar 23, 2016 at 10:07:10AM +:
> On 2016-03-22 Tue 22:49 PM |, Bob Beck wrote:

>> A few years back, Ingo moved it to the new mandoc based man.cgi, and
>> now we've actually moved this to a dedicated place - "man.openbsd.org"

> Superb.
> 
> What's next?
> 
> $ ssh gu...@man.openbsd.org
> 
> Welcome guest user to OpenBSD's online manual library.
> 
> The only command available is 'man'.
> 
> (For help; type 'man man[ENTER]'.)
> 
> $

Sounds like a bad idea to me.  The man(1) utility spawns less(1),
and less can spawn editors and shells.  So that is hard to secure.

Even if it could be secured, i don't like the idea of handing out
SSH access to an OpenBSD web server to the general public.  A web
server is always a fragile beast, and attack surface ought to be
minimized.

Even if it could the secured and even if there weren't concerns
about expanding attack surface, it doesn't look like it could be
worth the effort.  I don't think there are many people out there
expecting to find public information on the Internet on anonymous
SSH servers rather than on WWW servers, so it's not likely the
service would see much real-world use.

And even if there were a few people who would use it, i don't
quite see how it would be better for them than what we already
have.  I mean, http://man.openbsd.org/ works with text browsers
on text-only terminals.

Yours,
  Ingo

let's get reference to state key back

[Alexandr Nedvedicky]

Hello,

this yet another patch, which got backed out in Jan. This time I'd like to
commit change, which makes sure IP stack keeps reference to state key along
the packet (mbuf).

The change should not cause panics, but I'd like to ask testers to watch
for memory leaks on state key pool (pfstkey):

while true ; do vmstat -m |egrep '^pf|^Name' ; sleep 5 ; done 

I could spot no memory leaks, but my test scenario is currently limited
to local traffic and simple router, which forwards packets.

thanks a lot
regards
sasha

8<---8<---8<--8<
Index: src/sys/kern/uipc_mbuf.c
===
RCS file: /cvs/src/sys/kern/uipc_mbuf.c,v
retrieving revision 1.220
diff -u -p -r1.220 uipc_mbuf.c
--- src/sys/kern/uipc_mbuf.c22 Mar 2016 06:17:00 -  1.220
+++ src/sys/kern/uipc_mbuf.c25 Mar 2016 12:49:38 -
@@ -72,6 +72,8 @@
  * Research Laboratory (NRL).
  */
 
+#include "pf.h"
+
 #include 
 #include 
 #include 
@@ -93,6 +95,10 @@
 #include 
 #endif
 
+#if NPF > 0
+#include 
+#endif /* NPF > 0 */
+
 struct mbstat mbstat;  /* mbuf stats */
 struct mutex mbstatmtx = MUTEX_INITIALIZER(IPL_NET);
 struct pool mbpool;/* mbuf pool */
@@ -261,6 +267,10 @@ m_resethdr(struct mbuf *m)
/* delete all mbuf tags to reset the state */
m_tag_delete_chain(m);
 
+#if NPF > 0
+   pf_pkt_unlink_state_key(m);
+#endif /* NPF > 0 */
+
/* like m_inithdr(), but keep any associated data and mbufs */
memset(>m_pkthdr, 0, sizeof(m->m_pkthdr));
m->m_pkthdr.pf.prio = IFQ_DEFPRIO;
@@ -350,8 +360,12 @@ m_free(struct mbuf *m)
if (n)
n->m_flags |= M_ZEROIZE;
}
-   if (m->m_flags & M_PKTHDR)
+   if (m->m_flags & M_PKTHDR) {
m_tag_delete_chain(m);
+#if NPF > 0
+   pf_pkt_unlink_state_key(m);
+#endif /* NPF > 0 */
+   }
if (m->m_flags & M_EXT)
m_extfree(m);
 
@@ -1201,6 +1215,10 @@ m_dup_pkthdr(struct mbuf *to, struct mbu
to->m_flags = (to->m_flags & (M_EXT | M_EXTWR));
to->m_flags |= (from->m_flags & M_COPYFLAGS);
to->m_pkthdr = from->m_pkthdr;
+
+#if NPF > 0
+   pf_pkt_state_key_ref(to);
+#endif /* NPF > 0 */
 
SLIST_INIT(>m_pkthdr.ph_tags);
 
Index: src/sys/net/if_pfsync.c
===
RCS file: /cvs/src/sys/net/if_pfsync.c,v
retrieving revision 1.227
diff -u -p -r1.227 if_pfsync.c
--- src/sys/net/if_pfsync.c 31 Jan 2016 00:18:07 -  1.227
+++ src/sys/net/if_pfsync.c 25 Mar 2016 12:49:41 -
@@ -523,6 +523,7 @@ pfsync_state_import(struct pfsync_state 
skw->port[0] = sp->key[PF_SK_WIRE].port[0];
skw->port[1] = sp->key[PF_SK_WIRE].port[1];
skw->rdomain = ntohs(sp->key[PF_SK_WIRE].rdomain);
+   PF_REF_INIT(skw->refcnt);
skw->proto = sp->proto;
if (!(skw->af = sp->key[PF_SK_WIRE].af))
skw->af = sp->af;
@@ -532,6 +533,7 @@ pfsync_state_import(struct pfsync_state 
sks->port[0] = sp->key[PF_SK_STACK].port[0];
sks->port[1] = sp->key[PF_SK_STACK].port[1];
sks->rdomain = ntohs(sp->key[PF_SK_STACK].rdomain);
+   PF_REF_INIT(sks->refcnt);
if (!(sks->af = sp->key[PF_SK_STACK].af))
sks->af = sp->af;
if (sks->af != skw->af) {
Index: src/sys/net/pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.966
diff -u -p -r1.966 pf.c
--- src/sys/net/pf.c4 Mar 2016 22:38:23 -   1.966
+++ src/sys/net/pf.c25 Mar 2016 12:49:49 -
@@ -231,6 +231,11 @@ int pf_step_out_of_anchor(int *, 
stru
 voidpf_counters_inc(int, struct pf_pdesc *,
struct pf_state *, struct pf_rule *,
struct pf_rule *);
+voidpf_state_key_link(struct pf_state_key *,
+   struct pf_state_key *);
+voidpf_inpcb_unlink_state_key(struct inpcb *);
+voidpf_state_key_unlink_reverse(struct pf_state_key *);
+
 #if NPFLOG > 0
 voidpf_log_matches(struct pf_pdesc *, struct pf_rule *,
struct pf_rule *, struct pf_ruleset *,
@@ -732,6 +737,7 @@ void
 pf_state_key_detach(struct pf_state *s, int idx)
 {
struct pf_state_item*si;
+   struct pf_state_key *sk;
 
if (s->key[idx] == NULL)
return;
@@ -745,15 +751,15 @@ pf_state_key_detach(struct pf_state *s, 
pool_put(_state_item_pl, si);
}
 
-   if (TAILQ_EMPTY(>key[idx]->states)) {
-   RB_REMOVE(pf_state_tree, _statetbl, s->key[idx]);
-   if (s->key[idx]->reverse)
-   

Re: multitouch support again

[Theo Buehler]

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 knows a better way to make progress
> > in this area? I'm at a loss here. As far as I can see, I
> > cannot offer a smaller diff; this one contains the minimum
> > that technically makes sense. And as it just adds the basics,
> > a lot of things remain that could and possibly should be done
> > soon, 6.0 isn't far away here.
> 
> I've been running the previous version of your diff without problem.
> However, on my laptop (X2240) I can't figure out if the
> touchpad is supposed to support multitouch or not.
> 

Same here: I've been running the three patches you sent gzipped on my
Thinkpad T450 since you posted them and didn't notice any regression so
far. It just works as I expect it to.

> I wanted to do more tests (comparing with Linux for instance) but I've
> lacked time so far.
> 
> If you have some small test programs (or recipes based on xinput)
> to suggest I'll try that.

Yes, it would be very helpful if you could give some good test cases and
instructions what to look for.

> Again, your work on this is much appreciated, even if it's true that
> we've not provided feedback...

Seconded.

Re: multitouch support again

[Matthieu Herrb]

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 knows a better way to make progress
> in this area? I'm at a loss here. As far as I can see, I
> cannot offer a smaller diff; this one contains the minimum
> that technically makes sense. And as it just adds the basics,
> a lot of things remain that could and possibly should be done
> soon, 6.0 isn't far away here.

I've been running the previous version of your diff without problem.
However, on my laptop (X2240) I can't figure out if the
touchpad is supposed to support multitouch or not.

I wanted to do more tests (comparing with Linux for instance) but I've
lacked time so far.

If you have some small test programs (or recipes based on xinput)
to suggest I'll try that.

Again, your work on this is much appreciated, even if it's true that
we've not provided feedback...

Thanks.
> 
> 
> 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 infrastructure
> >coexist in wsmouse, and only the touchpad drivers have been
> >changed to use the new one. Except for a stylistic detail
> >(s/timespeccpy/memcpy/), nothing else has changed, and the
> >descriptions I added last week apply to this version as
> >well (the synaptics diff, which needs the modified wsconsio.h,
> >is the first one here, the rest is for the kernel).
> >
> >Tests have been made with an Elantech-v4 touchpad, an ALPS
> >Glidepoint, and an old Synaptics touchpad. I couldn't test
> >the older Elantech models, more recent Synaptics models, or
> >models that run with hidmt or ubcmtp. (The December version
> >had more tests, but this isn't exactly the same code anymore.)
> >
> >
> >[...]

-- 
Matthieu Herrb


pgphKg4PvBKaG.pgp
Description: PGP signature

Re: multitouch support again

[Ulf Brosziewski]

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 -u -p -r1.13 wsconscomm.c
--- src/wsconscomm.c29 Aug 2015 08:48:28 -  1.13
+++ src/wsconscomm.c11 Mar 2016 20:46:30 -
@@ -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_CONTACTS:
+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_RESET:
+/*
+ * The contact 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: dev/hid/hidmt.c
===
RCS file: /cvs/src/sys/dev/hid/hidmt.c,v
retrieving revision 1.1
diff -u -p -r1.1 hidmt.c
--- dev/hid/hidmt.c 20 Jan 2016 01:26:00 -  1.1
+++ dev/hid/hidmt.c 20 Mar 2016 14:22:49 -
@@ -329,20 +329,15 @@ hidmt_input(struct hidmt *mt, uint8_t *d
width = 50;
}

-   wsmouse_input(mt->sc_wsmousedev, mt->sc_button,
+   WSMOUSE_TOUCH(mt->sc_wsmousedev, mt->sc_button,
(mt->last_x = mt->sc_contacts[i].x),
(mt->last_y = mt->sc_contacts[i].y),
-   width, tips,
-   WSMOUSE_INPUT_ABSOLUTE_X |
-   WSMOUSE_INPUT_ABSOLUTE_Y |
-   WSMOUSE_INPUT_ABSOLUTE_Z |
-   WSMOUSE_INPUT_ABSOLUTE_W);
+   width, tips);
} else {
-   wsmouse_input(mt->sc_wsmousedev, mt->sc_button,
+   WSMOUSE_INPUT(mt->sc_wsmousedev, mt->sc_button,
(mt->last_x - mt->sc_contacts[i].x),
(mt->last_y - mt->sc_contacts[i].y),
-   0, 0,
-   WSMOUSE_INPUT_DELTA);
+   0, 0);
mt->last_x = mt->sc_contacts[i].x;
mt->last_y = mt->sc_contacts[i].y;
}
Index: dev/pckbc/pms.c
===
RCS file: /cvs/src/sys/dev/pckbc/pms.c,v
retrieving revision 1.68
diff -u -p -r1.68 pms.c
--- dev/pckbc/pms.c 27 Feb 2016 22:01:58 -  1.68
+++ dev/pckbc/pms.c 20 Mar 2016 14:22:52 -
@@ -143,17 +143,8 @@ struct elantech_softc {

int min_x, min_y;
int max_x, max_y;
-   struct {
-   unsigned int x;
-   unsigned int y;
-   unsigned int z;
-   

Re: multitouch support again

[Martin Pieuchot]

On 24/03/16(Thu) 22:34, Ulf Brosziewski wrote:
> Are there any reviews, tests, OKs, or NOs pending? And if
> not, may I ask if someone knows a better way to make progress
> in this area? I'm at a loss here. As far as I can see, I
> cannot offer a smaller diff; this one contains the minimum
> that technically makes sense. And as it just adds the basics,
> a lot of things remain that could and possibly should be done
> soon, 6.0 isn't far away here.

I cannot apply your diff.