REPORT_MOUSE_POSITION mask doesn't work

[markjolesen]

REPORT_MOUSE_POSITION mask does not work. I believe the problem is in pdcurses/getch.c line 134. It is not checking for the flag. See diff below. I tested DOS and x11 and it appears to fix the issue.

diff --git a/pdcurses/getch.c b/pdcurses/getch.c
index 44f7f80..1a9c677 100644
--- a/pdcurses/getch.c
+++ b/pdcurses/getch.c
@@ -131,7 +131,7 @@ static int _mouse_key(WINDOW *win)
 
     if (pdc_mouse_status.changes & PDC_MOUSE_MOVED)
     {
-        if (!(mbe & (BUTTON1_MOVED|BUTTON2_MOVED|BUTTON3_MOVED)))
+        if (!(mbe & (REPORT_MOUSE_POSITION|BUTTON1_MOVED|BUTTON2_MOVED|BUTTON3_MOVED)))
             pdc_mouse_status.changes ^= PDC_MOUSE_MOVED;
     }

[Bill-Gray]

Thank you. That looks quite reasonable. However, running 'testcurs -z', I'm still not getting mouse movement events in DOS or X11. The only place where they show up is in Win32a, where my patch of 2017 Feb 18 had already enabled them. I'll dig deeper; it's quite possibly a blunder on my end.

Just to make sure we're running similar tests: I'm testing by running 'testcurs -z', going to the 'Input Test', and moving the mouse over the area. In Win32a, this results in a stream of mouse movement messages. In DOS and X11, I only get mouse move messages if a mouse button is pressed.

[markjolesen]

Bill,

Your correct, I checked using 'testcurs -z' and did not get mouse movement messages in either DOS or x11 unless the button was pressed. Incidentally, It did fix a click and drag problem I was having. Sorry I jumped the gun. Bummer.

Regards, Mark

[markjolesen]

source: PDCurses/dos/pdckbd.c

125 bool PDC_check_key(void)
...
   INT 33,3 - Get Mouse Position and Button Status
   on return:
      CX = horizontal (X) position  (0..639)
      DX = vertical (Y) position  (0..199)
      BX = button status
167        ms_regs.W.ax = 3;
168        PDCINT(0x33, ms_regs);
...
   Here we are checking if a mouse button was pressed
   and if it is the same button. This is why only events
   with the button pressed is reported.
199        mouse_moved = !mouse_button && ms_regs.h.bl &&
201                       ms_regs.h.bl == old_ms.h.bl &&
202                    (((ms_regs.W.cx ^ old_ms.W.cx) >> 3) ||
203                     ((ms_regs.W.dx ^ old_ms.W.dx) >> 3));
   The check should be commented out
199        mouse_moved = !mouse_button && /* ms_regs.h.bl &&
201                       ms_regs.h.bl == old_ms.h.bl && */
202                    (((ms_regs.W.cx ^ old_ms.W.cx) >> 3) ||
203                     ((ms_regs.W.dx ^ old_ms.W.dx) >> 3));
   I am also not sure why the division is necessary?
   Just checking to see if new differs from old should suffice.

The initial patch above must also be applied.

[markjolesen]

For x11,

source PDCurses/x11/x11.c
static XtActionsRec action_table[] =
{
    {"XCursesButton",         (XtActionProc)XCursesButton},
    {"XCursesKeyPress",       (XtActionProc)XCursesKeyPress},
    {"XCursesPasteSelection", (XtActionProc)XCursesPasteSelection},
    {"string",                (XtActionProc)XCursesHandleString}
};
...
static const char *default_translations =
{
    "<Key>: XCursesKeyPress() \n" \
    "<KeyUp>: XCursesKeyPress() \n" \
    "<BtnDown>: XCursesButton() \n" \
    "<BtnUp>: XCursesButton() \n" \
    "<BtnMotion>: XCursesButton()"
};

As can be seen, there is an entry for buttons: <BtnDown>, <BtnUp>, <BtnMotion>.

BtnMotion: Pointer moved with any button held down

So, only motion events will be reported when a mouse button is pressed. What is needed, is "MouseMoved" or "PtrMoved."

MouseMoved: Pointer moved PtrMoved: Pointer moved

[markjolesen]

static const char *default_translations =
{
    "<Key>: XCursesKeyPress() \n" \
    "<KeyUp>: XCursesKeyPress() \n" \
    "<BtnDown>: XCursesButton() \n" \
    "<BtnUp>: XCursesButton() \n" \
    "<BtnMotion>: XCursesButton() \n" \
    "<MotionNotify>: XCursesButton()"
};

Seems that adding MotionNotify might be the solution? XCursesButton already has a case statement for it.

[Bill-Gray]

Thank you; you're right about adding MotionNotify. It doesn't appear to be the 'full' solution, but it is at least part of the solution.

I am still investigating how this is supposed to work. I can get situations where moving the mouse causes the area from the upper left corner down to the mouse location to be selected. I've also been working on getting 'testcurs' to work with ncurses mouse commands (it's currently set up to use the old Sys V commands), so I can get some grasp on how ncurses handles this problem. (One odd thing about ncurses handling: you get a mouse move event whenever the mouse moves at all, even if it's still in the same character cell as before. And a double or triple click in ncurses gets you just that double or triple click. In PDCurses, a triple-click is returned as three mouse events: a click, a double-click, and a triple-click.)

Anyway... the MotionNotify does bring us closer to success here, in that the code now "sees" messages when you move the mouse. We now "just" have a logic issue in figuring out what PDCurses ought to do with those messages.

[GitMensch]

What is the status of this issue? It seems to (have been?) related to all ports.

[Bill-Gray]

Current status is :

The framebuffer/DRM port has no mouse events at all. I've examined a few possible ways of reading the mouse from the console, including GPM, the uinput interface, and reading /dev/input/mice directly. None really work very well, and I can't find much guidance about which would be the "right" solution. It'd be nice to fix this; I could see this port being really useful on embedded devices where one doesn't really need X11.

VT, X11, and WinGUI support all mouse movement events. (*) I suspect that both the return to single-threading and some of the fixes that have been made to mouse handling on X11 and WinGUI cleared up the various issues reported above.

DOS, SDL1 and SDL2 lack mouse movement events, except when a button is down. This suggests to me they're actually getting the events; they just haven't been configured to report them. That ought to be fixable. The original behavior in PDCurses is to not report mouse movement events; that's been fixed in some ports in PDCursesMod, but apparently not in these.

I'd assume DOSVGA has the same issue as DOS (the mouse handling code is virtually identical).

I'm currently on my Linux box. Under Wine, I'm not seeing any mouse events at all. Pretty sure they worked (last I checked) on "real" Windows 10, but don't know about mouse movement events. Trying to get the mouse to work in Wine might be worth doing, for test purposes if nothing else.

No idea about Plan9 or OS/2.

(*) X11, SDL1, and SDL2, and some other platforms, report double-clicks and triple-clicks as two or three single clicks.