I just picked up a new wireless mouse and have found that it behaves oddly on OSMC. It will only move within a certain small 4x3 area in the upper, left corner of the 16x9 1080 display. I have tried troubleshooting this a bit myself and have found that the boundaries increase in size when “Set GUI Limitation” is set lower & lower. However, it always remains a 4x3 square confined to the upper left quadrant.
I have tested this mouse out on a Windows machine, as well as an Mac OSX machine and it behaves fine in both environments. I have noticed that there are monitor settings for the Pi in “MyOSMC”, but I hesitate to mess around with them too much without checking here first. Also of note, is that a Google search reveals that this sort of mouse problem also shows up in certain video games where the solution involves toggling the resolution or setting the video to stretch or full screen.
As I have already tried quite a few things myself, I hope to get a few suggestions here.
Both correlate with the problem also found in certain video games in that they are caused by a scaling issue. These however are at an operating system level like what I’m seeing in OSMC. Could this be what I am experiencing and if so, can it also be traced back to Xorg [xorg-xrandr] xrandr scaling?
Ah, ok. Seeing as how these types of mouse issues are related to scaling, could the problem still reside in how scaling is done in OSMC specifically? It’s almost as if the resolution is being reported differently than it is being displayed.
Another thought… Could it be possible that OSMC’s operating system is outputting video to the HDMI as a 2nd monitor? The reason I ask is that a common tie between this problem seen in both gaming and basic system use is multiple monitors. It seems to be possible to reproduce this bug on many setups with as few as two monitors. Could it even be a combination of the OS scaling to a 2nd monitor?
When I was first experimenting with OSMC on a “Pi 2”, I was using an Rii 2.4GHz wireless combined keyboard/mouse. Works fine on everything else I’ve had it connected to (including other "Pi"s), but simply would not work properly under OSMC - kept on going up to the top-left corner of the screen (plus mouse movement would be interpreted as keypresses, and all sorts of other odd things).
I didn’t bother diagnosing it - just disabled keyboard and mouse support through the OSMC configuration and carried on by using the web interface instead (more than sufficient for what I needed); now have a “Vero 2” and just use the (very nice ) OSMC remote which came with it.
However, I wonder whether it might be related to your problem - does your mouse pointer stay where it is within the “4x3 square confined to the upper left quadrant”, or does it keep trying to go to the very top leftmost corner and the “4x3 square ...” is just the furthest you’ve managed to move it? If the latter, it might be worth looking into your mouse settings in a little more depth.
No, I have full control over the mouse movement, it’s just that the movement is confined to what seems to be a 4x3 square at the upper left part of the screen.
Well, I wanted to eliminate the mouse itself as being problematic before I continued asking for help, so I tested it on as many machines as I could get access to today. I have now tested it on OSMC (Pi2), EmuOS (x86), Mac OSX (10.11.3), Windows (7, 8.1 & 10), Ubuntu (Don’t know the version) and an android gaming machine running KitKat.
Out of all those systems, OSMC seems to be the only system that is having a problem. Are there any OSMC developers out there who might have an idea how to resolve this? Do any of my previous thoughts about scaling and hdmi as a 2nd monitor hold water? Is there some video setting in “MyOSMC” that might be helpful? Will Dylan ever tell Donna of his undying love for her after his regrettable indiscretions with her twin sister?
You see, there’s why you have to provide full information in the first place!
Sigh …
If only you’d have mentioned Donna’s twin sister then I’d have known to say try running:
sudo apt-get remove donnas_sister
(remember to use apt-get rather than dpkg as you don’t want any dependencies on Donna’s sister left lying around afterwards - could be awkward …) … I believe Donna’s sister doesn’t like mice, so that’s probably your problem …
I’m sure one of the OSMC team will reply to you shortly with some useful suggestions
Ha! Very good sir. That reminds me of another one. Interrupt me if you’ve head it…
0001-CHICKEN-CROSSING.
IF NO-MORE-VEHICLES
THEN PERFORM 0010-CROSS-THE-ROAD
VARYING STEPS FROM 1 BY 1 UNTIL
ON-THE-OTHER-SIDE
ELSE
GO TO 0001-CHICKEN-CROSSING
Oh no, anything but COBOL! Last I had to use that would have been, IIRC, “MicroFocus Level II” on a PDP 11 running Microsoft Xenix 2.9d … ahhh, brings back memories …
I had the idea to install OpenElec on my Pi to see if it works there. I’m hesitant to wipe out my current install, but if it would give some sort of insight, I suppose it would be worth it. Would that help diagnose the problem at all? Does it handle scaling any differently than OSMC? Did we ever decide if scaling was a problem here? It does still seem to be the common thread between similar issues on multiple platforms and applications.
Also, if I’m posting in the wrong area to receive this type of support, I apologize and would humbly ask to be pointed in the right direction.
Everything looks in order and indeed the mouse does work in it’s own little quadrant of the screen. But why is it trapped in the upper left hand area? I still plan to give OpenElec a try, but I figured I might as well have a second pair of eyes on the log before I scrap everything completely.
Well, the mouse works in OpenElec, Retropie and RecalBox as well. Adding those to the exhaustive list of other operating systems I named previously, I’m prepared to say this bug is somewhat limited to OSMC. Not knowing any more about the inner system’s workings than a series of educated guesses, I suppose I’ll just have to take comfort in knowing that there was nothing I personally could do to solve the problem.
While I suspect this could have been resolved given some more informed attention, I do understand that the developers having been feeling a lot of pressure to get Bluetooth running on the new Rasp3, among many other important things, both inside and out of OSMC development, so I don’t fault them for budgeting their time elsewhere. While I’ve never been OpenElec’s biggest fan, it will work to my needs well enough and I will most certainly continue to recommend OSMC to others.
Thanks for the help and the lols here THEM. Also, the clarification from ActionA on how OSMC renders graphics helped by eliminating a possible cause of my problem and I am most grateful. I’ll be peeking in from time to time to check out the beautiful new OSMC skin, as well as ask the odd question here and there as I still support four other OSMC installs for my family that just use simple CEC remote control input.
Until we meet again, keep up the good work and thanks to all.
Did you test with an OpenELEC build running Jarvis? The current stable OpenELEC runs Kodi Isengard (an older version), which handles mice a bit differently.
I installed the latest stable OpenELEC, so it is Isengard. Perhaps that is why the mouse is no longer in it’s invisible jail. From what I’ve been reading, a trapped mouse situation usually stems from a scaling issue, appearing most frequently on the second monitor of a two monitor setup. However, it is not exclusive to that case. Computer Games also seem to suffer from the problem quite frequently, but it can supposedly appear anywhere.
As far as skins go, I tested both Confluence and the default when troubleshooting in OSMC. I do hope the changes you spoke of will allow my personal Pi2 to return to the OSMC fold, but thankfully it’s superior performance and unique maintenance features can still be utilized throughout the rest of my family, which makes their lives and mine much easier.
) OSMC remote which came with it.