"Change Movement to Scroll" - default action triggered after movement

x64 Replacement/Alternative to Microsoft's IntelliMouse application.
Forum rules
Please read the forum rules before posting for the first time.
The more information you can provide, the quicker and more accurately someone can help.
NOTE: To reduce spam, new users can not post links, files or images until they have at least 4 posts.
Post Reply
User avatar
Killy
Dedicated
Posts: 46
Joined: Mon Nov 27, 2017 1:26 pm

"Change Movement to Scroll" - default action triggered after movement

Post by Killy »

I have "Change Movement to Scroll" on RMB, and default action is "No Change" (exact value is irrelevant though - the issue remains).

Expected behaviour:
Default action (RMB) is triggered on button release only if there were no movement(scroll).

Actual behaviour:
Every time I scroll, default action is triggered on button release (context menu shown in my case).

This might be happening in case of rather hign CPU load (I have a lot of stuff running simultaneously now).
After restarting XMBC it might work fine for under a minute, then it starts to behave like this.

Looks like something dodgy in there with default action handling.
User avatar
phil
Site Admin
Posts: 7627
Joined: Sun Apr 06, 2003 11:12 pm

Re: "Change Movement to Scroll" - default action triggered after movement

Post by phil »

I'm sure this used to work.... Did it work for you in earlier versions (through beta 17 maybe)?
Will have a look cos this one may be serious enough for a quicker 2.18 beta 1 with little fixes (or a 2.17.1 even!).

thanks,
Phil
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9/G604/M720/MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, AMD Ryzen 5900x, MSI x570 Tomahawk, 32GB DDR4,
nVidia RTX 2070s, Evo 970 1Tb NVME, 2x2TB WD Black (RAID1)
User avatar
Killy
Dedicated
Posts: 46
Joined: Mon Nov 27, 2017 1:26 pm

Re: "Change Movement to Scroll" - default action triggered after movement

Post by Killy »

I only know how to get v2.17 beta 16, and it has the same issue now.

While checking this, I also noticed ~15% CPU load rise when scroll emulation is used (release and last beta the same).
This might relate it to another issue Windows System Beep (audio) / IO latency
User avatar
phil
Site Admin
Posts: 7627
Joined: Sun Apr 06, 2003 11:12 pm

Re: "Change Movement to Scroll" - default action triggered after movement

Post by phil »

I can provide links to earlier betas or 2.16 if needed...

2.17 beta 1 https://www.highrez.co.uk/scripts/downl ... on=2170001
2.17 beta 7 https://www.highrez.co.uk/scripts/downl ... on=2170007
2.17 beta 10 https://www.highrez.co.uk/scripts/downl ... on=2170010
2.17 beta 12 https://www.highrez.co.uk/scripts/downl ... on=2170012
2.17 beta 15 https://www.highrez.co.uk/scripts/downl ... on=2170015

Hint: Just change the last 2 digits of the number at the end to get a different beta version!

Regarding the 15% CPU usage (probably 100% of one core), I cant reproduce that here, so any chance you could pop a copy of your profile in a PM so I can test it with your profile?

Thanks,
Phil
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9/G604/M720/MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, AMD Ryzen 5900x, MSI x570 Tomahawk, 32GB DDR4,
nVidia RTX 2070s, Evo 970 1Tb NVME, 2x2TB WD Black (RAID1)
User avatar
Killy
Dedicated
Posts: 46
Joined: Mon Nov 27, 2017 1:26 pm

Re: "Change Movement to Scroll" - default action triggered after movement

Post by Killy »

Beta 6 and up - has all the symptoms - excessive CPU usage and default action triggered.

Beta 1 to 5 - no excessive load. Default action not fired every time, but more like third of the times.

Example of a CPU load on a continuous scroll (might not be easy to reproduce without trackball):
scroll_cpu_beta_7.png
Sometimes the load can be split between cores more evenly.

Then I realized I have cursor slowdown modifier key turned on, set to Control.
Turned it off, checked beta 7 - no excessive CPU load, but default action still triggers after scroll.

