Keyboard keypress repeat and keyboard stop working on Raspberry Pi

Hi there,

I’ve been following the WIP ROMs and trying them on the Pi since the last stable release, but there’s something very important that has yet to be fixed, and that makes the system pretty much useless as it is: sometimes, a single keypress is repeated over and over, ruining whatever I’m trying to write, and other times the keyboard just stops responding totally, so I have to reboot.

It happens with both my wirerless usb keyboard and my wired IBM keyboard.

In Linux, these keyboards perform with no problems at all, in the same Pi. These things happened in Linux back in 2012, but no more.
Will they be fixed on Risc OS?

Oh! And what about USB joystick support? Will that be added? Jon Abbott is making an awesome work bringing Archimedes classics back to life in Risc OS for the Pi, so we need joysticks :D

I have exactly the same problem, I’m using a wired Dell keyboard on my Pi. The repeated key-press problem is frustrating but manageable (I just hit f12, followed by some other keys to clear the repeating one).

The ‘dead keyboard’ issue is for me thankfully a rare occurrence, I’ve only noticed it when testing games which need repeated rapid key presses. When it does happen, a complete switch off/on is the only cure…

What is the cause? Can a solution be implemented in RO?

… and is it really a bug?
I did have this problem with my high end keyboard. It was link to insufficient power. An USB hub with external power solved the problem.

This is a known bug, some keyboards suffer from it more than others. Linux used to suffer from the same problem on the Pi, until the low level driver was fixed. We are awaiting some kind soul to integrate those changes into the RISC OS driver (which is based on the same sources). I think it is on someone’s to do list but they are somewhat busy including other RISC OS work!

This issue is quite often confused with power issues, which did initially delay it being fixed on Linux. I believe the fix was to force USB to USB1 as the issue appeared to be at hardware level, things may have progresses since I last checked though.

Whilst I would not rule out a bug ….

My workaround has been to discard all of my original 1200mA power supplies from RS (the ones with the long flimsy bit of wire for the 5v connection) and to replace them with 2100mA power supplies from Farnell (and a much heavier duty 5v cable).

Beforehand, all 8 Raspberry Pis were totally unusable. Now they are rock solid (with both RISCOS and Linux).

If I have to use a USB hub, then it has to be powered from a good quality, heavy duty, power supply – which is then also used to power the Pi.

A poor PSU can cause the same symptoms as the acknowledged USB bug.
Re PSUs.
1200mA is overkill given that there is a 1Amp fuse on the board.
A 2100mA PSU can give a poor quality¹ output, just as a 1200mA one can. With only a light load on the USB ports (standard Mice/keyboard) the Pi draws 500-750mA, so it generally accepted that a 1A PSU should be more than adequate, provided of course it is of good quality.

¹ Like Iyonix PSU’s defining what is poor quality is difficult. The actual voltage can normally be +/- 5% ² and everything should work fine. I suspect it is ‘noise’ on the line that is the problem most often but I’m sure there can be other problems. If I can ever find the time I’ll put our scope on some suspect Pi and Iyonix PSU’s

This issue is quite often confused with power issues, which did initially delay it being fixed on Linux. I believe the fix was to force USB to USB1 as the issue appeared to be at hardware level, things may have progresses since I last checked though.

Inspired by this posting I connected my mouse and keyboard directly to the RPi via a small USB hub, presumably USB1 as it isn’t marked otherwise, and my problems seem to have gone away. Before, they were connected via my USB2 powered 10 port hub.

I can now have auto-key-repeat turned on, and my mouse clicks work as intended, whereas before clicking on, say, a character in Chars would result in a string of the character rather than just one, or clicking a button to increment a number field would advance a few digits!

Early days, but matters seem vastly improved ATM.

Worth a try! Nothing to lose!

I can now have auto-key-repeat turned on, and my mouse clicks work as intended,

