[CrassPants]

I am unable to type in XBMC. The keyboard appears to behave as a remote control. Arrows, enter, and escape work, and numbers act like SMS key presses. Issue is present with both my bluetooth keyboard and USB keyboard. Keyboard behaves correctly in shell.

Using an unofficial build of xbmc v12 from the arch linux arm forums for my raspberry pi. Didn't have any issue in raspbmc, but still not sure if this is because of compile time options or some config file like keyboard.xml. There currently isn't a v11 binary available for arch linux arm, so I'd have to compile it myself (Not easy with 256MB ram and a cell phone cpu).

Here's some pertinent information. I'm happy to provide more if asked:

lsusb:
Bus 001 Device 006: ID 04f3:01a4 Elan Microelectronics Corp. Wireless Keyboard

uname -a:
Linux alarmpi 3.1.9-28-ARCH+ #1 PREEMPT Fri Jul 6 23:07:26 UTC 2012 armv6l GNU/Linux

XBMC version:
XBMC 12.0-ALPHA3 Git:20120623-e443c98 (Compiled: Jun 24 2012)
Retrieved from http://archlinuxarm.org/forum/viewtopic....cab914fa30

Suspicious log entries

Code:

16:01:26 T:1099304960 WARNING: no keymap support (requires /dev/tty0 - CONFIG_VT)

Thanks in advance!

Edit: grammar

[artrafael]

Yes, the keyboard is used extensively to control various XBMC functions, as described here.

Where in XBMC are you trying to type text? When the virtual keyboard is displayed?

[CrassPants]

Trying to type in the virtual keyboard areas and text boxes. The hotkeys described in the wiki work fine (c brings up contextual menu's etc...)

[artrafael]

I know you said that you didn't have this problem using Raspbmc, but here's something in their forums last month that seems suspiciously similar to the error you reported: http://forum.stmlabs.com/archive/index.p...09-13.html

I haven't read through that thread, but maybe the problem was fixed in Raspbmc but not in the ArchLinux ARM build for the Pi? Just a thought. I don't have a Raspberry Pi (wish it was more readily available ), so I can't offer much more.

[CrassPants]

Changed permissions of /dev/tty0 to 0777, issue resolved.

Added "chmod 0777 /dev/tty0" to /etc/rc.local to make change permanent.

Thanks for the help atrafael!

[artrafael]

Cool, glad you got it fixed!

[hangten]

Hey guys,

I had the same problem with my IOGear wireless keyboard and this solution did fix the problem. Fantastic!

Don't want to look a gifted horse in the mouth, but I hate patching stuff through init startup scripts. I tried solving this by modifying udev rules (e.g. KERNEL=="tty[0-9]*", MODE="0660") , but no success. Used 660 because rw permission is all that is needed.

I am still open to anyone who can suggest getting the system to set the proper permission on tty0 without the user having to do this. I am also curious to know why this permission setting fixes this problem....something to do with XBMC passing keyboard through tty0? I understood tty0 to be the system console. Anyway, it would be good to know the mechanics behind this.

Thanks.

[hangten]

.....answered my own question and was able to implement a udev rule that did the trick.

The following line was added to a newly created file /etc/udev/rules.d/51-udev-tty.rules :

SUBSYSTEM=="tty", KERNEL=="tty0", GROUP="tty", MODE="0660"

The original tty rules were in /lib/udev/rules.d/50-udev-default.rules. You don't want to edit the rule files under /lib. Add your customize rules to /etc/udev/rules.d and make sure it falls in the proper alphabetical order. Note the new etc/udev/rules.d/51-udev-tty.rules file alphabetically (or numerically) follows /lib/udev/rules.d/50-udev-default.rules. From what I read, the etc/ rules supersede the /lib rules but I still kept the alpha sequence intact just in case. Anyway it works.

My OpSys is 3.6.11-8-ARCHLINUX running on a raspberry pi.

I still wonder why XBMC requires this permission to get the keys on keyboard to pass thru tty0? Maybe a XBMC developer can shed light on this some day.

[J040]

The kodi-rbp package (a special build for raspberry pi on Arch Linux ARM) is effected by this issue.

[mccurly]

Hello and sorry if this seems a little too necro... but since I also faced this problem, with kodi-rbp package, and I was 'inspired' by the advices from above, and because the new ALARM archpi has a different way of enumerating those udev rules (not sure if that is true but anyway...), I came up with this solution:

change the file /etc/udev/rules.d/raspberrypi.rules from

Code:

SUBSYSTEM=="vchiq|input", MODE="0777"
KERNEL=="mouse*|mice|event*", MODE="0777"

to

Code:

SUBSYSTEM=="vchiq|input|tty", MODE="0777"
KERNEL=="mouse*|mice|event*|tty0", MODE="0777"

There is one thing though: I am not quite sure this is perfectly safe so... If anyone has more precise ideas about these permission settings I would be more reassured too.

Cheers.

[Numinous]

Thank you @CrassPants !

changing the permissions of /dev/tty0 worked for me aswell