Turned it on again, and now there were no more CPU load, to my surprise. Although I noticed another issue (I noticed it just before, but can now relate to modifier key) - there is a huge delay when typing on a keyboard while modifier key is active. This either not happen on beta 1-5 or has significantly smaller effect. But it still happens on higher versions, regardless of whether high CPU load is reproducing or not.
You do not have the required permissions to view the files attached to this post.
User avatar
phil
Site Admin
Posts: 7627
Joined: Sun Apr 06, 2003 11:12 pm

Re: "Change Movement to Scroll" - default action triggered after movement

Post by phil »

Well, try as I might, I cant reproduce this...
Not only does the default action not trigger, but the CPU usage remains "normal" too...
NOTE: When "default action" is set to "nothing", it should *NEVER* trigger any action. If you set the default action to something other than RMB, does that trigger as expected, when no movement is made, or does it always trigger OR does it still fire the RMB (i.e the original button) rather the the remapped "default" action?

You did say "After restarting XMBC it might work fine for under a minute, then it starts to behave like this." so maybe I need to wait longer, but I have waited for well over a minute and still the problem does not occur. I wonder if there is something in particular (another button mapping maybe) that triggers it...

Regarding the high CPU load, what sort of windows are you scrolling - does it make any difference to the CPU load (that is, the high CPU load may actually be in the app that's doing the scrolling)... Or is it definitely XMBC that's hogging that CPU - because I don't see it here - when change movement to scroll is enabled, XMBC it uses no more than 1 or 2 CPU (and I have only 4 cored with no hyper-threading so 100% of 1 core would be 25%).

Having layer modifier keys also makes no significant difference to CPU load here. While tying or using the mouse...

I'm starting to wonder if this is something external - has something else caused high CPU load in some cases (I don't suppose you have installed any BIOS updates for this Intel/AMD meltdown/spectre bugs that may be having a higher CPU load impact on XMBC - I have the latest Windows 10 and all updates but I haven't got a bios path for my 4th gen Intel CPU. I will check on different PC too (only tried on my gen I5 6600K desktop so far - will try in on my varying age PCs to see if I can get any joy (or misery in this case) out of those!
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9/G604/M720/MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, AMD Ryzen 5900x, MSI x570 Tomahawk, 32GB DDR4,
nVidia RTX 2070s, Evo 970 1Tb NVME, 2x2TB WD Black (RAID1)
User avatar
Killy
Dedicated
Posts: 46
Joined: Mon Nov 27, 2017 1:26 pm

Re: "Change Movement to Scroll" - default action triggered after movement

Post by Killy »

It had no difference whatever windows I was trying to scroll or what exact action was mapped. Sometimes it was like it was processing some events multiple times. So it was like there was another RMB click after release (no bouncing - I replaced the switch under RMB just recently).
I'm starting to wonder if this is something external
Yes, that's most likely it. I just discovered there was a stalled service "Internet Connection Sharing (ICS)". It's known issue in 1709 update, it seems, when this service stuck in "Starting" state and keep consuming some CPU time. And another network service got high CPU load in relation to that. Both were under 10%, but they probably got significant impact on event processing queue.

Disabling ICS resolved my issues, it seems.
Now I can only see small CPU load spikes when modifier keys are enabled and I trigger "Slow down cursor" modifier.
User avatar
phil
Site Admin
Posts: 7627
Joined: Sun Apr 06, 2003 11:12 pm

Re: "Change Movement to Scroll" - default action triggered after movement

Post by phil »

Well that's a good start re the CPU load, I wonder if the same is causing all the beeps that were reported elsewhere....

Regarding the default action.. You say it made no difference what default action was mapped - does that mean it always sent the right click, or it always sent the mapped default action (sorry but I need to be really clear on this as its critical).

I was wrong earlier when I said the default is set to nothing (don't intercept) that is should never send anything, it should do the default button action (so RMB if on the right button). It should only do nothing at all if set to "Disable".

I still haven't been able to reproduce that :(. Button bouncing could well cause it - i.e. its seeing two clicks. I know you said it cant be that, but it might be worth turning on debug logging and capturing the problem because that maybe will help me narrow it down, and certainly it will show if the button is being pressed more than once :)).
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9/G604/M720/MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, AMD Ryzen 5900x, MSI x570 Tomahawk, 32GB DDR4,
nVidia RTX 2070s, Evo 970 1Tb NVME, 2x2TB WD Black (RAID1)
User avatar
Killy
Dedicated
Posts: 46
Joined: Mon Nov 27, 2017 1:26 pm

Re: "Change Movement to Scroll" - default action triggered after movement

Post by Killy »

phil wrote: Sun Feb 11, 2018 4:20 pm does that mean it always sent the right click, or it always sent the mapped default action (sorry but I need to be really clear on this as its critical).
It was always sending the mapped action. I tried to set {capslock} as the default action and it was doing capslock then.

Now it will be harder for me to reproduce the issue. It will mean to reproduce the issue with Internet Connection Sharing service, turn modifier keys on and keep waiting...
If there were bouncing issues I would've still observing unintended clicks. But that's not the case. (De-bounce features in XMBC was never enabled, btw.)

I looked into the log and found stuff like this:

Code: Select all

11-02-3918 00:09:58.188> The lock for 'MouseHookLLProc 1' took 1218ms to release!
11-02-3918 00:09:58.188> ***************************************************************************
11-02-3918 00:09:58.188> WARNING: Mouse hook has taken too long (1218 ms). Hook may be disabled.
11-02-3918 00:09:58.188> MouseHookData: Msg=0x0204 (WM_RBUTTONDOWN), X=359, Y=879, Data=0x00000000, Flags=0x00000000, Time=1482160000, Info=0x0, Ptr=0x281EF1, Layer=0
11-02-3918 00:09:58.188> ***************************************************************************
11-02-3918 02:15:21.677> LeaveCS: Critical Section 'KeySwitchTimerProc' took 1453ms to release!
11-02-3918 02:15:41.702> The lock for 'MouseHookLLProc 1' took 1391ms to release!
11-02-3918 02:15:41.702> ***************************************************************************
11-02-3918 02:15:41.702> WARNING: Mouse hook has taken too long (1391 ms). Hook may be disabled.
11-02-3918 02:15:41.702> MouseHookData: Msg=0x0201 (WM_LBUTTONDOWN), X=453, Y=792, Data=0x00000000, Flags=0x00000000, Time=1489703328, Info=0x0, Ptr=0x291EF1, Layer=0
11-02-3918 02:15:41.703> ***************************************************************************
Almost exclusively in the day when I opened this topic (with version 2.17) and yesterday (with beta 5).
It seems that not only XMBC but other apps were affected too.
I have separate profile for games, with everything in "Don't Intercept" position, but still some clicks were delayed there. (I also got a similar response from another user who are unlikely to use XMBC, but still waiting response from him about his issue.)

I guess, being it XMBC or Windows, in such severe conditions something was unable to process events in queue properly and that leaded to multiple events on button release...
Not sure if there is anything to fix, since it's unlikely I would've got into this issue in normal conditions. And in case of the service issue anything like version switching was just delaying the symptoms. (Although it might reveal some bottlenecks for optimization?)
User avatar
phil
Site Admin
Posts: 7627
Joined: Sun Apr 06, 2003 11:12 pm

Re: "Change Movement to Scroll" - default action triggered after movement

Post by phil »

OK, sorry I didn't realize that the ICS fix also fixed the default action triggering...
Its great if that fixes it - I will have to see if BoseRoHS is having similar issues with high CPU usage from ICS!

But it makes some sense, esp, seeing those log entries. I think you are correct in that the ICS service taking too much CPU is preventing XMBC from seeing all the messages, or responding to the messages in time. And if the hook does not respond in time XMBC may well be getting confused!

Thanks,
Phil
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9/G604/M720/MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, AMD Ryzen 5900x, MSI x570 Tomahawk, 32GB DDR4,
nVidia RTX 2070s, Evo 970 1Tb NVME, 2x2TB WD Black (RAID1)
User avatar
Killy
Dedicated
Posts: 46
Joined: Mon Nov 27, 2017 1:26 pm

Re: "Change Movement to Scroll" - default action triggered after movement

Post by Killy »

Hmm...
Bad news.
It was all god for a whole day, and then default action started to trigger again and high CPU load on scroll emulation is reproducing too (in version 2.17, modifier keys disabled).

No stalled processes this time. But I still can run into the situation when XMBC start to misbehave.
So ICS service was adding to the issue but wasn't the only cause.

My guess now: high CPU load caused by imperfect scroll emulation, firing too many scroll events. And after overflowing event queue it does strange things on release.
The fact that there is a higher chance to get default action triggered if I release the button before the ball stops - adds to this theory.

Looks like there is something to improve in XMBC after all.
XMBC emits too much scroll events, processing events taking too long, or both.
"Delay between simulated keystrokes" option doesn't seem to do anything for scroll emulation.
This must be optimized somehow.

Beta 5 is unaffected, once again. Beta 6 is the first where the issue is reproducing in the current state on my machine. Looks like the fixes done there are computationally expensive or locking some resources far too long or something like that.
In beta 6 and 2.17, high CPU load is reproducing right from the start, when I continuously perform emulated scroll. And it takes some time before default action start to trigger after release.
Chance to get the default action triggered is higher on the scroll up for some reason...

No "too long" warnings in the log file so far from today.
User avatar
phil
Site Admin
Posts: 7627
Joined: Sun Apr 06, 2003 11:12 pm

Re: "Change Movement to Scroll" - default action triggered after movement

Post by phil »

Typical, on a day I had some free time to investigate - it worked...
And now that time is over, it doesn't work...
And either way, I cant reproduce it (I will have to dig out my track ball and try with that next - but Im not holding up much hope :().

XMBC sends scroll messages when the cursor moves so if it moves very quickly, I suppose it could be overloading things - Ive seen that in the past with really fast scroll wheel messages on free wheeling scroll mice - it beeps like reported in the other thread - are you getting IO buffer full beeps too by any chance? If not, then its not so clear...

Turn on the debug logging and reproduce, make a note of the time the default action triggers and send me that log (PM/Email) and hopefully it will give me something to go on when I next get time to have a look!

The software gods are clearly against me!
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9/G604/M720/MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, AMD Ryzen 5900x, MSI x570 Tomahawk, 32GB DDR4,
nVidia RTX 2070s, Evo 970 1Tb NVME, 2x2TB WD Black (RAID1)
User avatar
phil
Site Admin
Posts: 7627
Joined: Sun Apr 06, 2003 11:12 pm

Re: "Change Movement to Scroll" - default action triggered after movement

Post by phil »

Give 2.18 Beta 2 a try - it should fix this problem.
I know you said there was no chance of the button bouncing, but I think that may be what is happening (certainly was in another case of this - dealt with by email not forum posts).

I have modified 2.18 beta 2 to ignore a subsequent click/release if the first was less than 400ms ago and movement/scroll occurred then. It should have the desired effect here too but would like confirmation.

Thanks,
Phil
--[ Phil ]--
--[ Administrator & XMBC Author ]--
Logitech G9/G604/M720/MX518, Microsoft Intellimouse, Trust 16341 BT Mouse
Windows 10 x64, AMD Ryzen 5900x, MSI x570 Tomahawk, 32GB DDR4,
nVidia RTX 2070s, Evo 970 1Tb NVME, 2x2TB WD Black (RAID1)
User avatar
Killy
Dedicated
Posts: 46
Joined: Mon Nov 27, 2017 1:26 pm

Re: "Change Movement to Scroll" - default action triggered after movement

Post by Killy »

Looks good after one day in use.
Can't get more that 10% load on a single CPU core.
Have no default actions triggered after movement so far.
Post Reply