#15670 closed Bugs (Fixed)

Mouse-Clicks are not correctly processed in the presence of Mouse movement

Reported by: Norsak Owned by: jhsrennie
Priority: 4 - Normal
Component: Keymapping (Remote Control / Gamepad Controller) Version: 15.0 "Isengard" Alpha1
Severity: Normal Keywords: keymap mouse.xml Mouse Remote
Cc: Blocked By:
Blocking: Platform: All

Description

Bug Summary:
If Mouse Left-Click and/or Right-Click are assigned an Action using the keymap mouse.xml, this Action is only executed when the mouse is still. If the mouse is moving while clicking, KODI modifies it's interpretation of what keynames to lookup.

Left-Click + movement = mousedrag
Right-Click + movement = Null

This behaviour results in logical errors and causes issues with a number of input devices.
Forum dialogue concurs that there is presently no option to modfify or bypass this behavior

How to reproduce the error

modify the mouse.xml keymap as follows

<keymap>
  <global>
    <mouse>
      <mousemove>noop</mousemove>
      <leftclick>Select</leftclick>
      <rightclick>Back</rightclick>
      <middleclick>noop</middleclick>
      <doubleclick id="0">noop</doubleclick>
      <longclick id="0">noop</longclick>

      <wheeldown>noop</wheeldown>
      <wheelup>noop</wheelup>
      <mousedrag>noop</mousedrag>
      <mousemove>noop</mousemove>
    </mouse>
  </global>
</keymap>

Desired behaviour is: All Mouse movement is irrelevant, only Left-Click and Right-Click are assigned an Action

Now wiggle the mouse while Clicking. You will discover that KODI does not execute the assigned actions with 100% reliability.

(Tested on KODI 14.0/ KODIbuntu / 64bit)

Importance
Mouse-movement plays a lesser role than button presses in the majority of KODI deployments. The logic that mouse-movement should always override button presses seems dated.

Several input devices, especially gyroscopic 'air-mice' are not naturally still when transmitting Clicks. This group of devices appears to work un-reliably when used with KODI. But the device actually works perfectly, while a small logic error in KODI prevents reliable interpretation of it's IO signals. A large number of remote-controls are excluded from KODI usability, because of this.

Suggestion
Under System/Settings/Input devices there is presently an option to enable/disable Mouse. We could add an option to only Disable Mouse Movement , and assign simpler IO interpretation upon selection.

Left-Click = Left-Click (mouse-movement is ignored)
Right-Click = Right-Click (mouse-movement is ignored)

Alternatively if a line in mouse.xml triggered the above change in IO interpretation, for example <mousemove>noop</mousemove>, or a new key-word

This would be a little more user-friendly for someone modifying the mouse.xml file (they wouldn't need to google to find the system setting)

Please, please make this change. I have been living with this bug for over a year now.

Change History (17)

comment:1 Changed at 2015-01-04T12:14:11Z by jhsrennie

It isn't obvious to me why this is a bug. If you move the mouse fast enough whilst clicking, the mouse button down and mouse button up events will occur at different positions on the screen. If the distance between the down and up events is greater than some internal limit (that I can't remember offhand) a mousedrag event will be triggered instead of a click. NB *instead of*. XBMC does not generate the click event until it has waited to see if the mouse is being dragged. This means a mousedrag only generates a drag event not a click followed by drag.

It sounds as though this is really a feature request to turn off processing of drag and always create a click event even when the mouse button down and up happen in a different place. If so please close this ticket and resubmit as a feature request.

comment:2 Changed at 2015-01-04T12:27:47Z by Norsak

Fair enough, when describing the Left-Click. But Right-Click + movement results in a Right-Click in most other environments. Wouldn't you agree?

Last edited at 2015-01-04T12:38:17Z by Norsak (previous) (diff)

comment:3 Changed at 2015-01-04T13:18:02Z by Norsak

