Keyboard keypress repeat and keyboard stop working on Raspberry Pi

No more problem here on a PandaBoard.

The FIQ fix is in ‘DWCDrive’ which I’m pretty certain is only used by the Pi, so no changes to the OMAP builds!

A few weeks ago I did have frequent chrashes and the Panda refused to boot without a keyboard. It’s not the case anymore :)

Are the latest fixes just keyboard related? Or will this improve mouse handling too?

I’ve never had my wireless mouse working reliably with the Raspberry Pi when used with the Attrix Lapdock.
(The Mouse is fine on my Pandaboard ES)

RISC OS 5.21 is used on both the Pandaboard & Pi. The mouse is the Logitech M510.

Rob: AIUI the changes may fix other USB problems, so I’d suggest give it a go and report back.

AIUI the changes may fix other USB problems,

Just wish we could hook audio playback to FIQ as well, so a RISC OS MP3 player could be a possibility. ;-)

I tried out the wireless mouse with the latest build of RISC OS, everything was working great until after approx 1 hour, everytime I double clicked on an application, it’s directory opened. (Seems the Filer thinks I have shift held down.)

everytime I double clicked on an application, it’s directory opened. (Seems the Filer thinks I have shift held down.)

This will deliberately happen if you are slow at releasing the button on the second click. I forget the name of the utility addon that is in the Pi Disc image that causes this.

No utility required these days, it’s built into the Filer. Just open the Filer configuration plug-in and alter the setting for ‘Double-click and hold’.

@Rick Not sure what you mean about an MP3 player, digitalCD works great for me.
Not sure how else I could cope reading PRMS and searching through C header files!
If only I could get netsurf stable, it’s a total mess at the moment (all versions on latest ROOL on pandaboard) – I’m hoping that’s my dodgy cd drive that’s causing some weird interaction, but I’m not holding out on that.

This will deliberately happen if you are slow at releasing the button on the second click. I forget the name of the utility addon that is in the Pi Disc image that causes this.

I make use of the feature quite regularly. However the issue is, this becomes uncontrollable after approx 1 hour of use.
This only occurs when using this mouse with the Raspberry Pi.

If only I could get netsurf stable, it’s a total mess at the moment (all versions on latest ROOL on pandaboard) – I’m hoping that’s my dodgy cd drive that’s causing some weird interaction, but I’m not holding out on that.

I’ve got the latest Netsurf (Stable & Dev) working nicely on my Pandaboard with the latest RISC OS 5.21 ROM. Can’t say that Netsurf ever gives me any issues. I’ve got Smart Reflex enabled, and the Pandaboard is overclocked. (With cooling!)

If only I could get netsurf stable, it’s a total mess at the moment (all versions on latest ROOL on pandaboard)

Updating my copy recently seemed to bring the joy¹ of attempted Tinct use on ARMv7 (two lines required in the NetSurf choices file to cure that)
plot_fg_quality:128
plot_bg_quality:128

There’s an alteration to the cache setup which may come into play, but the Tint rather than OS based dither seems to cause all the crashes²

¹ For certain values of joy
² based on changing to OS based and having all crashes go away again

@Rick Not sure what you mean about an MP3 player, digitalCD works great for me.

I mean it in a rather more literal sense. (^_^)

See: https://www.riscosopen.org/forum/forums/1/topics/2564?page=2#posts-32425

Dan: Over here is a ROM image which has some debug code enabled. Basically it contains debug builds of the USB drivers, and I’ve rigged the kernel’s abort handler so that it will dump a bunch of log output out over the serial port when the machine crashes.

Once you’ve booted the ROM, use the following two commands to set a ‘moderate’ level of debug output:

*usbdebug 10 10
*dwcdebug 11 0

And also the following to clear out any old log entries:

*dadreset

And then wiggle your mouse around until it crashes. Once it’s done printing out the log (it’ll take a minute or two, I’ve set it to a 1MB log buffer) email it to me and I’ll take a look.

