Pi missing keypresses

this topic is about fixing USB mouse/keyboard sensitivity to low voltage on riscos.

This is really fascinating to me. How does your software affect the sensitivity to low voltage?

I’m not casting doubt on your work, but I really want to understand the mechanism involved.

It bypasses the low voltage problem.

As I understand it the DWC USB chip has buggy periodic transfers used for interrupt/isochronous endpoints something to do with chip interrupts not happening at the correct time or being missed. This results in interupt transfers being discarded which means you miss a keyup or keydown event for example. This problem gets worse at lower voltages. The fix moves interrupt low and full speed split transactions over to the non periodic (bulk/control transfers) part of the chip which is bug free – there’s never a problem with bulk/control transfers. I just found the fix in the code and enabled it. How someone thought to emulate a split transaction interrupt transfer using a split transaction control transfer I’ll never know – some people are just clever.

What was Isambard Brunel supposed to have said – about standing on the shoulders of a clever man :-)

What was Isambard Brunel supposed to have said – about standing on the shoulders of a clever man :-)

I think that was Issac Newton

think that was Issac Newton

It was Isaac Newton, and the phrase was If I have seen further, it is by standing upon the shoulders of giants

It was Isaac Newton, and the phrase was If I have seen further, it is by standing upon the shoulders of giants

However, Isaac wasn’t the first to say it. It was a commonplace and it was expected of anyone who made “a giant leap for mankind” to express the sentiment.

I have never seen the yellow under-voltage symbol before on my other Raspberry-Pis which are R-Pis 1, B, B+ or 2 using the same power adaptor as I used on the R-Pi3 inside my Pi-Top. So, is the under-voltage warning more likely to occur with the R-Pi3?

but it works fine with cheap usbaudio devices (44100/48000 16bit)

It turns out that with the fix my better usbaudio dac works in USB 1 (class 1) mode ie up to 96000 24bit. Previously the dac was unusable on my pi b+. It still doesn’t work properly in USB 2 (class 2) mode.

@collin: Since your fix has TOTALLY changed the game for me, I am worried it gets lost. It should be part of the stable 5.24 ROM: without it, Risc OS on the Pi is just broken…
So, are you a ROM developer or will you somehow put this “upstream”, please?

It should be part of the stable 5.24 ROM:

That’s not the way it works. 5.24 is 5.24 and is a static and known state item, any fix is submitted (I believe Colin has done that) and can be added to the 5.25 beta to be more extensively tested by all the people using the 5.25 images.

That’s not the way it works. 5.24 is 5.24 and is a static and known state item, any fix is submitted (I believe Colin has done that) and can be added to the 5.25 beta to be more extensively tested by all the people using the 5.25 images.

If could not be any other way.

But, perhaps we may see 5.26 earlier than April 2019?

It cannot be in 5.24, but it could be provided in a 5.24-updated-HD-image-for-softload part. Just as in the good(?) old Acorn days.

It cannot be in 5.24, but it could be provided in a 5.24-updated-HD-image-for-softload part. Just as in the good(?) old Acorn days.

It could even be put into a component loaded from the “disc” as part of a bundle of such items collectively known as “the rom image” of course it would need to be made distinct from the older 5.24 image as released so it could be labelled as RO5.25beta – how does that sound as an idea?

It could even be put into a component loaded from the “disc” as part of a bundle of such items collectively known as “the rom image” of course it would need to be made distinct from the older 5.24 image as released so it could be labelled as RO5.25beta – how does that sound as an idea?

It sounds a lot worse than fixing known bugs in a known-should-be-stable version. Instead of shipping a bunch of changes consisting of bugfixes, changes and new features, all possibly leading to new bugs (aka “risk of change”).

Getting RISC OS again into Noobs image will need a proper release version, IIRC. 5.25 will not cut it. Another reason ot provide important fixes as separate softloads replacing only minimal parts of the otherwise stable ROM.

Another reason to provide important fixes as separate softloads

