RISC OS 5.28 on PI3

Somebody already mentionned the issue on RC16, which I have never used, but upgrading from 5.27 (09 Sep 2020) to 5.28 gives a “keyboard not present” in the boot window. Also on entering the desktop the buttons aren’t working properly (first click with SELECT opens a menu) till I have at least clicked each mouse button at least once.

This is an old issue that I mentionned some years back and which stopped occuring at least a year ago. Could it be that one of the commits on the USB module is missing from the release branch?

First click is working fine for me with 5.28 on a Pi 3.

‘No keyboard present – Autobooting’ is displayed during boot but I’m fairly sure that message has been around since the early Pi 1 betas. If I recall correctly, it’s looking for a PS/2 keyboard.

My Iyonix has always displayed ‘No keyboard present – Autobooting’ .
It’s caused by the USB failing to initialise the keyboard in time. My mouse & keyboard are connected via a hub.

Somebody already mentionned the issue on RC16, which I have never used, but upgrading from 5.27 (09 Sep 2020) to 5.28 gives a “keyboard not present” in the boot window.

I mentioned this in June this year.

The message was definately not displayed on a Ras Pi running the ‘latest’ 5.27 at that time.

I checked before posting.

If I recall correctly, it’s looking for a PS/2 keyboard.

1. I believe it’s just the standard keyboard message because that particular keyboard didn’t quite respond in time as mentioned by Jeff. Different keyboard may well “fix” the issue.
2. André is right, I think, because there was some work by Jeffrey to stop that on headless machines being used over VNC. His solution was to introduce a dummy keyboard.

Given the rather random way that Git commit events show in web log I’m sure a submitted item could be overlooked quite easily.

Is there a way to extract from Git the sources used to build 5.28?

Is there a way to extract from Git the sources used to build 5.28?

This is what I use on RISC OS using sgit.

dir <Obey$Dir>
set UnixEnv$sgit$sfix ""
sgit clone https://gitlab.riscosopen.org/Products/BCM2835.git BCM2835
dir BCM2835
sgit submodule init
sgit submodule update
echo finished

It takes a while.

Won’t that get 5.29?

Won’t that get 5.29?

No.

The submodule call needs the --remote switch, which sgit does not support, to get 5.29.

On Linux :-

git clone <a href="https://gitlab.riscosopen.org/Products/BCM2835">https://gitlab.riscosopen.org/Products/BCM2835</a> BCM2835Dev
cd BCM2835Dev
git submodule init
git submodule update --remote

Interesting! Thanks for the tip; I don’t personally need it now but that could be useful in the future.

I clone both on my work PC and compared 5.28 and dev (5.29) and except for the additions made in 5.29 I found no difference.

I also installed the 5.29 ROM over the 5.28 one and the problems vanished again. It is as if there is some code that behaves differently in stable and dev versions.

I said earlier :

I believe it’s just the standard keyboard message because that particular keyboard didn’t quite respond in time as mentioned by Jeff. Different keyboard may well “fix” the issue.

It is as if there is some code that behaves differently in stable and dev versions.

As mentioned by Sprow elsewhere the dev differs slightly in having the module list displayed and that takes a small amount of time, during which a slow initialising keyboard will complete its power up and be detected by the system.

So back to Jeffs comment

It’s caused by the USB failing to initialise the keyboard in time. My mouse & keyboard are connected via a hub.

Remove any USB hub in line with the keyboard and possibly even change the keyboard as well.