Thanks Jeffery – a couple of debug traces are winging their way to you now.

My wireless mouse seems to be fine when the receiver is plugged straight into the Pi.
I was originally using a USB port on the Attrix Lapdock.

Is this issue now considered resolved? Is the keyboard now using FIQ?

I ask because I’ve noticed it still seems to be very dependent on the state of IRQ’s and appears to drop keypresses if they occur whilst IRQ’s are disabled.

I’ve been using my Pi with an Aten CS1784A DVI/USB2 KVM switch and the releases up to RC12a were basically useless with it as mouse movement was inaccurate and there were lots of missing or repeated keys. The Aten KVM has an option to reset its USB devices using a hot key combination and I found that each time I did that, the keyboard and mouse would vary their instability. Sometimes they would be perfect and stable, other times completely unresponsive and I would also get all combinations of instability in between those two extremes. I assume that resetting the USB devices was changing the relative timings of things so perhaps it would make a good overall test of stability. I have tried one of the latest January beta builds which I assume contains the FIQ fix code added since RC12a and it is much better. I still managed to get a repeated key stream after resetting the USB bus many times so it isn’t 100% fixed as Jon indicated but I found that connecting the KVM to the Pi via a USB 1.1 hub seemed to workaround that as presumably it slows the rate of USB interrupts.

I was wondering if there has been any further information on the keyboard rrrrrepeating issue? It had pretty much gone away on my Pi1, but since moving to a Pi2 it has resurfaced. I can only imagine it is some sort of subtle timing issue as, from my observations:

• Some days it seems worse than others (even if the machine hasn’t been reset!)
• Some software suffers more than others – I don’t see it much when typing in NetSurf, I see it quite a lot when typing in Zap, and in between the two with OvationPro (sensitive to system loading?)

Pi2 is powered from a five-output USB power source (running the Vonets and the HDMI, plus charging my phone from time to time – it’s rated 5A, able to output a reasonable amount of juice to each port). I don’t see the rainbow thingy. I did when I first set up the Pi2, so I changed the USB lead for one from my phone (which is able to fast charge at 9V/2A so needs a decent cable) and that solved the problem.
Keyboard, mouse, same as Pi1. Generic inexpensive non-fancy stuff.

I will remember the USBReset trick (previous message) and see if that makes any difference.

I intermittently experience the repeated key problem in StrongED on a Pi3.

Sorry to resurrect this topic, but recently I made a Teensyduino keyboard controller to connect an Acorn Archimedes A3010 keyboard through USB. I had the idea of using it with the RISC OS Pi, but what a surprise when I see that works on all the systems I tested (Linux, Windows 10 and even Raspbian on the Pi) but not on the RISC OS Pi.

Currently what happens is that (always) as soon as I press a key, it keeps repeating forever (well, I haven’t tested that long but you get the
idea).

I don’t think it is a hardware issue on the Pi side (as it was mentioned here). I tested with powered hub as suggested and also my controller works perfectly on the same RasPi 2B with Raspbian, but it does not when I boot RISC OS. So I’m guessing it is something related with how RISC OS works?

Maybe there is something I can do on my side (on my controller). Any ideas?

Thanks a lot in advance.

Oh, and if anybody is interested in replicating this controller, I posted it on GitHub (https://github.com/asmCcoder). It is far from finished yet.

Are you using the pi development ROM that has a fix for repeating keypresses that just missed the latest stable rom.

Are you using the pi development ROM that has a fix for repeating keypresses that just missed the latest stable rom.

From the description it doesn’t sound like it’s that particular issue, but an issue with interpreting the key up event. It might be worth grabbing the USB descriptor and some sample data of a key up to check.

I have to agree with Jon. The fix was to stop intermittent issues; if every single keypress is getting stuck then that’s a different problem. The RISC OS USB system has a few quirks; at one point I had a mouse that would crash FileCore :)

I am running the ROM that came when buying RISC OS ePic so I guess it’s the stable version.

I’ll download the Beta RPi ROM, test and report here.

Thanks.