Or indeed, ROMPatch as standard. (And I’m not sure why the fixes should have to be separate)

And I’m not sure why the fixes should have to be separate

“Separate” as in “not only available as part of a complete new ROM”.

it would need to be made distinct from the older 5.24 image as released so it could be labelled as RO5.25beta – how does that sound as an idea?

That sounds like you haven’t understood what’s being asked for. I think Steffen is suggesting that the stable release 5.24 could have a bug fix released for it, which would mean that everything else in 5.24 stayed the same and was still classed as stable. The daily build of 5.25Beta is just that, Beta, and could(will?) have any number of other things broken in it.

I’ve been following this discussion with interest, and am now using the 5.25 beta with Colin’s modification in it.

But what I don’t follow is discussion of patches etcetera. Is not having a stable 5.24 with Colin’s improvements as well merely a matter of RMLoading his USBDriver module to replace the earlier version in the 5.24 ROM image? Isn’t that what the RISC OS module system is for?

Unless I am totally misunderstanding things, does this not provide the three things needed? A set-in-stone versioned stable version, an even better version with better USB by simply updating a module for those that need it, and the ongoing beta version with all its improvements and shortcomings.

Which bit have I misunderstood?

Since it seems – this effects only the ‘Pi’ what about calling the updated ROM file 5.24a?

That sounds like you haven’t understood what’s being asked for. I think Steffen is suggesting that the stable release 5.24 could have a bug fix released for it, which would mean that everything else in 5.24 stayed the same and was still classed as stable.

No, I think everyone suggesting altering the 5.24 image has misunderstood the ROOL definition of stable

Please read the second paragraph carefully.

The daily build of 5.25Beta is just that, Beta, and could(will?) have any number of other things broken in it.

As could the 5.24 stable. There is nothing stopping a user choosing a specific date version of 5.25 and remaining on that as their own “5.24+a bit” or perhaps “5.24u” (for USB fix)

I tested Colin’s ROM because I have some button initial state issues with 5.24, like menus opening on the first SELECT click, which are resolved after I click at least once on every mouse button.

The ROM doesn’t solve it (it seems to me like an initialisation issue as it worked fine with a 5.23 from August 2017) but I suffered the PI3 Shutdown issue with that ROM. Was the issue causing it disabled only in 5.24, not in the 5.25 development branch?

Come to think about it I have seen that about twice having never seen it before it coinsided with me updating to the latest loader files and I put it down to that – I’ve been using old files for a long time and wondered if the latest loader files would help keypress problems.

It appears that my rom has bmcvideo 0.50 (06 Apr 2018) and the 5.24 rom has 0.50, 1.50.2.1 (18 Apr 2018) which disables the gamma table. Don’t know why my ROM which was downloaded using cvs on the 22 Apr didn’t download that version of the module.

It turns out that I downloaded the rom from the BCM2835Dev product file which fetched the HEAD version of BCMVideo. The BCM2835 product file which is 5.24 fetches a version with the gamma table disabled.

At least you know that disabling the gamma table fixes the problem.

it seems to me like an initialisation issue as it worked fine with a 5.23 from August 2017

It looks like another instance of moving the USBDriver so that it is intialised earlier causing problems to me. Does *rmreinit usbdriver in predesk fix the problem?

There is nothing stopping a user choosing a specific date version of 5.25 and remaining on that as their own “5.24+a bit” or perhaps “5.24u” (for USB fix)

For a new user coming up against the missing key presses problem today, how would they choose, for example, last Thursday’s version of the ROM? They only date they can choose is ‘today’.

It doesn’t seem unreasonable to offer a download which they can use to patch their ‘stable’ version of RISC OS 5.24 to make their Pi usable without incorporating any of the other changes etc. which may have occurred since RO5.24, especially since the next stable release could be heaven knows when and the 5.25beta versions between now and then could break any number of previously ‘stable’ components. Most users, and in particular new users, don’t want to be a beta tester for new features, they just want to have a working system.