Based on what I wrote yesterday as replies to other messages,
I have completely reworked the interface exposed by this
autorepeating thing.

Consider the following:

[dawn jmmv] $ sudo wsconsctl -m -a | grep scroll
emul.scroll.repeat=3Dtrue
emul.scroll.up=3D3
emul.scroll.down=3D4
emul.scroll.left=3D5
emul.scroll.right=3D6

As you can see, I've defined buttons 3, 4, 5 and 6 to be the scrolling
buttons for the four possible directions.  Then, I enabled this new
"repeating" feature by setting emul.scroll.repeat to true, which makes
all those buttons send events repeatedly while pressed.

The user no longer has to deal with delays; they are all hidden in
the kernel.  Also, some acceleration is applied to the frequency of
the generation of these repeating events, so if you hold down the
scrolling button, it will progressively scroll faster and faster (up to a
limit).

Note that, at the moment, there is no difference in assigning a button
to any of the {up,down,left,right} directions; they all behave the same.
However, this will be useful to have in case something like X's
"EmulateWheelButton" is implemented.  (Given that I just discovered
X has this feature in itself, I doubt I'll reimplement it in the driver...)

It's clear that this feature is not as flexible as the one I presented
yesterday.  In that one, the user could enable repeating for any
number of buttons and specifically give the repeating intervals.
However, the way it is now is much simpler to manage and understand,
and also is focused to a specific usage.  I'm not sure this scheme
makes much sense, though.

And what about the node names?  'emul.scroll' comes from the fact
that this new feature is specially useful to emulate scrolling on mice
that do not have a wheel.

Any comments?  If not I'll be commiting this soon (unless I came up
with a "better" idea, which may well be rolling back these changes to
yesterday's status ;-)

Thanks,


On 2/2/06, Julio M. Merino Vidal <jmmv84@gmail.com> wrote:
> Hi all,
>
> I recently got a trackball that has four buttons.  It has no wheel but
> two of the buttons are designed to simulate it (button 3 does a wheel
> down and button 4 does a wheel up).
>
> The mouse comes with special drivers for Windows and Mac OS that handle
> the scrolling.  If you leave either button 3 or 4 pressed, it
> automatically
> repeats the scrolling events, so what you have on screen effectively
> scrolls multiple times.  I find this very, very comfortable and useful
> (otherwise the buttons are mostly useless).
>
> Unfortunately, neither wsmouse nor X11 can simulate this feature.  Yet.
>
> I've patched wsmouse(4) to be able to simulate autorepeating for
> some buttons, similarly to what wskbd(4) has.  You can see the
> preliminary patch in:
>
>         ftp://ftp.NetBSD.org/pub/NetBSD/misc/jmmv/repeat.diff
>
> which I'd like to commit in the following days.
>
> Some things to discuss:
>
> - Should this functionality be optional?  (I hear 'of course'...
>    but it's not that big and machines that use mice shouldn't be
>    too tight on memory, or do they?)
>
> - The interface I added to wsconsctl(8) looks like the following:
>
>    $ wsconsctl -m -a
>    repeat.del1=3D"0 0 0 200 200 0 0 0 ..."
>    repeat.delN=3D"0 0 0 100 100 0 0 0 ..."
>
>    It tries to mimic the one for wskbd, but as there are multiple
>    buttons, they should be configurable independently (you surely
>    do not want button 0 to autorepeat).
>
>    Each integer in the variable represents a button.  Similarly,
>    the same interface is used to set the delays:
>
>    $ wsconsctl -m -w repeat.del1=3D"0 0 100"
>
>    This sets the delay for first repeat on button 2, disabling the
>    delay for button 0 and 1.
>
>    The kernel stores this in appropriate structures, not strings.
>
>    Any better idea?
>
>    Note that at the moment this looks bad because the kernel always
>    returns 32 buttons for the mouse.  (This is the 'TODO' I left in
>    wsmouse_attach).  Should be better when the kernel returns the
>    appropriate numbers (i.e., the integer list will be much shorter).
>
> - I'll work on fixing the  'TODO' and 'XXX' markers added to
>    wsmouse_attach after commiting this.  These should be easy to
>    do but are completely unrelated to the patch so I haven't done
>    them yet.
>
> Please comment.
>
> Thanks,
>
> --
> Julio M. Merino Vidal <jmmv84@gmail.com>
> The Julipedia - http://julipedia.blogspot.com/
>
>
>


--
Julio M. Merino Vidal <jmmv84@gmail.com>
The Julipedia - http://julipedia.blogspot.com/