August 2019 - Wine-Devel - list.winehq.org

Re: [PATCH v9 6/8] winex11.drv: Implement native mouse-movement raw-input using RawMotion.

by Derek Lesho

To add a little bit of further clarification, the purpose of sending normal input from rawmotion is for when we are at the edge of a clip and WM_MOUSEMOVE events without the MOUSEEVENTF_ABSOLUTE flag are sent, indicating the dx and dy parameters are relative. On Thu, Aug 1, 2019 at 2:34 AM Derek Lesho <dereklesho52(a)gmail.com> wrote: > > I just tested disabling normal input from RawMotion in oblivion, which > uses dinput, which does not use rawinput. Without it, I can not move > the mouse outside of the confines of the clip even when the pointer is > invisible / locked. I think that relative MOUSEMOVE events are still > supposed to be sent when the cursor is pushing up against the clip, > which would mean we need to keep the __wine_send_input extra stuff. I > have the rest of the changes you requested completed and will submit > them tomorrow as it's getting late here. > > > On Wed, Jul 31, 2019 at 4:04 AM Rémi Bernon <rbernon(a)codeweavers.com> wrote: > > > > On 7/31/19 12:41 AM, Derek Lesho wrote: > > >> AFAIU the existing RawMotion event handler was sending INPUT messages to > > >> the server for the sole purpose of emulating and sending raw input > > >> messages. > > > > > > It was my impression that MotionNotify events are ignored when the the > > > cursor is clipped, due to some bug or problem it. I went searching to > > > see whether the case, and I found this: > > > https://github.com/wine-mirror/wine/commit/0e2b4f99a9f5d97f8da0189037b7516c… > > > > > > This commit came around the time they were adding raw-input, and it > > > seems to indicate that there is a problem w/ MotionNotify on a clipped > > > cursor, but the ignore case isn't there anymore so maybe things have > > > changed. Some other reasons I'm skeptical that the RawMotion code > > > currently in place is only for rawinput events are that > > > > > > 1) The input is also sent as WM_MOUSEMOVE by the server, as there was > > > no previous infrastructure to send raw-input separately and > > > > This commit is about warping the cursor, then ignoring the MotionNotify > > event induced by the warp itself. > > > > I can see that the a pre-existing ignore case for MotionNotify events > > while clipping is active, comes from > > https://github.com/wine-mirror/wine/commit/8e9b4e0a5c6bee5f72ca2314db262336… > > and > > https://github.com/wine-mirror/wine/commit/da9922b40da5bc581815a4357340f3f1…, > > then reverted in > > https://github.com/wine-mirror/wine/commit/9716d1c8619e5fe68d1ad3ab9a18b106…. > > > > About these commits, I believe that while xinput2 events are received, > > and because they were translated as both raw input messages and normal > > input messages, it was maybe redundant to listen to MotionNotify as > > well. Also, the oldest commit makes me think that there could be some > > back-and-forth movement issues if MotionNotify events are processed > > while RawMotion events were delayed. > > > > Now regarding the interactions between MotionNotify and RawMotion events > > while clipping the cursor, AFAICS MotionNotify events are still received > > when the cursor moves but is blocked by the X11 confine window, with its > > current position in x,y fields. > > > > This means that regardless if the cursor is clipped or not, both > > MotionNotify and RawMotion events will currently get translated to raw > > and normal input messages, the raw message position being compared to > > the current position and converted to relative position, and the normal > > input message position being clamped with the clipping window and not > > sent if it is the same as the last known position (see > > queue_hardware_message in server/queue.c and > > https://github.com/wine-mirror/wine/commit/3909f51122ffc0f6150fa9758ba47c70…) > > > > So with the current code: > > > > * If the cursor moved (inside a clipping window), you get a normal input > > message from either MotionNotify or RawMotion (which ever came first), > > then two raw input message, one with the corresponding relative > > movement, and another with 0x0 relative movement. The second normal > > input message is discarded because the cursor didn't move. > > > > * If the cursor is clipped and blocked by confine window, Wine receives > > (order may vary as well): > > > > * a MotionNotify event with identical position, which is translated > > to raw input message with 0x0 relative movement, but does not get > > translated to normal input message because the cursor didn't move. > > > > * a RawMotion event with some relative movement, which is translated > > to the corresponding raw input message with relative movement, and is > > added to current position, then clamped, and then ignored w.r.t. normal > > input message because the clamped position is the same as the last. > > > > Currently if the clipping window is disabled, then no RawMotion events > > are received anyway. > > > > > > > > 2) When somebody tested warframe with my patch before I re-added > > > mouse-movements, they had issues that were fixed by rebasing > > > mouse-movements on my commit, and warframe does not use raw-input for > > > the mouse. > > > > There could be some subtleties I may be overlooking, I will do some > > tests. Thanks for mentioning it. > > -- > > Rémi Bernon <rbernon(a)codeweavers.com>

