Keyboard 'key up' occasionally lost

I have a radio keyboard connected to the Pi and very occasionally it misses the ‘key up’ event so that the key concerned repeats until struck again. Less often it misses a ‘key down’ event but that may be me missing the key! It can happen several times in a row. (This happened in the early days of the Iyonix I seem to remember.)

Same problem here with a wireless keyboard and wired mouse. I had thought it was a power supply issue but I’m using a 1A supply so shouldn’t have any problems. Is this a problem that is unique to RISC OS? I haven’t tried running any other OS for a significant amount of time but I can’t recall noticing any keyboard problems… not that I used the keyboard much anyway! I found the Pi to be a little on the sluggish side when running any other OS.

I’m using a wireless keyboard as well and have been noticing a similar issue on the Pi. I often get a period of about 20-30 seconds of bad behaviour, shortly after entering the desktop, with the trackball moving irratically and mouse clicks often being lost. It’s possible it’s a bug in the threading code I had to write in the USB driver, so I’ll have to try getting some useful debugging info from that (not easy with the high rate of interrupts the driver generates). There are also some new patches that I need to look into integrating, so if it’s not my code causing it it’s possible those patches will fix it.

I’ve seen a similar issue whilst running Linux on the RPi. If it doesn’t recover shortly then I tend to just unplug and reinsert the USB keyboard/mouse which normally ‘fixes’ things. So its not specific to the RISC OS build.

I’ll have to try getting some useful debugging info from that (not easy with the high rate of interrupts the driver generates).

A topic I’ve often thought about. Would it be useful to have an RM that simply logs strings to a (large) area of memory? That way it could log extremely rapidly (quick response time) for a fair duration.

A topic I’ve often thought about. Would it be useful to have an RM that simply logs strings to a (large) area of memory? That way it could log extremely rapidly (quick response time) for a fair duration.

We’ve already got one of those – DADebug, and I use it almost exclusively when I want to get debug output from anything which relies on interrupts. I probably just need to tweak things a bit to make it more useful in this situation.

We’ve already got one of those – DADebug

It’s a handy module, although the spec could do with defining what a “line” is in the context of this debug – is it a zero-terminated string, LF and/or CR terminted, ctrl-terminated?

LF terminated.

I’m using a wireless keyboard as well and have been noticing a similar issue on the Pi. I often get a period of about 20-30 seconds of bad behaviour, shortly after entering the desktop, with the trackball moving irratically and mouse clicks often being lost.

Annoyingly, now that I’m trying to debug the issue, this seems to have stopped happening. If I can’t reproduce it using the fresh image I’m about to build, I think I’ll have to ignore it for now and move on to merging in the USB patches.

Hi Jeffrey,

I seem to experiencing this issue with my Pi quite regularly with my wired Logitech USB keyboard. Similarly, my mouse seems strangely unresponsive to clicks at times.

How might I be able to provide some debugging?

I had this problem earlier with the latest Rasp Pi ROM image and updates but I didn’t realise it was this problem at first.

The shift key was “auto-repeating” so when I clicked on the close windows widget they were being pinned to the pinboard rather than closing. Hitting the shift key a couple of times and then expanding the minimised windows and closing them again worked so it was definitely a manifestation of this problem.

I’m using an original MS Natural Keyboard Elite ergonomic keyboard which is wired USB and around 12 years old.

Paul

I’ve just been using the latest release of Raspbian and had the same key up issue, this time with the cursor keys so this could well be a Raspberry Pi firmware issue…

Paul

I think this pretty much confirms it’s a USB stack packet loss issue…

https://github.com/raspberrypi/firmware/issues/19

Paul

They wrote a USB ‘ping’. Nice :)

I’m glad it’s been narrowed down – I was seeing this on both Debian and RiscOS and was blaming my old Apple keyboard with it’s on-board hub. Looks like I don’t have to go spend any more money on a new one…

I’m using a wireless keyboard as well and have been noticing a similar issue on the Pi. I often get a period of about 20-30 seconds of bad behaviour, shortly after entering the desktop, with the trackball moving irratically and mouse clicks often being lost.

I’m able to reproduce this again now. CPU traces don’t seem to show anything obviously different between the “good” and “bad” states, so it looks like I’ll have to try getting some debug logs from the USB drivers.

At the Bletchley Park Raspberry Jam on Sunday, Rob Bishop from the foundation said that they had just (Friday?) checked in a lot of fixes for USB. Stuck or missed keys/mouseclicks were mentioned.

So it might be worth looking there before poking about for RISC OS specific bugs.

Yeah, there are a few changes they’ve made recently, but nothing that jumps out at me:

• They reverted the patch which reduced the IRQ rate, AIUI because it was causing stuck keys (and similar issues). However I never enabled that patch in the first place, because I couldn’t get it working reliably with our port of the driver (probably because we’re currently using a centisecond timer for a lot of our task scheduling)
• They incorporated a patch to add transfer scheduling on the microframe level, except I’d already incorporated that patch several weeks ago (at the same time as I looked into the IRQ patch)
• They found a problem with their SD drivers where USB interrupts were being missed due to the SD driver disabling interrupts for too long (which would have been another cause of missed keypresses). My CPU traces didn’t show any obvious signs of code leaving IRQs disabled for long periods of time, so it’s unlikely that we’ve got a similar problem
• They also updated to version 2.94 of the DWC driver sources; out of all their changes this is the only one that might actually provide something useful to us, but there’s still no guarantee it will fix any of the issues we’re currently seeing.

