modified drawterm /kern/devmouse.c to allow buttonmap command

buttonmap xyz
or
buttonmap (reset to default)

whole file http://okturing.com/src/3732/body
patch http://okturing.com/src/3736/body

i dont know if apply because of SHIFT key modifier (default) that changes
mouse button 3 behavior to act like middle mouse 2 button.
anyway anon delivers, still if someone is interested.

second test. drawterm respects Windows mouse settings, if button is swapped
in OS.



2016-07-13 11:56 GMT+02:00 hiro <23hiro@gmail.com>:

> If I understand correctly this is how the mouse works:
>
>         case MotionNotify:
>                 me = (XMotionEvent *)e;
>                 s = me->state;
>                 ms.xy.x = me->x;
>                 ms.xy.y = me->y;
>                 ms.msec = me->time;
>                 break;
>
>
>
> On 7/13/16, stanley lieber <sl@stanleylieber.com> wrote:
> > Dave MacFarlane <driusan@gmail.com> wrote:
> >
> >>On Tue, Jul 12, 2016 at 8:22 PM, stanley lieber <sl@stanleylieber.com>
> >>wrote:
> >>> hiro <23hiro@gmail.com> wrote:
> >>>
> >>>>I was under the impression this is handled by your OS (Xorg for
> >>>>example), not inside drawterm.
> >>>
> >>> So, mousectl is simply not implemented?
> >>>
> >>> sl
> >>>
> >>
> >>What would it do? Change the settings on the OS of the machine that
> >>you're connecting
> >>from?
> >>
> >>- Dave
> >
> > No, why would anyone expect activity inside the drawterm session to
> change
> > the behavior of the host OS?
> >
> > The expected result would be to change the behavior of the mouse inside
> the
> > drawterm session, just as the mouse(3) bits that are currently
> implemented
> > facilitate the current behavior of the mouse inside the drawer term
> session.
> > If I understand correctly, all that is missing here is implementing those
> > bits (namely, ctl messages).
> >
> > Maybe I'm misunderstanding and this is impossible, but if so, how can the
> > mouse work at all? Drawterm already intercepts and interprets the mouse,
> > right?
> >
> > sl
> >
> >
>