Keyboard keypress repeat and keyboard stop working on Raspberry Pi

It has a pretty big bounty against it as well, I’m surprised there’s no takers.

1. I’m not sure if the low level Raspberry Pi work is covered by the Bounty.
2. I think there has been some discussion that Colin and Dave Higton’s recent work covers part of the bounty.
3. Some people are not particularly motivated by monetary reward (Claiming a much deserved bounty does put a degree of pressure on, that they might not want).
4. If I’ve read Colin’s post about correctly he doubts isochronous USB is possible on the Pi.
5. Jeffrey in his normal understated way suggests moving to FIRQ is non trivial. He has also stated IIRC that he has about a years work on his to do list.
So all in all a can of worms?

I suggest ROOL need to work out how Colin & Dave’s work affect the bounty and be more specific with what is left.

This will pose problems for porting it to RISC OS as FIQ handlers under RISC OS have traditionally been much more bare-bones.

Which is a good thing. People, please remember what the F in FIQ stands for.

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.

How does everybody else do it? Surely the options boil down to:

• Block IRQs for the duration of what you need to do and stuff the system. [hint: this is not the correct answer!]

or:

• Re-enable IRQs, deal with re-entrancy, and gracefully handle cases where you might stuff yourself. ;-)

How does everybody else do it?

There are two additional options I can think of:

1. Interrupt priority levels. Whether through hardware or software, the OS makes sure that while a certain device is being serviced any devices which have lower priority will be incapable of generating an IRQ. E.g. by temporarily masking their IRQ signal. So for the Pi, in order of lowest to highest, you’d probably have something like SD, video, VCHIQ (sound), timers, USB.
2. Interrupt threads. Instead of using regular interrupt handlers, each device has a thread which waits on a semaphore or some other synchronisation object. When the IRQ is received the kernel masks it and then signals the semaphore in order to wake up the handler thread. Upside is that your IRQ code gets itself a full thread context and can use whatever thread priority system the OS provides. Downside is that in general there’ll be extra latency due to the thread context switch that’s required, and extra latency if the thread scheduler decides not to run your thread straight away.

If I’ve read Colin’s post about correctly he doubts isochronous USB is possible on the Pi.

I doubt that it would work satisfactorily with IRQ interrupts.

It’s actually good to hear I got it wrong. Pity it sounds like it will be very difficult to do.

Sorry but I got lost in the technical details: do you guys mean it won’t be fixed and we will have broken keyboard support in Risc OS on the Pi for a long while?
It’s NOT the power supply, that’s for sure.

Sorry but I got lost in the technical details: do you guys mean it won’t be fixed and we will have broken keyboard support in Risc OS on the Pi for a long while?
It’s NOT the power supply, that’s for sure.

Some people think it’s the power supply – it may have been a factor in their case.

I have vastly improved my RPi’s performance by using a separate USB1 hub for the keyboard and mouse plugged directly into the RPi’s own socket, and, for good measure, I have followed Rick’s suggestion and used the bottom USB socket – the one nearest the board – for this, as Rick is usually right.

My powered 10 port USB2 hub, which incidentally powers the RPi, is plugged into the top socket.

Whether the USB1 hub helps in any way by being USB1, I don’t know. It just works. My problems have gone away, so I am not experimenting further.

Try it yourself and see if it helps.

The problem does not seem to affect everyone.

I wouldn’t consider that the need if using a HUB is a proper fix. I don’t have a HUB, I don’t need one, and I have different keyboards missbehaving in Risc OS on the Pi. Why should I need a HUB to use a keyboard and a mouse?

I think everyone accepts that the problem can often be the PSU.

I hope everyone now accepts that it isn’t always.

I also hope that everyone realises that some keyboards seem to be more prone to erroneous key repeats than others. Connecting via a hub improves things for some.

I expect that it will get fixed but currently no one has it on their to do soon list:-(

I wouldn’t consider that the need if using a HUB is a proper fix. I don’t have a HUB, I don’t need one, and I have different keyboards missbehaving in Risc OS on the Pi. Why should I need a HUB to use a keyboard and a mouse?

To make it work? I do apologise. I thought you were seeking a solution to your problem, whereas you are actually just having a rant at, presumably, the developers.

Tant pis! I shall waste no more time.

I agree with John Williams. If you want a solution (or just a workaround) for this issue, then upgrading the power supply or using a properly powered hub could well give you the answer. It certainly did for me.

As a workaround, nemo’s FixUpDown may help.

Possibly related to this, some code sequences on the Pi cause keyboard input to become really unresponsive. Does the Pi trigger an IRQ or FIQ when keyboard input is detected, or does the OS have to poll for keyboard input?

It’s particularly noticeable under ADFFS when games prompt for a 2nd disk and proceed to poll the filesystem to detect the disk change. Whilst in these small code loops, key presses are invariably missed. BlowPipe or Xenon2 for example both sit in a code loop of less than a dozen instructions which perform an OS_File or OS_Find and loop if the expected result isn’t correct.

From this one can surmise the bulk of the time is sat in RISC OS, which will be in SVC32, possibly with IRQ disabled and FIQ enabled. The remaining instructions in the game code will execute in User32 with IRQ/FIQ enabled.

I’ve not got RO5 IOMD support to a point where I can test these games on IOMD, so can’t pin it specifically to the Pi HAL, but I suspect that’s where the issue is.

Does the Pi trigger an IRQ or FIQ when keyboard input is detected, or does the OS have to poll for keyboard input?

The USB controller is entirely interrupt based (using IRQs under RISC OS), I don’t think there’s any polling, except perhaps for short-term stuff like checking a status flag in a loop to see if the controller has finished resetting.

I’m guessing the keyboard is FIQ based on IOMD / IOC. As it’s IRQ based, surely that means that whilst dealing with many SWI’s, IRQ aren’t going to be occurring?

Has anyone picked up switching the HAL to FIQ? I’d have a go myself if I was pointed in the right direction and hand-held on how to build the OS!

I’m guessing the keyboard is FIQ based on IOMD / IOC

No, it’s IRQ based.

As it’s IRQ based, surely that means that whilst dealing with many SWI’s, IRQ aren’t going to be occurring?

Only if the SWIs are poorly behaved and disable IRQs for long periods of time.

Has anyone picked up switching the HAL to FIQ?

What’s the HAL got to do with it? The USB driver is implemented as a module.

I’d have a go myself if I was pointed in the right direction and hand-held on how to build the OS!

I think you need your hand holding on more things than just building the OS! ;)