I have my keyboard plugged in to the lower USB socket and the mouse (via hub) in the upper. I geeeeeeeet ;-) this problem occasionally (pressing the key again fixes it).
With the keyboard plugged in anywhere else or anyhow else, I got this problem a lot.
Never had any issue with the mouse; which is good as I need someplace to plug in USB media, too.

I believe the fix was to force USB to USB1 as the issue appeared to be at hardware level

Do you have any specifics? I’m just wondering if this would have an influence on the work Colin/Dave are doing re. USB audio.

I don’t have a pi but it’s unlikely that you are using this in USB1 mode. It’s all or nothing either everything uses USB2 or everything uses USB1 so you would have slow disc drives (I’m not even sure you can effect this change without a software change). I think the effects you are seeing is more likely related to the hubs conversion to USB2. USB1 devices are converted to USB2 by the hub. The Pi has a built in hub and you plug into that (the model A doesn’t have this hub) The protocol for dealing with USB1 devices which have been converted to USB2 is tricky to implement.

Its complicated so I won’t go into it but given that equal quality USB1 to USB2 conversion by the hubs I would expect a mouse plugged into either port of the pi or one which is the only usb1 device on a separate hub to perform equally well.

This wouldn’t be a problem if the software performed correctly but getting it to work correctly is as I said tricky.

USB audio was certainly an issue in Linux until fiq_split_enable was added, see issue 19

Also related to audio and the fix for the keyboard dwc_dtg.speed=1 was added to force USB1.1, you do however need a keyboard that works at USB1.

There’s lots of threads on the USB audio issues on the Pi, take your pick

I just fired up RISC OS under QEmu emulating a Pi for the first time, the first thing that happened when I started typing at the Supervisor prompt…a sticky key! I think that points at a software rather than hardware issue.

I just fired up RISC OS under QEmu emulating a Pi for the first time, the first thing that happened when I started typing at the Supervisor prompt…a sticky key! I think that points at a software rather than hardware issue.

On the other hand, the last bit I saw that had been altered by the people doing that QEmu Pi work was the USB keyboard/mouse handling. If were unaltered code then perhaps it might be a useful pointer, since it has been changed all bets are off.

The problem is not that the hardware isn’t capable but that it isn’t designed for a desktop environment it needs attention 8000 times per sec and that doesn’t happen. Moving the interrupts to fiq should improve things. Changing the controller to USB1 the device only needs attention 1000 times per sec which while easier to achieve still doesn’t happen all the time. ehci, (the controller on the other devices) by comparison can better cope with interrupts not arriving on time.

Isn’t that exactly what the split FIQ fork did?

8,000 times a second is perfectly possible. Games running under ADFFS generate 10,000+ aborts a second, so I would have thought a switch to FIQ would fix it.

I have used the FIQ interrupts for various projects in the ‘old days’™ of A310s, A5000s and RiscPCs. Keeping the FIQs free for ‘user’ use would be a very useful USP for RISC OS, and this might tempt some of the RPi ‘Bare Metal’ crowd to come over to RISC OS. RISC OS is a pretty ideal operating system if you want to read and write directly to the RPi hardware and associated add-ons, and having FIQs free would be good. FIQs on these early ARMs are relatively easy to use and very powerful, as they have extremely low interrupt latency.

Did the RPi Linux people actually find the root cause of the issue that was causing occasional USB packets to be lost when using IRQs ? i.e. was this due to excessive interrupt latency, or due to a fundametnatl hardware issue on the Broadcom chip ?

If we were able to fix the USB lost packet on the RPi without using FIQs that would be a feather in the cap for RISC OS.

Incidentally most/all the stuck keyyyyyyys that I’ve had on my RPi with RISC OS have been due to poor power supply issues. Normally my RPi is powered by a Huawei 1000mA phone charger and this works fine as my keyboard and mouse use the built-in 4-port USB hub in my Dell monitor. Yesterday I started getting lots of ‘stuck keysssssssss’ when I used a UK-built (late) RPi with the daughtercard with the Chinese USB/RTC/Serial/VGA ports on, powered using my Huawei micro_USB charger. These errors stopped when I powered the RPi using a good 12VDV power supply plugged into the Chinese daughtercard power socket (designed to accept 6-24VDC from memory). Slightly odd to me that this leads to such a specific symptom as the loss of a single USB packet from the keyboard ?