The only thing I did spot when I was looking into this last night is that it looks like the mouse does freeze for a second or two before the erratic behaviour starts; if I can get a trace of that then that might pinpoint the problem. If that doesn’t reveal anything useful then I might have a go at updating to the latest Linux sources, but I’m not holding my breath!

For people experiencing keyboard/mouse issues: Are you all using wireless keyboards/mice? I have a feeling these issues may be down to inadequate power supplies rather than bugs in the USB driver.

In my case I’m using a HTC charger (1A output), with a USB stick, radio keyboard+trackball dongle, SD card, and LAN plugged into the Pi. After trying a few different things I was able to come up with a ROM build where the mouse will always be laggy on entering the desktop (it seems the issue is very sensitive to whether the USB drivers have debugging enabled or not, so finding a reliable way of reproducing it was tricky). If I swap the keyboard+trackball dongle with a wired keyboard+trackball then everything is fine. If I swap the keyboard+trackball dongle with a powered hub (with the dongle plugged into it) then everything is fine. If I remove the power from the hub then dongle loses power – so clearly I’m right on the limit of what the power supply/Pi is able to deliver.

Checking the elinux wiki also reveals that the Pi is only designed to supply 100mA to attached devices. If what my devices report via *usbconfinfo is to be believed, the USB stick needs 200mA and the dongle 100mA. Measuring the voltage across TP1 & TP2 using a multimeter shows that with everything connected I’m only getting a mere 4.66V, and the only way to get above 4.8V is to unplug everything and turn off the power-hungry LAN chip by killing the USB driver!

For people experiencing keyboard/mouse issues: Are you all using wireless keyboards/mice?

I use a wired Keyboard (A4TECH) and a wired mouse (Logitech) and get problems with repeated/stuck keys and missed mouse clicks whether using Linux (official Debian distro) or RISC OS. For me, Debian Linux is worse than RISC OS for the repeated key problem.

Perhaps the question should have instead been “Have you all checked that the voltage across TP1 & TP2 is acceptable?”

From this point on I’ll be using a powered hub (and hopefully a better power supply once I find one), so if there are any issues which aren’t power supply related then hopefully it won’t be long until I spot them.

Just to clarify: the Pi “is only designed to supply 100mA to EACH attached device”

This makes sense, I had massive problems getting wifi working reliably on the pi on the debian image.
I discovered this was due to power issues.
I have had the same irritating issue with my keyboard and mouse, but now I’ve plugged them both into the “powered” ports of my USB hub and no other items plugged into the hub. So I’ll see if the problem goes away, it’s fairly repeatable so if it doesn’t happen this week then power is definately the issue – I suspect it is.

I have this problem with wired kbd (on Belkin USB powered hub – 2.5A), only under Linux so far….

I am curious how they will fix this problem, as I read its definitely hardware issue (something about the polyfuses..)

http://www.petervis.com/Raspberry_PI/Raspberry_Pi_USB_Not_Working/Raspberry_Pi_140mA_USB_Power_Limit.html

I’ve had no end of power supply issues, which I eventually tracked down to high resistance micro USB cables. Of the 7 USB cables I have, only one has low enough voltage drop to correctly power a Pi. Having sliced open a few other USB cables, it’s impossible to tell from outside how feeble the conductors are going to be. Powered hub is no use as there’s still too much drop down the cable. I’ve resolved it by any of these methods:

• Taking croc clip leads directly from the charger to the Pi GPIO port power pins
• Using my one working cable (I have three Pis)
• Using a pigtail cable from Poundland: USB cable about 10cm long with a bunch of different connectors on the other end – micro, mini, iPod, Nokia, etc.

I’ve actually found the USB ports of the BBxM are handy for powering the Pi and not power limited. So I’m using it as a glorified plug adaptor.

Anyway, after all that I still lose keypresses. Fairly basic Cherry mini-keyboard, with either wired MS Intellimouse or Logitech wireless mouse. It’s worse at some times than others, but I haven’t looked into why (different Pi, different mouse, different power supply setup). It has definitely been happening when the voltage to the Pi is fine at 4.9V or so.

I had massive problems getting wifi working reliably on the pi on the debian image.

On a scale of 1 to 100, where do we stand with WiFi under RISC OS (I’m interested in Beagle, but I’d imagine a USB WiFi would look the same under that and Pi)?

I’m somewhat less inclined to run a server with my kit ethernetted to the Livebox after a lightning strike took out it, the Livephone, and the attached radio-walky-phone. :-(

WiFi would be good – but I’m aware there’s a couple of hundred cheapo devices out there, all subtely different. Plus the standards (with my new Livebox, my phone prompted me for WPS – the hell is that?), anyway…
…is this more a “possible maybe in a while” or a “not a hope in hell”?