Aug. 1, 2019

Re: [PATCH v9 6/8] winex11.drv: Implement native mouse-movement raw-input using RawMotion.

by Derek Lesho

I just tested disabling normal input from RawMotion in oblivion, which uses dinput, which does not use rawinput. Without it, I can not move the mouse outside of the confines of the clip even when the pointer is invisible / locked. I think that relative MOUSEMOVE events are still supposed to be sent when the cursor is pushing up against the clip, which would mean we need to keep the __wine_send_input extra stuff. I have the rest of the changes you requested completed and will submit them tomorrow as it's getting late here. On Wed, Jul 31, 2019 at 4:04 AM Rémi Bernon <rbernon(a)codeweavers.com> wrote: > > On 7/31/19 12:41 AM, Derek Lesho wrote: > >> AFAIU the existing RawMotion event handler was sending INPUT messages to > >> the server for the sole purpose of emulating and sending raw input > >> messages. > > > > It was my impression that MotionNotify events are ignored when the the > > cursor is clipped, due to some bug or problem it. I went searching to > > see whether the case, and I found this: > > https://github.com/wine-mirror/wine/commit/0e2b4f99a9f5d97f8da0189037b7516c… > > > > This commit came around the time they were adding raw-input, and it > > seems to indicate that there is a problem w/ MotionNotify on a clipped > > cursor, but the ignore case isn't there anymore so maybe things have > > changed. Some other reasons I'm skeptical that the RawMotion code > > currently in place is only for rawinput events are that > > > > 1) The input is also sent as WM_MOUSEMOVE by the server, as there was > > no previous infrastructure to send raw-input separately and > > This commit is about warping the cursor, then ignoring the MotionNotify > event induced by the warp itself. > > I can see that the a pre-existing ignore case for MotionNotify events > while clipping is active, comes from > https://github.com/wine-mirror/wine/commit/8e9b4e0a5c6bee5f72ca2314db262336… > and > https://github.com/wine-mirror/wine/commit/da9922b40da5bc581815a4357340f3f1…, > then reverted in > https://github.com/wine-mirror/wine/commit/9716d1c8619e5fe68d1ad3ab9a18b106…. > > About these commits, I believe that while xinput2 events are received, > and because they were translated as both raw input messages and normal > input messages, it was maybe redundant to listen to MotionNotify as > well. Also, the oldest commit makes me think that there could be some > back-and-forth movement issues if MotionNotify events are processed > while RawMotion events were delayed. > > Now regarding the interactions between MotionNotify and RawMotion events > while clipping the cursor, AFAICS MotionNotify events are still received > when the cursor moves but is blocked by the X11 confine window, with its > current position in x,y fields. > > This means that regardless if the cursor is clipped or not, both > MotionNotify and RawMotion events will currently get translated to raw > and normal input messages, the raw message position being compared to > the current position and converted to relative position, and the normal > input message position being clamped with the clipping window and not > sent if it is the same as the last known position (see > queue_hardware_message in server/queue.c and > https://github.com/wine-mirror/wine/commit/3909f51122ffc0f6150fa9758ba47c70…) > > So with the current code: > > * If the cursor moved (inside a clipping window), you get a normal input > message from either MotionNotify or RawMotion (which ever came first), > then two raw input message, one with the corresponding relative > movement, and another with 0x0 relative movement. The second normal > input message is discarded because the cursor didn't move. > > * If the cursor is clipped and blocked by confine window, Wine receives > (order may vary as well): > > * a MotionNotify event with identical position, which is translated > to raw input message with 0x0 relative movement, but does not get > translated to normal input message because the cursor didn't move. > > * a RawMotion event with some relative movement, which is translated > to the corresponding raw input message with relative movement, and is > added to current position, then clamped, and then ignored w.r.t. normal > input message because the clamped position is the same as the last. > > Currently if the clipping window is disabled, then no RawMotion events > are received anyway. > > > > > 2) When somebody tested warframe with my patch before I re-added > > mouse-movements, they had issues that were fixed by rebasing > > mouse-movements on my commit, and warframe does not use raw-input for > > the mouse. > > There could be some subtleties I may be overlooking, I will do some > tests. Thanks for mentioning it. > -- > Rémi Bernon <rbernon(a)codeweavers.com>

