[Norsak]

Background:
In case it's relevant, I run all my XBMC / KODI deployments on:

- Older Desktop PCs
- XBMCbuntu
- LCD TV

I wanted to use a good remote control for each deployment. When you search for a nice remote control for a PC these days, you will find one common feature: Almost all remotes have air-mouse functionality built in. I ended up purchasing several MINIX A2 remotes


The Challenge

• The most sensible way to control XBMC/Kodi is to use only keyboard commands.
  
• Air-mouse remotes have buttons for Mouse functions and buttons for Keyboard functions.
  
• The buttons which are hard-wired to the Mouse clicks are in central positions and can not be ignored
  

The solution appears to be to edit the mouse.xml file to re-assign the tasks of those 2 buttons:

Code:

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

The Problem:
The problem is the reassigned buttons do not work reliably, rendering this approach unusable.

Specifically: If the remote is in motion (sending mouse movement) at the same time as I try to press one of the mouse buttons, reliability drops to less than 50%. Presumably motion + left click is being interpreted as mousedrag?
I have written a forum post describing this problem almost one year ago: Link

Work around which demonstrates that it could work
As it is almost impossible to purchase a PC remote without air-mouse functionality, and these remotes were expensive, I had to find a way to make it work.

The solution I used is ugly:
- I had to install evrouter Link,
- get evrouter to autostart
- give it enough permissions to manipulate the computer IO
- use evrouter to convert the remote's mouse clicks to keystrokes at a system level
- let XBMC process the resulting keystrokes, while ignoring all mouse actions.

This results in 100% reliability
But this is a very ugly hack that can not be passed off as standard operating procedure.

If there is a XBMC/kodi config solution which I am not aware of, please let me know how to correctly use an Air-mouse remote with XBMC.

Otherwise, please add this bug/feature-request to your development schedule.

[Ned Scott]

There is no XBMC/Kodi side solution. These are very poorly designed air mice and one of the big reasons the feature is now seen as a mark against the remote.

[Norsak]

There is no XBMC/Kodi side solution. These are very poorly designed air mice and one of the big reasons the feature is now seen as a mark against the remote.

Maybe they are poorly designed, but isn't this the design that is dominant in the market place?
Therefore: shouldn't there be a kodi side solution?

The problem is with XBMC/KODI, not the air-mouse:
When I test the air-mouse on other applications, It always registers left-click and right-click, even when the mouse is waved around (100% success)
This is a pretty strong indication that there is no system-level issue preventing an application from detecting mouse-clicks from an air-mouse.

As a matter of fact here is a simple test anyone can perform with a regular mouse:
(tested on Kodi 14.0 / Kodibuntu / 64bit)
- use mouse.xml to assign the Back action to Right-Click
- check that it works when the mouse is still
- now try right-clicking while wiggling the mouse around.....XBMC will not register a right-click and not perform a Back action with 100% success
(same is true for left-clicks accompanied by movement)

I think that is pretty strong evidence that there is a bug in XBMC/KODI that prevents the application from correctly interpreting mouse clicks.

Presently we can completely disable the mouse in XMBC/Kodi (system settings)
If we could alternatively disable all mouse-movement related activity, while preserving the monitoring of the mouse buttons, wouldn't that get us closer to a working solution?

[Ned Scott]

Maybe they are poorly designed, but isn't this the design that is dominant in the market place?
Therefore: shouldn't there be a kodi side solution?

No, and no :)

I'm a bit of a remote control freak, and I have a basket full of them. There are many different kinds, with many different features, collected over the years. I read up about other remotes that other people have used, and am eternally on a mission to find the "perfect" remote. I'm certainly no authority on the topic, but I have a fairly good idea of what is out there. Air mice are just one type, and they are far from dominate. There may be a high number of different types, but that's not the same thing. The Chinese factories can pump out variations all day long, and that doesn't mean they're dominating the market.

These remotes default to the air mouse being on, and share the select button with the mouse click. That's pants-on-head retarded. Not all of them do it, but a good number of them do. In a year there will probably be far less that do this. Air mice in general are a flash in the history of various remotes for media centers/computers. I seriously doubt anyone would find it worth the time and effort to support some poorly built remotes with some crazy complicated hack. There's so many better remotes out there of all different types (IR, RF, bluetooth, air mouse, trackpad, pure remote, etc) that it just makes zero sense to support bad design (really really bad design).

[Norsak]

Ned,

Ok so we have 2 issues in play here:

1.) Are Air-mice remotes good or bad designs?
2.) Is there a bug in XBMC/KODI that prevents the program from correctly detecting mouse clicks in the same way as 99% of all other programs?

1.) Are Air-mice remotes good or bad designs?

First off, I don't like the air-mouse feature. I have no use for it. I see what it's trying to do: When Android gets on the living room TV, they are trying to replace touch with the air-mouse. I don't think that's the pinnacle of UI evolution, I can't see myself using it even in a pinch.

Yes, the air-mouse feature is enabled by default (bad)
Yes, there is no way to tell by looking at the remote if the air-mouse feature is enabled/disabled (bad)
Yes, there is no way to reprogram the remote via USB (bad)

