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
>
>