Aug. 1, 2019

Re: [PATCH v2] include : Added missing ComboBox_* defines.

by Marvin

Hi, While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=54996 Your paranoid android. === debian10 (build log) === error: patch failed: include/commctrl.h:5295 Task: Patch failed to apply === debian10 (build log) === error: patch failed: include/commctrl.h:5295 Task: Patch failed to apply

Aug. 1, 2019

[PATCH v2] include : Added missing Edit_* defines.

by Alistair Leslie-Hughes

Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- include/commctrl.h | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/include/commctrl.h b/include/commctrl.h index 477c5d666cc..1e44ab0f442 100644 --- a/include/commctrl.h +++ b/include/commctrl.h @@ -5336,6 +5336,14 @@ typedef struct _tagEDITBALLOONTIP (BOOL)SNDMSG((hwnd), EM_SETCUEBANNER, (WPARAM)(drawfocused), (LPARAM)(text)) #define Edit_GetCueBannerText(hwnd, buff, buff_size) \ (BOOL)SNDMSG((hwnd), EM_GETCUEBANNER, (WPARAM)(buff), (LPARAM)(buff_size)) +#define Edit_SetHilite(hwnd, start, end) \ + SNDMSG((hwnd), EM_SETHILITE, start, end) +#define Edit_GetHilite(hwnd) \ + ((DWORD)SNDMSG((hwnd), EM_GETHILITE, 0L, 0L)) +#define Edit_ShowBalloonTip(hwnd, tip) \ + (BOOL)SNDMSG((hwnd), EM_SHOWBALLOONTIP, 0, (LPARAM)(tip)) +#define Edit_HideBalloonTip(hwnd) \ + (BOOL)SNDMSG((hwnd), EM_HIDEBALLOONTIP, 0, 0) /************************************************************************** * Listbox control -- 2.17.1

Aug. 1, 2019

[PATCH v2] include : Added missing ComboBox_* defines.

by Alistair Leslie-Hughes

Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- include/commctrl.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/include/commctrl.h b/include/commctrl.h index ffc5636c4c2..477c5d666cc 100644 --- a/include/commctrl.h +++ b/include/commctrl.h @@ -5295,6 +5295,10 @@ static const WCHAR WC_COMBOBOXW[] = { 'C','o','m','b','o','B','o','x',0 }; ((INT)SNDMSG((hwnd), CB_GETMINVISIBLE, 0, 0)) #define ComboBox_SetMinVisible(hwnd, count) \ ((BOOL)SNDMSG((hwnd), CB_SETMINVISIBLE, (WPARAM)(count), 0)) +#define ComboBox_SetCueBannerText(hwnd, text) \ + ((BOOL)SNDMSG((hwnd), CB_SETCUEBANNER, 0, (LPARAM)(text))) +#define ComboBox_GetCueBannerText(hwnd, text, cnt) \ + ((BOOL)SNDMSG((hwnd), CB_GETCUEBANNER, (WPARAM)(text), (LPARAM)(cnt))) /************************************************************************** * Edit control -- 2.17.1

