* [9front] nusb/kb mouse handling
@ 2020-12-08 0:59 umbraticus
2020-12-08 8:44 ` umbraticus
0 siblings, 1 reply; 6+ messages in thread
From: umbraticus @ 2020-12-08 0:59 UTC (permalink / raw)
To: 9front
This patch is tidier than the last one I sent. It does three things:
1. Only update button state if a button event was actually received.
2. Send b = 8 through instead of treating like b = 2.
3. Fix some typos.
umbraticus
diff -r 7a249c0196e5 sys/src/cmd/nusb/kb/kb.c
--- a/sys/src/cmd/nusb/kb/kb.c Mon Dec 07 18:59:54 2020 +0100
+++ b/sys/src/cmd/nusb/kb/kb.c Tue Dec 08 13:38:54 2020 +1300
@@ -637,7 +637,7 @@
s->h = v;
break;
- case 0x0D0051: /* Conteact identifier */
+ case 0x0D0051: /* Contact identifier */
s->id = v;
break;
@@ -684,7 +684,7 @@
{
char err[ERRMAX], mbuf[80];
uchar lastk[64], uk, dk;
- int i, c, nerrs, lastb, nlastk;
+ int i, c, nerrs, bpress, lastb, nlastk;
int abs, x, y, z, b;
Hidreport p;
Hidslot lasts[nelem(p.s)], *s, *l;
@@ -774,7 +774,7 @@
continue;
/* combine all the slots */
- abs = x = y = z = b = 0;
+ bpress = abs = x = y = z = b = 0;
for(i=0; i<p.ns; *l = *s, i++){
s = &p.s[i];
@@ -785,7 +785,7 @@
if(l == &lasts[nelem(lasts)-1] || !l->valid)
*l = *s;
- /* convet absolute z to relative */
+ /* convert absolute z to relative */
z += s->z;
if(s->abs & 4)
z -= l->z;
@@ -803,11 +803,8 @@
}
/* map to mouse buttons */
- b |= s->b & 1;
- if(s->b & (4|8))
- b |= 2;
- if(s->b & 2)
- b |= 4;
+ bpress |= s->m;
+ b |= s->b & ~6 | (s->b & 2) << 1 | (s->b & 4) >> 1;
/* X/Y are absolute? */
if((s->abs & 3) == 3){
@@ -829,6 +826,7 @@
if(z != 0)
b |= z > 0 ? 8 : 16;
+ if(!bpress) b = lastb;
if(abs || x != 0 || y != 0 || z != 0 || b != lastb){
lastb = b;
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9front] nusb/kb mouse handling
2020-12-08 0:59 [9front] nusb/kb mouse handling umbraticus
@ 2020-12-08 8:44 ` umbraticus
2020-12-08 11:37 ` umbraticus
0 siblings, 1 reply; 6+ messages in thread
From: umbraticus @ 2020-12-08 8:44 UTC (permalink / raw)
To: 9front
Sorry, a little tweak:
if(!bpress) b = lastb & 7;
Otherwise if I move the pointer too soon after the scroll wheel it
thinks the scroll button is still held down and turbo-scrolling™ gets
way out of control…
umbraticus
diff -r 7a249c0196e5 sys/src/cmd/nusb/kb/kb.c
--- a/sys/src/cmd/nusb/kb/kb.c Mon Dec 07 18:59:54 2020 +0100
+++ b/sys/src/cmd/nusb/kb/kb.c Tue Dec 08 21:21:03 2020 +1300
@@ -637,7 +637,7 @@
s->h = v;
break;
- case 0x0D0051: /* Conteact identifier */
+ case 0x0D0051: /* Contact identifier */
s->id = v;
break;
@@ -684,7 +684,7 @@
{
char err[ERRMAX], mbuf[80];
uchar lastk[64], uk, dk;
- int i, c, nerrs, lastb, nlastk;
+ int i, c, nerrs, bpress, lastb, nlastk;
int abs, x, y, z, b;
Hidreport p;
Hidslot lasts[nelem(p.s)], *s, *l;
@@ -774,7 +774,7 @@
continue;
/* combine all the slots */
- abs = x = y = z = b = 0;
+ bpress = abs = x = y = z = b = 0;
for(i=0; i<p.ns; *l = *s, i++){
s = &p.s[i];
@@ -785,7 +785,7 @@
if(l == &lasts[nelem(lasts)-1] || !l->valid)
*l = *s;
- /* convet absolute z to relative */
+ /* convert absolute z to relative */
z += s->z;
if(s->abs & 4)
z -= l->z;
@@ -803,11 +803,8 @@
}
/* map to mouse buttons */
- b |= s->b & 1;
- if(s->b & (4|8))
- b |= 2;
- if(s->b & 2)
- b |= 4;
+ bpress |= s->m;
+ b |= s->b & ~6 | (s->b & 2) << 1 | (s->b & 4) >> 1;
/* X/Y are absolute? */
if((s->abs & 3) == 3){
@@ -826,6 +823,7 @@
}
}
+ if(!bpress) b = lastb & 7;
if(z != 0)
b |= z > 0 ? 8 : 16;
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9front] nusb/kb mouse handling
2020-12-08 8:44 ` umbraticus
@ 2020-12-08 11:37 ` umbraticus
2020-12-08 13:50 ` kvik
0 siblings, 1 reply; 6+ messages in thread
From: umbraticus @ 2020-12-08 11:37 UTC (permalink / raw)
To: 9front
Thanks to sigrid, who committed the part of the patch that fixes my
trackball. We decided to leave the button mapping for the time being.
Currently, if a USB mouse has more than three buttons, b4 acts as
another b2 and anything above that is ignored. I had suggested
instead just sending through b4 and higher as is. This results in b4
and b5 acting as alternatives for the scroll wheel; perhaps a nice
side effect for some mice:
b |= s->b & ~6 | (s->b & 2) << 1 | (s->b & 4) >> 1;
Or perhaps extra buttons should be exposed in case anyone wants to
make use of them but not overlap with scroll wheel:
b |= s->b & 1 | (s->b & 2) << 1 | (s->b & 4) >> 1 | (s->b & ~7) << 2;
The current behaviour was introduced with revison 3acb9fdd26cc
nusb/kb: map button 4 to middle button 2 (for logitech 5 button mouse)
so I assume someone wanted it. What about b5 though? Perhaps this
should be mapped to b3 for some kind of consistency?
/* map to mouse buttons */
b |= s->b & 1;
if(s->b & (4|8))
b |= 2;
- if(s->b & 2)
+ if(s->b & (2|16))
b |= 4;
What do others think should happen to buttons >3?
umbraticus
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9front] nusb/kb mouse handling
2020-12-08 11:37 ` umbraticus
@ 2020-12-08 13:50 ` kvik
2020-12-08 21:18 ` umbraticus
0 siblings, 1 reply; 6+ messages in thread
From: kvik @ 2020-12-08 13:50 UTC (permalink / raw)
To: 9front
Quoth umbraticus@prosimetrum.com:
> What do others think should happen to buttons >3?
For my use I mapped higher buttons to bits 0x20 and up.
I then interpose a filter [1] between nusb/kb and /dev/mousein
that maps these according to what makes sense for a particular
device.
Such a filter could be made more versatile and powerful.
The issue with this approach is having to setup the filtering
in nusbrc, in particular outside and before most of the useful
namespaces even exist. This makes it harder to do fun stuff
with all the new buttons...
[1]: https://git.sr.ht/~kvik/mousetrap
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9front] nusb/kb mouse handling
2020-12-08 13:50 ` kvik
@ 2020-12-08 21:18 ` umbraticus
2020-12-09 0:14 ` kvik
0 siblings, 1 reply; 6+ messages in thread
From: umbraticus @ 2020-12-08 21:18 UTC (permalink / raw)
To: 9front
> https://git.sr.ht/~kvik/mousetrap
Nice. So you'd be in favour of b4 starting at 32, skipping over the
scrollwheel's 8/16. The owner of the "logitech 5 button mouse" could
follow your lead if he still wants b4 mapped to b2, or we could extend
the buttonmap functionality described in mouse(3) ...
umbraticus
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9front] nusb/kb mouse handling
2020-12-08 21:18 ` umbraticus
@ 2020-12-09 0:14 ` kvik
0 siblings, 0 replies; 6+ messages in thread
From: kvik @ 2020-12-09 0:14 UTC (permalink / raw)
To: 9front
Quoth umbraticus@prosimetrum.com:
> Nice. So you'd be in favour of b4 starting at 32, skipping over the
> scrollwheel's 8/16. The owner of the "logitech 5 button mouse" could
> follow your lead if he still wants b4 mapped to b2, or we could extend
> the buttonmap functionality described in mouse(3) ...
The way I see this, the driver should report unmapped input events and
let the rest of the input system decide what they mean.
The problem with mapping in mouse(3) is with it applying to all devices,
making it useless for dealing with per-device oddities.
I don't have a big idea on how to handle the general input issue.
Mousetrap works to make my Huge usable but I'm not convinced that it's
the way things oughta be.
The main problem is nothing in Plan 9 knows how to deal with these extra
input events. If I'm remembering correctly we'r even filtering out
anything above 0x10 in mouse(3) or rio.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-12-09 0:16 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-08 0:59 [9front] nusb/kb mouse handling umbraticus
2020-12-08 8:44 ` umbraticus
2020-12-08 11:37 ` umbraticus
2020-12-08 13:50 ` kvik
2020-12-08 21:18 ` umbraticus
2020-12-09 0:14 ` kvik
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).