So why do I want these remotes? Because if you ignore the superfluous air-mouse feature, they are very useful remotes which have the exact form factor I am looking for.


My criteria included the following features:

- I want a tactile remote that I can read with my fingers without looking at it (no smartphone app)
- I wanted a one-handed, ambidextrous device. (implies conventional form factor)
- I wanted a QWERTY keyboard so that I can use the search option in XBMC
- I wanted a remote which uses radio rather that IR
- I wanted a remote that doesn't accidentally do stuff when lying between the sofa cushions
- I wanted a remote with around 10-15 buttons on the upper side (but not 50!) so that I can assign shortcuts to all my important XBMC functions.
- I wanted a remote my mom can also use.
- price had to be reasonable...

The MINIX A2 meets 90% of my criteria....after I installed evrouter to circumvent XBMC's shortcomings.
As a matter of fact, my top 3 remotes would all be air-mice designs.
Not because they have air-mice, but because they have the conventional form factor + a QWERTY keyboard.

If you think there are better remotes which I should consider, share your top ten, I am always happy to discover something new.

TLDR: Air-mouse feature is shit, everything else is actually quite nice.
.

.


2.) Is there a bug in XBMC/KODI that prevents the program from correctly detecting mouse clicks in the same way as 99% of all other programs?

This is a separate issue, and I'd like you to respond to my earlier claim: There is a bug in XBMC!
Perform the mouse-click test I described with a regular mouse:

Edit mouse.xml :

Code:

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

Now trying to trigger the Select and Back actions with the mouse buttons while wiggling your conventional mouse.
Now tell me you don't see what I see: XBMC get's confused by mouse movement and can not reliably detect mouse-clicks in the presence of mouse-movement.....and that's not normal, every other application can detect mouse-clicks in these circumstances.

THIS is the real problem, not the Air-mice!
If XBMC did not have this bug, you wouldn't be hating on air-mice so much. You would just use the above mouse.xml, and be able to evaluate them based on their button layout and form factor.

TLDR: XBMC has a bug that affects all mice, not just air-mice; please fix

[Ned Scott]

As far as I can tell, when the mouse is moving then normal "clicks" are "mousedrag". That is what Kodi sees. The fact that you had to use a program to modify what USB HID signal was being sent to Kodi seems to back up that this is not something Kodi can change as a normal application. I'm not a developer, so maybe I'm wrong and there is something on the Kodi side that could be done to fix this.

*shrug*

[Norsak]

The fact that you had to use a program to modify what USB HID signal was being sent to Kodi seems to back up that this is not something Kodi can change as a normal application

I have to modify the IO signal that is sent to KODI to bypass the bug inside KODI.
KODI can easily detect mouse clicks and mouse movement.

My unqualified opinion is that KODI contains a small logical error.
Some code was written that states:

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

Maybe this code makes sense when mouse-movement is a relevant input.
But when <mousemove>noop</mousemove> is set (or it's future equivalent in system->settings), simpler code should come into effect:

• Left-Click = Left-Click
  
• Right-Click = Right-Click
  

I believe it would be rather easy to fix that.
If we consider this a bug rather than a feature request, what is the proper procedure to submit a bug?

[Karnagious]

http://trac.kodi.tv/

[Norsak]

http://trac.kodi.tv/

Ticket created: http://trac.kodi.tv/ticket/15670
Not sure how tickets progress through the system. Guess I'll keep an eye on it and see what happens.

[Norsak]

Success!

jhsrennie was kind enough to see that I had a point.
He has merged code updates which will solve the problem starting in the next release.

Two new keynames have been created:

<mousedragend>
<mouserdragend>

The idea is that you can now capture a mouse-click + motion using these keynames.

The tested mouse.xml (nightly build Windows)

Code:

<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>
  
    </mouse>
  </global>
</keymap>

So a left-click will either be captured as <leftclick> or as <mousedragend>
and a right-click will either be captured as <rightclick> or as <mouserdragend>

Thank you jhsrennie !

[Ned Scott]

I stand corrected, I guess someone did find it worth while to fix. Good to hear :)

[helta]

for the record, air mice still suck.

[Mango123456]

Thank you very much to all involved! I have a Flying Squirrel which operates in a similar fashion to what you described.

[kimyiu1029]

Success!

jhsrennie was kind enough to see that I had a point.
He has merged code updates which will solve the problem starting in the next release.

Two new keynames have been created:

<mousedragend>
<mouserdragend>

The idea is that you can now capture a mouse-click + motion using these keynames.

The tested mouse.xml (nightly build Windows)

Code:

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

</mouse>
</global>
</keymap>

So a left-click will either be captured as <leftclick> or as <mousedragend>
and a right-click will either be captured as <rightclick> or as <mouserdragend>

Thank you jhsrennie ! 

i see that "<mousemove>noop</mousemove>" is noop, how can kodi recognize the movement(motion) of mouse? in my case, kodi doesnt even show the mouse cursor