Aug. 1, 2019

Re: [PATCH 3/3] ws2_32: avoid data corruption of WSAPROTOCOL_INFO in ws_protocol_info()

by Marvin

Hi, While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=54995 Your paranoid android. === debian10 (32 bit report) === ws2_32: sock.c:1672: Test succeeded inside todo block: socket family invalid, expected 23 received 23 sock.c:1672: Test succeeded inside todo block: socket family invalid, expected 23 received 23 sock.c:3053: Test failed: Test[1]: expected 2, got 0 sock.c:3053: Test failed: Test[2]: expected 2, got 0 sock.c:3053: Test failed: Test[1]: expected 2, got 0 sock.c:3053: Test failed: Test[2]: expected 2, got 0 === debian10 (32 bit Chinese:China report) === ws2_32: sock.c:1672: Test succeeded inside todo block: socket family invalid, expected 23 received 23 sock.c:1672: Test succeeded inside todo block: socket family invalid, expected 23 received 23 === debian10 (32 bit WoW report) === ws2_32: sock.c:1672: Test succeeded inside todo block: socket family invalid, expected 23 received 23 sock.c:1672: Test succeeded inside todo block: socket family invalid, expected 23 received 23 === debian10 (64 bit WoW report) === ws2_32: sock.c:1672: Test succeeded inside todo block: socket family invalid, expected 23 received 23 sock.c:1672: Test succeeded inside todo block: socket family invalid, expected 23 received 23

Aug. 1, 2019

Re: [PATCH 2/3] ws2_32: implement IP_PKTINFO on *BSDs, which only have IP_RECVDSTADDR instead.

by Marvin

Hi, While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=54994 Your paranoid android. === debian10 (64 bit WoW report) === ws2_32: sock.c:3053: Test failed: Test[1]: expected 2, got 0 sock.c:3053: Test failed: Test[2]: expected 2, got 0 sock.c:3053: Test failed: Test[1]: expected 2, got 0 sock.c:3053: Test failed: Test[2]: expected 2, got 0

Aug. 1, 2019

Re: [PATCH 1/3] ws2_32: WSARecvMsg allows a NULL control buffer when no control messages arrive

by Marvin

Hi, While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=54993 Your paranoid android. === w7pro64 (64 bit report) === ws2_32: sock.c:11385: Test failed: got 0 sock.c:11386: Test failed: got 0000000000000000 sock.c:11387: Test failed: got 0000 sock.c:11388: Test failed: got 00000000 sock.c:11389: Test failed: got 00000000 sock.c:11396: Test failed: got 0464,00000234,00000002

Aug. 1, 2019

Re: [PATCH 13/13] include : Added missing Edit_* defines.

by Marvin

Hi, While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=54992 Your paranoid android. === debian10 (build log) === error: patch failed: include/commctrl.h:5295 Task: Patch failed to apply === debian10 (build log) === error: patch failed: include/commctrl.h:5295 Task: Patch failed to apply

Aug. 1, 2019

Re: [PATCH 12/13] include : Added missing ComboBox_* defines.

by Marvin

Hi, While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=54991 Your paranoid android. === debian10 (build log) === error: patch failed: include/commctrl.h:5295 Task: Patch failed to apply === debian10 (build log) === error: patch failed: include/commctrl.h:5295 Task: Patch failed to apply

Aug. 1, 2019