I tested the following mouse.xml (

<keymap>
  <global>
    <mouse>
      <mousemove>noop</mousemove>
      <leftclick>Select</leftclick>
      <rightclick>Back</rightclick>
      <middleclick>noop</middleclick>
      <doubleclick id="0">noop</doubleclick>
      <longclick id="0">noop</longclick>

      <wheeldown>noop</wheeldown>
      <wheelup>noop</wheelup>
      <mousedrag>Select</mousedrag>
      <mousemove>noop</mousemove>
    </mouse>
  </global>
</keymap>

Only examining the Select Action
According to your description:

  • left-mouse-button-down event is registered, and mouse-position1 in recorded
  • left-mouse-button-up event is registered, and mouse-position2 is recorded
if (mouse-position2 - mouse-position1)> n:
    mousedrag
else:
    leftclick

So either the leftclick or the mousedrag Action should be triggered. But informal testing shows that often 2 Select Actions are triggered for a single click using the above mouse.xml

Debug shows:

13:12:09 T:139905256245184   DEBUG: ProcessMouse: trying mouse action Select
13:12:09 T:139905256245184   DEBUG: Activating window ID: 10004
13:12:09 T:139905256245184   DEBUG: ------ Window Deinit (Home.xml) ------
13:12:09 T:139905256245184   DEBUG: ------ Window Init (Settings.xml) ------
13:12:09 T:139905256245184   DEBUG: ProcessMouse: trying mouse action Select
13:12:09 T:139905256245184   DEBUG: Activating window ID: 10019
13:12:09 T:139905256245184   DEBUG: ------ Window Deinit (Settings.xml) ------
13:12:09 T:139905256245184   DEBUG: ------ Window Init (SettingsCategory.xml) ------
13:12:09 T:139905256245184   DEBUG: ProcessMouse: trying mouse action Select

I get the same behaviour when <leftclick>noop</leftclick> is in the mouse.xml
It appears that mousedrag is performing the Select action twice?

comment:4 Changed at 2015-01-06T08:26:15Z by jhsrennie

Ah, erm, OK, my previous comment was wrong. I think it's the leftclick action that does the checking for dragging and this wouldn't happen with your keymap. I'll copy and paste your keymap and have a play.

comment:5 Changed at 2015-01-09T18:36:19Z by jhsrennie

I've reproduced the problem you describe, and my initial guess was correct. It happens because if the mouse moves while the mouse button is down the click is reported as a drag instead. If I modify the code to disable drag detection then the clicks are correctly processed even when I'm waving the mouse around like a mad thing.

So this isn't a bug. Kodi is behaving exactly as it's supposed to. The only solution I can see is yet another advanced setting to disable drag detection, but I'm not sure how well that would go down with the team as there are already a large and unwieldy assortment of advancedsettings.

If you fancy building your own version of Kodi I can tell you which line to modify to disable drag detection.

I'll leave the ticket open for now to give you a chance to reply. However I will close in in a few days.

comment:6 follow-up: Changed at 2015-01-11T06:45:40Z by jhsrennie

Have a look at https://github.com/xbmc/xbmc/pull/6171 I think I've found a way round the problem.

comment:7 in reply to: ↑ 6 Changed at 2015-01-11T07:26:48Z by Norsak

Replying to jhsrennie:

Have a look at https://github.com/xbmc/xbmc/pull/6171 I think I've found a way round the problem.

Ok, if we can map an action to mousedragend, I think that would solve the left-click issue.

(Under the present system I am not sure how anyone could assign an action to mousedrag, and experience the desired outcome, but I may not be thinking outside of my box)

Now what about the right-click + mouse-motion scenario?

In Windows, right-click + mouse-motion = right-click...as there is no right-drag concept.

Is this not the prevailing GUI convention?

In KODI

  • right-click = right-click
  • right-click + mouse-motion = Null
Last edited at 2015-01-11T07:27:45Z by Norsak (previous) (diff)

comment:8 Changed at 2015-01-11T07:40:22Z by jhsrennie

The mousedrag action is required to update the cursor. If it didn't exist the cursor would disappear every time you did a mouse drag. You can see this in action by leaving <mousemove> mapped to mousemove and mapping <mousedrag> to noop. The result is that the cursor disappears every time you do a drag. At the moment the mousedrag action doesn't do anything except update the cursor - I don't think Kodi uses drags anywhere.

I think most GUIs do support right dragging. For example in Windows right dragging is used to create shortcuts on the desktop. Kodi doesn't have any right drag support at the moment, but it could be easily added. However let's see what the team make of my pull request. At the moment it has attracted no attention, which probably means the team don't think it's worth adding.

comment:9 Changed at 2015-01-12T10:58:47Z by Norsak

I am monitoring the git-hub thread.
I appreciate you taking on my little cause.

comment:10 Changed at 2015-01-13T10:09:16Z by jhsrennie

Well no-one complained about the change so I've merged it. I've created a new pull request to add support for right dragging:

https://github.com/xbmc/xbmc/pull/6197

These changes will be in the next version of Kodi. You could simply wait for v15 to be released, or you could build your own kodi.bin from the source code.

comment:11 Changed at 2015-01-13T10:13:33Z by jhsrennie

Actually, what OS do you use? If it's Windows or Ubuntu I can provide a version of Kodi for you to test.

comment:12 Changed at 2015-01-13T13:28:47Z by Norsak

I use KODIbuntu for deployments
I downloaded the (Windows) nightly build of Jan 13th 6am for testing.

I tested the following mouse.xml

<keymap>
  <global>
    <mouse>
      <mousemove>noop</mousemove>
      <leftclick>Select</leftclick>
      <rightclick>Back</rightclick>
      <middleclick>noop</middleclick>
      <doubleclick id="0">noop</doubleclick>
      <longclick id="0">noop</longclick>

      <wheeldown>noop</wheeldown>
      <wheelup>noop</wheelup>
      <mousedrag>noop</mousedrag>
      <mousedragend>Select</mousedragend>
      <mousemove>noop</mousemove>
    </mouse>
  </global>
</keymap>

Casual testing indicates that left-click works 100% as promised
So a big thank you for fixing it, this has been bothering me for over a year.

..shall we move on to right-click?
You are correct to point out that there is in fact a right-drag concept in Windows. But as we know left-drag plays almost no role in KODI, and right-drag has no role in KODI.

Is there an a similar work around you can implement for right-click + Mouse movement ?

Last edited at 2015-01-13T13:29:55Z by Norsak (previous) (diff)

comment:13 Changed at 2015-01-13T15:49:50Z by jhsrennie

Good, glad it works :-) There's a pull request to add right click support at https://github.com/xbmc/xbmc/pull/6197. If no-one objects (no-one is likely to) I'll merge this on Wednesday. Thursday mornings build should have support for:

<mouserdragend>Back</mouserdragend>

comment:14 Changed at 2015-01-14T08:54:39Z by jhsrennie

I've added the right drag support. This didn't make the 14/01/15 nightly, but will be in the nightly on 15th Jan.

The mouse.xml I tested with looks like (this is a minor tweak of yours):

<keymap>
  <global>
    <mouse>
      <leftclick>Select</leftclick>
      <rightclick>Back</rightclick>
      <middleclick>noop</middleclick>
      <doubleclick id="0">noop</doubleclick>
      <longclick id="0">noop</longclick>

      <wheeldown>noop</wheeldown>
      <wheelup>noop</wheelup>

      <mousemove>noop</mousemove>

      <mousedrag>noop</mousedrag>
      <mousedragstart>noop</mousedragstart>
      <mousedragend>Select</mousedragend>

      <mouserdrag>noop</mouserdrag>
      <mouserdragstart>noop</mouserdragstart>
      <mouserdragend>Back</mouserdragend>
    </mouse>
  </global>
</keymap>

comment:15 Changed at 2015-01-15T20:31:16Z by Norsak

I have downloaded the 15/01/15 nightly build for Windows. I tested using this mouse.xml

<keymap>
  <global>
    <mouse>
      <mousemove>noop</mousemove>
      <leftclick>Select</leftclick>
      <rightclick>Back</rightclick>
      <middleclick>noop</middleclick>
      <doubleclick id="0">noop</doubleclick>
      <longclick id="0">noop</longclick>

      <wheeldown>noop</wheeldown>
      <wheelup>noop</wheelup>
      <mousedrag>noop</mousedrag>
      <mousedragend>Select</mousedragend>
      <mouserdragend>Back</mouserdragend>
      <mousemove>noop</mousemove>
    </mouse>
  </global>
</keymap>

Both left-click and right-click now work 100% reliably using my airmouse remote. Thank you very much for addressing this issue, this will make several new remotes viable for use with KODI.

Will you be updating the KODI wiki to alert people to the existence of the 2 new keynames? I'd be happy to write about air-mice remotes, provided my request for a wiki account is approved.

I have one observation.
I thought it was related to your changes, but has probably been there all along:

If you trigger the Select or Back actions with the keyboard, each has a sound-effect
If you trigger either action with a mouse-click there is no sound effect....

This doesn't bother me as I disable those sound effects, but maybe it's something that would bother you.

comment:16 Changed at 2015-01-16T06:44:42Z by jhsrennie

  • Resolution set to Fixed
  • Status changed from new to closed
  • Version changed from 14.0 "Helix" Final to 15.0 "I***" Alpha1

Thanks for testing. I'll have a look round the Wiki and see where it make sense to document the new tags.

comment:17 Changed at 2015-01-28T18:11:03Z by Martijn

  • Milestone changed from Future / Pending to 14.0 "Helix"
Note: See TracTickets for help on using tickets.