Ralph

Gordon who has done the USB FIRQ work for Raspberrypi.org has contributed frequently to the USB Redux thread here:
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=23544

Wasn’t Gordon resolving the “split transactions get lost” issue. I believe that was resolved around 7 months ago in the Linux kernel, does RISC OS need updating to match?

I think I read all the posts in that long thread as they appeared and I was certainly left with the understanding that Gordon did the FIRQ work. He almost certainly has done other USB fixes. I also read all the official Pi developer Twitter feed which is a list of source changes a bit like the headlines at https://www.riscosopen.org/viewer/revisions

Gordon was indeed involved in the RPi Linux FIQ work.

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=39175

“by gsh » Thu May 09, 2013 9:19 am
Announcement:

Please be aware there is a new kernel containing the USB FIQ driver, this is meant to fix problems like:

1) Keyboards dropping keys
2) Strange ‘resetting’ USB devices whilst enumerating
3) Anything which uses low speed for Full Speed devices and drops packets or does strange stuff!"

It does appear that the reason for using FIQs was due to the excessive IRQ latency with Linux. I would expect RISC OS to have a much better ARM IRQ latency, as it is a much much simpler operating system.

Worth noting that the FIQ ‘fix’ on the Linux RPi builds still does not fix all of the USB issues (see end of the thread above, and elsewhere).

Ralph

Wasn’t Gordon resolving the “split transactions get lost” issue. I believe that was resolved around 7 months ago in the Linux kernel, does RISC OS need updating to match?

Yes. Any volunteers?

I might be wrong on this as it’s been a while since I looked at the code, but I seem to remember that the Linux implementation of the FIQ fix relies on the fact that FIQ handlers on Linux have all the same capabilities as IRQ handlers. I.e. they can signal semaphores to wake up threads, they can use the heap a little bit, etc. This will pose problems for porting it to RISC OS as FIQ handlers under RISC OS have traditionally been much more bare-bones. In particular I think I was worried about how I’d be able to hook it into the RTSupport-based threading model that’s implemented.

It does appear that the reason for using FIQs was due to the excessive IRQ latency with Linux. I would expect RISC OS to have a much better ARM IRQ latency, as it is a much much simpler operating system.

Simpler doesn’t always mean better :) One problem with RISC OS’s IRQ handling is that (to keep latency low) we’re encouraged to re-enable IRQs as soon as possible, so that other devices can be serviced. But that also means that the IRQ handler will lose all control over how long its execution time is. E.g. the USB driver could receive an interrupt, re-enable IRQs from within its handler, and then have its processing blocked for an indeterminate amount of time due to the system receiving a bunch of other interrupts (sound, VSync, timer, SD, etc.)

And of course there’s still the possibility that the IRQs might be missed due to some code simply leaving interrupts disabled for too long.

Could you not have a bare-bones FIQ handler that copies the data into a FIFO that’s serviced via CallBack?

While tracing problems with isochronous transfers in ehci and ohci I noticed that isochronous interrupts scheduled for millisec intervals can be delayed up to 4 millisec. Fortunately this isn’t a problem for these controllers as you can ensure the controller is always busy by scheduling a number of transfers in advance.

I can’t see that IRQ is going to work on the pi – at least not properly. Keyboards and mice have long periods between interrupts so you may get away with them working after a fashion. bulk transfers are more forgiving of when they are scheduled – its normal for a bulk transfer not to happen until there is available bandwidth so missing some timeslots shouldn’t be a problem other than slowing things down. I can’t imagine isochronous working.

Could you not have a bare-bones FIQ handler that copies the data into a FIFO that’s serviced via CallBack?

IIRC that’s basically what the Linux code does – processes some simple stuff within the FIQ and then defers the rest to a thread (or maybe to an IRQ?). But that doesn’t mean it’s trivial to port across!