ROM building hand holding can be found on the wiki. The Pi USB driver sources are here.

However you’ll probably have to merge in the latest sources from the Raspberry Pi github in order to get their FIQ fix (although I remember looking at the code at one point, I don’t think I went as far as merging it into the RISC OS version).

It looks like I performed the last merge from this revision of the Pi sources, so you’ll want to download those Pi sources, download the latest Pi sources, and then use your merge tool of choice to merge any differences into the RISC OS version of the driver. And make sure you note down the revision of the new sources so it can go in the CVS checkin comment!

No, it’s IRQ based.

If that’s the case, I’m barking up the wrong tree.

What’s the HAL got to do with it? The USB driver is implemented as a module.

I mistakenly thought something as fundamental and hardware specific as USB would be implemented at HAL level!

I think you need your hand holding on more things than just building the OS! ;)

Not sure how to take a comment like that!

I think you need your hand holding on more things than just building the OS! ;)

Not sure how to take a comment like that!

I would think if you CAN’T do it, there are very few people who can. I’m sure Jeffrey’s comment was meant in jest, so please don’t be put off. It would be great to have the Pi USB fixed uuuuuuuuuuuuuup. ;)

I know he’s joking.

From Jeffrey’s description, it doesn’t sound like the problem these games are seeing is USB related anyhow. I’ll need to get Xenon 2 or BlowPipe working on IOMD RO5 to see if that too suffers the same problem, in which case it’s possibly related to the SWI’s being called and more of a fundamental OS problem. I doubt it’s this, but you never know.

Either way, it shouts “IRQ’s are disabled for too long” to me, just need to figure out where the problem is and see if it’s resolvable.

As it’s IRQ based, surely that means that whilst dealing with many SWI’s, IRQ aren’t going to be occurring?

Depends on whether or not they disable interrupts. IRQ trumps SWI.

Has anyone picked up switching the HAL to FIQ?

NO!!!

Doesn’t anybody remember what FIQ is supposed to be for? To switch the HAL to use FIQs to fix a problem reminds me of the 6502 days when people used to wire up all their stuff to NMI because they couldn’t design a low-latency interrupt handler to save their lives.

Either there is something fundamentally wrong in what RISC OS is doing, or the GPU firmware, or both because I can’t quite understand why a 700ish MHz board cannot keep up with a device that has a lower bandwidth than audio tape. Seriously, a keyboard is slow. It’s like being a Cessna in an air show…

I’d have a go myself if I was pointed in the right direction and hand-held on how to build the OS!

Your wish, my command, or something: http://www.heyrick.co.uk/blog/index.php?diary=20131105

I believe the issue on the Pi is a lack of buffering on the USB module, to work around that Linux switched from IRQ to FIQ, which resolved most of the issues. I’m no expert on it though, I’ve just been following the issue for a while.

It’s basically a software fix for a failing in the hardware design.

Your wish, my command, or something

Just what I needed, thanks.

Jon: More thoughts about USB & FIRQ on the Pi are in the thread: https://www.riscosopen.org/forum/forums/4/topics/2383

Jon: More thoughts about USB & FIRQ on the Pi are in the thread: https://www.riscosopen.org/forum/forums/4/topics/2383

Whoa! Recursion!

Deja Vu!!

A quick way to check if the issue is possibly power related is to measure the voltage between TP1 and TP2. If it’s dropping below 4.75v the PSU isn’t adequate. The official Pi PSU’s (Part# RPI-PSU-UK-MK1) certainly don’t provide enough voltage for a Pi to operate correctly.

The only reliable PSU I’ve found to date is an Apple iPad USB PSU with a short lead, the gauge of the lead is crucial, data leads simply won’t provide enough current. Again, you can quickly find out by measuring TP1/TP2, I’ve seen drops of over .5v on some leads.