I’ve attached this wireless USB keyboard to an RPi2 running the latest version of OSMC at this time, and something strange is happening with some of the keys even at the console level.
If I type qwertyuiop, there’s no problem.
If I type asdf, I see as+~.
If I type h, it’s as if I’ve pressed Caps Lock.
The 4, 6 and g keys seems to have no effect at all.
This weird behaviour carries over to Kodi itself, but manifests a little differently:
qwertyuiop works as expected.
d shows up as +.
If I type f multiple times, it first shows as d then gets replaced with e, f and 3.
Similar for g: a, b, c, 2.
h seems to toggle between Shift being held down or not, with h8h8h8 causing *8* to appear.
This same keyboard works flawlessly if connected to a desktop computer running Linux Mint or Windows XP, so I assume it’s only a configuration issue at the system level. What steps can I take to resolve this?
Bus 001 Device 004: ID 25a7:0701
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Devices 001 to 003 are identical on another RPi2 without this particular keyboard, so I suspect that it’s Device 004. (The lack of any description on that line is not a paste error.)
That code (from memory) looks like a PC Remote which can be used as a keyboard - in practise it is tricky, as it is easy to switch beteen modes, and works better as a device for direction and special controls
This particular device (another pic here) identifies as a USB keyboard and a USB mouse when its receiver is plugged into a desktop machine, and there’s no way to physically switch the handheld device to a “remote” mode. It works as expected on the console of my Linux Mint desktop.
Could it just be a case of lower-level keyboard configuration?
It seems to be operating like some phones when entering SMS text - which is what my ‘PC Remote’ can do. It may be possible to find why. I seem toremember an old post about a remote operating in T9 mode, and this being assumptions made in the kodi configuration. There was no cure offered for the problem.
I should clarify that the SMS-style behaviour only occurs within Kodi and not at the console, so I suspect that Kodi is treating some key code specially rather than the remote itself emulating an SMS keypad.
If the weird behaviour only existed in Kodi I’d be less worried, because keys can be easily reassigned there. In my case though, even the console’s not getting it right. I don’t know where to begin in order to solve this.
Kodi defaults to SMS style letter entry on number keys for devices that present themselves as remote controls instead of keyboards - clearly this device does not present itself as a plain, standard keyboard.
I feel that maybe the way the underlying OS is identifying it is the problem, not the way the device is identifying itself.
If the device is identifying as a remote, surely it wouldn’t work properly on other systems—yet it works flawlessly at the console of my Linux Mint desktop. in an X session on the same desktop, and on my Windows XP computer (all with no additional drivers). Is this a false assumption?
What I’m struggling to understand is why it would be treated any differently at the console on the RPi2 vs. my Linux Mint desktop. I wonder if something like xev exists for the console…
For what it’s worth, the person who sold this keyboard to me had this to say:
So it sounds like it could be kernel version–related. There’s no obvious easy way to check what kernel versions ship with those two OpenELEC versions, but hopefully all I need to do is wait until OSMC ships with a newer kernel.
The problem won’t get magically fixed if we don’t know what it is. It could be just as much to do with which compile time kernel options are enabled at build time as the specific kernel version. Or they may have patched the kernel for that specific issue.
To find what kernel versions shipped with those builds of OpenElec you could run
from the command line after booting them - however as above the kernel version alone may not be an indicator of a solution.
This hope still doesn’t seem too far-fetched to me, especially given the major kernel version difference across the two OpenELEC releases.
Obviously I want to help identify what the actual issue is and what’s causing it, but please understand that I’m pretty clueless about this particular problem and I’m mostly just taking stabs in the dark.
I’m sorry to say that this is still a problem for me with the latest available version of OSMC (installed from scratch).
The problem is apparent both in Kodi and at the console, and use of the keyboard is basically impossible because:
Space is ignored
F3 maps to NumPad /
4 maps to NumPad .
6 maps to NumPad 0
- maps to NumPad -
= maps to NumPad 6
D maps to NumPad +
F maps to NumPad 3
G maps to NumPad 2
H maps to Caps Lock
Actually, I’ve just tried the keyboard on my updated Linux Mint desktop with the exact same outcome, so it’s clearly not an OSMC issue but something more underlying.
I realise this is out of OSMC’s jurisdiction now, but any ideas (if anyone has any) would still be gratefully received.
I guess it could be a keyboard “layout” issue. I seem to recall that Debian can prompt the user to press certain keys, after which the correct keyboard layout is automatically identified. Does anyone know how to trigger this?
I understand this is an old topic, but did anybody get to the bottom of it?
I have just purchased a Vero 4K so I cannot test it yet, but I get this issue with my rPi3 running OSMC. It doesn’t only affect my wireless mini keyboard, but a full USB PC keyboard too. Basically, all text entry through a keyboard is broken.
Funny thing is it all worked on my Wetek Core running OpenELEC with Kodi 16, yet a friend of mine has a Wetek Core running LibrELEC with Kodi 17 and that has the same issues.
I’m about to try an OpenELEC with Kodi 17 build on my Pi3 to see what that does.
Although I can’t test the Vero 4K yet, I fear it will have the same issue!