[-Alan]

Hello there.

I've found a bug: On some screens the mouse won't work properly on newer Kodi versions. Here is the data I've collected so far:

Control Group:
C1: OpenELEC 5.0.8 / Kodi 14.2 on RPi 2 / Logitech M185 -> LibreELEC 7.0.2 / Kodi 16.1
C2: OpenELEC 5.0.8 / Kodi 14.2 on RPi 2 / Logitech M305 -> OpenELEC 6.0.3 / Kodi 15.2

Manifesting:
M1: OpenELEC 6.0.3 / Kodi 15.2 on RPi B / A4Tech 53J
M2: OSMC 2016.09-1 / Kodi 16.? on RPi 2 / Microsoft M1000
M3: OpenELEC 6.95.3 / Kodi 16.1 on RPi 2 / Microsoft M1000

C1 and C2 started to manifest the problem after the update as described.

Description:
On some screens, most notably when the on-screen keyboard is displaying, the mouse cursor will either disappear, freeze, or update its position at very low rates (each 5 seconds or more). The problem seems to be somewhat skin-dependent, while all skins have caused the problem to some degree, of all skins tested, none of them were immune to the issue:

C1: Amber, AppTV, Confluence, Arctic: Zephyr, Re-Touched, ReFocus, Transparency!, Unity
C2: AppTV, Confluence, Transparency!
M1: Confluence, AppTV
M2: OSMC Skin, Confluence
M3: Confluence

Apparently the problem occurs when there are either too many button UI objects on screen or/and too many overlaying dialogues, for example when you're configuring a media type for a source(*1), however, an important exception is the OSMC Skin which has an usable on-screen keyboard, although it manifests the problem elsewhere. A significant note is that while the cursor doesn't respond adequately to the mouse movement, the UI objects will still highlight normally, as if there was an 'invisible' cursor hovering them.

*1: For example, that dialog where you can change the language for the TVDB scraper.

Since the problem apparently is broad (Pi or Pi 2, 3 different systems, apparently any 15.x or 16.x version, and any skin), I think reproducibility won't be a problem. Basically if you plug a mouse in your Pi running Kodi and try to enter text using the on-screen keyboard, chances are you're going to see the problem.

I guess it's safe to assume it's not distro-specific but I don't have enough data to predict an extent. Maybe trying Kodi on Raspbian and confirming non-reproducibility on x86 Linux systems could provide valuable data for further diagnostics.

I hope this is useful somehow.

Thank you.

[nickr]

Mouse use with kodi is a pretty edge case...

[-Alan]

Mouse use with kodi is a pretty edge case...

I thought the same thing when I first saw the issue, still, I think it's worth fixing, but what made me investigate the problem further is that I've seen many people on Freenode IRC channels #openelec, #libreelec and even #raspberrypi complaining about that just in the last two days. I guess the number of mouse users is highly underestimated to be honest. Maybe some actual data collection could shed some light on that because so far I don't think we have reliable statistics on that.

I think mouse usage is high especially in poor countries because everybody has an old wireless mouse gathering dust somewhere and electronic products aren't very cheap so that "$5 remote" everybody talks about isn't '$5' comparatively, and LIRC (sensor on GPIO pins) isn't very popular. Besides that, the cheap remotes are sold as incompatible with anything but a very few Windows versions and programs like Windows Media Player and Real Player. I've seen lots of people with questions on whether they can buy something like this:
https://www.amazon.com/SANOXY-Wireless-R...+ir+remote
Since it's clearly stated it supports only Windows, and in the equivalent of "Ebay" in some countries like India and Brazil the sellers won't tell you if it works on the Pi and in practice you can't return and get a refund. I don't have information sources in China but I guess the same thing applies there.

So, there's a lack of information factor preventing people from acquiring proper remotes, especially since with LIRC you can have a decent remote experience at very low cost, but apparently people don't know that or aren't confident enough to try; and also it's not trivial to buy a 'supported' IR USB remote for most people. I'm almost sure that any 'generic' remote that resembles the one linked above will work, but sellers won't say that and for people in poor countries (which is by very far the majority of humans) it's not very cheap so they can't take the risk.

Also, maybe it's no coincidence that the reports started to get noticeable exactly when the Pi 2 fakes/clones dropped the price in India and I guess other countries.

There are some people who also simply prefer to use the mouse. I have a wireless mouse to be honest (the M305 is mine and it's always plugged in) and personally I find it much better than touch screen remote apps like Kore or Yatse as long as you have a proper surface (in my case the couch does the job) and a decent mouse that works well and is sensitive enough so you don't have to move it too much. Let's not forget people using Wiimotes or other unconventional pointing devices too.

By the way, I forgot to mention that I've tried setting usbhid_mousepoll to 1ms and 0 (and other values too) with no change in that behavior.

I agree that using a pointing device is not ideal, and maybe some actions could be taken to make it easier for people to use low-cost remote solutions like LIRC tutorials and a FAQ on cheap remotes. But that doesn't change my opinion that any obvious bug should be fixed, even if it's not the most used feature as long as it's supported of course (and as as far as I can say Kodi does/should support pointing devices). Whether it's high priority is arguable, but just letting a bug be because few (disputable claim) people use it, is not a decent approach.

Is there a way I can easily modify for example a skin on the Pi maybe via Samba and reload it (rapid iteration) so I could do some tests? I think since the OSMC skin is the most functional with a mouse (while on OSMC the other skins have the same problem), comparing it to other skins would be a good starting point to pinpoint the problem, I guess it's too much overdrawing/draw calls, but the symptoms are very odd to be honest.

Maybe a decent solution for all those problems is using hardware mouse acceleration, it's supported in the Pi graphics adapter and surely would get rid of any related problem, but I don't think it's trivial to do that to be honest. Maybe eventually someone will make an Addon to enable that like that "Pi Config" one.

[popcornmix]

Can you test with a LibreELEC Krpyton build? The builds you have tested are quite old, so I'd like to know if its a current problem.
Test either Kypton or Milhouse nightly build.

[-Alan]

Yes, I can test those builds. I'll report back after I've performed the tests and gathered the data, is there any additional data that might be useful?

[popcornmix]

Yes, I can test those builds. I'll report back after I've performed the tests and gathered the data, is there any additional data that might be useful?

If it fails the a debug log (wiki) would be useful.

[-Alan]

Hi, just tested the two builds. I've installed LibreELEC 7.90.006α in a new SD card to test, and the same problem happened, then I upgraded to Milhouse's #1010-11-Oct-2016 and no deal, same issue. On a side note, I guess if the skin supports it properly, a pointing device could actually be a quite decent alternative for controlling Kodi I guess. Maybe touchpad gestures could be a thing for example... well, if done properly. But anyway, just reporting the results.