RO 5.22 for Pi

Is there any update on 5.22 for the Raspberry Pi? At the Wakefield show it was released for Armini, Panda etc. but were told there would be a delay in it being issued for the Pi.

Or have I missed something, I know there was once talk of “odd” numbers being “official” and “even” numbers development versions (or was it the other way round?)

thanks
Chris.

Other way around.

AIUI ROOL did not consider that the state of the Pi version good enough to be an ‘Official’ release so it jumped from 5.21 to 5.23
The next ‘official’ Pi release should be 5.24 but don’t expect it soon!

Chris overload in here :)

As far as I can tell, 5.24 won’t be out until at least next year – the current plan is to disable the “ZeroPain” module on 1/1/16 and that’ll be before the release of 5.24.

Chris overload in here :)

Just helping out, although if I got the wife to post…

As far as I can tell, 5.24 won’t be out until at least next year – the current plan is to disable the “ZeroPain” module on 1/1/16 and that’ll be before the release of 5.24.

That was my understanding of the situation. As per the Announcement: ZeroPain scheduled to cease working as soon as the date in the built ROM no longer includes the string 2015 and then a period of testing with the altered “zero page” situation with no ZeroPain module to catch the faults.

Common sense¹ would suggest that if we have about six months of ZeroPain assisted testing then another six months of final testing is a good idea.
Those who have stuff that breaks can always go back to the last ROM build before July 5th 2015² it may not have bleeding edge alterations but then it works the way it always did.

¹ Which isn’t at all common, but I will credit people round here as been less common and therefore having said sense.
² It’s archived.

Incidentally, it would be good to know if people are still seeing USB issues which they aren’t seeing in Linux, or which they aren’t seeing when using the same devices with other RISC OS machines (stuck key presses and the like). There’s a newer version of the Pi USB driver which moves a lot more of the logic into the FIQ handler that I can try integrating. If the current driver is good then that’s one less thing off the ‘Pi stable release’ todo list

Since moving to RO 5.23 (on Rpi2) I have encountered more freezes during bootup, typically just before or in the middle of the backdrop being rendered. I have a Logitech K260 wireless mouse and keyboard, working via a USB stick. I thought it might have something to do with the mouse’s battery running low, but I have had one freeze up after replacing the battery. Sorry if this is unquantified – probably not very helpful. But it was a rarer phenomenon with RO 5.21.

The latest release isn’t stable enough for me to boot, frequently hangs on dhcp (Hourglass stops, no response at all)
Not sure whether it’s USB related or not.

stuck key presses

I have seen stuck down keys or multiple characters recently, trying to rename an incoming download using NetSurf was one mistake not to make.

As far as general stability goes I abandoned my RPi2 because of apparently random freezes, the RPi1 is OK with the same disc image.

Given the price of the Pi wad how common it is (and the fact that it may be an introduction to RISC OS for many people), wouldn’t it be MUCH better to get the versibn for the Pi up to “official release” standard BEFORE moving to 5.24, with it’s associated zero page changes?

I am beginning to think that ROOL have no intention of ever making a stable version available for the Pi! Ignoring the (at least potentially) most numerous platform and making changes which will ensure that a significant proportion of existing software will no longer work, seems IMHO more likely to kill of RO5 than to improve it!

I think the concept of “stable release” is something of an anachronism given the platform has bugs and “issues” and the code is continually evolving…

The point, I believe, is to perform a freeze on the code and give it a more in depth test, fixing small quirks and removing larger problem code, in order that people should have a “known to work” release instead of the nightly builds (which may potentially fail to even boot, that’s why they are not recommended for people who just want to use their machine instead of fiddling with stuff).

For whatever reason, ROOL don’t feel that the Pi version is up to scratch yet – though I wonder if Pi’s frequent fiddling with the firmware has any influence on this?

As for the “breaking stuff”, ROOL are aware of the problems and the possibility of older software not being updated. The decision chosen will probably depend upon what “breaks” and how badly; though notice that I have put the work break in scare quotes – for standard user software (exception for the likes of Aemulor) should not be directly accessing kernel workspace. And anything that accesses &0 (or nearby) is probably trying to load from an uninitialised pointer and is, by definition, already broken. You just didn’t know it before. ;-)

I am concerned about this change as I’m not sure my preferred editor (Zap) will be fixed; I caught some pain in my own programs and actually I’m glad that ZeroPain caused them to crash spectacularly as each Pain was a bug. Hell to track down, but satisfying to finally grab the bug by the thorax and then nail the little $#!+ to the wall…

This is, ultimately, a move intended to enhance stability. We just need to experience some Pain along the way. Do be sure to use the new build and if stuff crashes and burns, try to contact the author with the relevant parts of your own ZeroPain log. The more stuff fixed before the end of the year, the fewer exception cases ROOL will need to cater for…

As for “significant proportion”, most stuff should be unaffected by this (and in my small tests, this is correct). It only really concerns software that fails to use the proper API and/or has existing bugs in memory access.

On the question re stability raised by David Gee, I’m using 5.21 dating from 12 Jan 15 on my Pi 1B. I use the Pi daily for long periods for a variety of tasks using a wide range of software both old and new (I have Aemulor) and I find it to be pretty stable, as good as or better than any previous OS version since 5.06 or thereabouts on the Iyonix. So while no doubt there are bugs to be fixed in 5.21, it is a perfectly serviceable day-to-day OS IMHO.

Just to hi-jack this thread for a moment…
Rick Please try this build of Zap as it has a lot of the zero page bugs squished. Just replace the zap module in !Zap.Code with the new one. (please rename the old one as a backup).

I used to get stuck keypresses until I replaced my power supply, then they came back a while ago (possibly in conjunction with RC14 but I can’t say that with confidence). It looks like I may need to install Raspbian and see whether I can replicate the problem there, although the intermittent nature of the problem makes it difficult to test.

Most disastrous for me is when Ctrl-K got stuck! I’ve been using the mouse for deletes since then…

Most disastrous for me is when Ctrl-K got stuck! I’ve been using the mouse for deletes since then…

Key debounce code, less than it could be?

Most disastrous for me is when Ctrl-K got stuck! I’ve been using the mouse for deletes since then…

Key debounce code, less than it could be?

For USB, key debounce is the responsibility of the device, and RISC OS’s key debounce code is disabled.

I believe stuck keys with USB are generally caused by missing microframe(s) – at regular intervals the host controller polls the devices interrupt endpoint to ask “has anything happened?”. If a key state transition has occurred since the last poll then the keyboard will send a response containing a list of all the keys that are currently down. The OS then compares that against the last state it received to generate the KeyV up/down events. Because the keyboard only sends a response when a key state has changed, if the microframe containing the “no keys are down” response goes missing then the key will remain stuck. Pressing any key on the keyboard should fix it.

Pressing any key on the keyboard should fix it.

Horrible kludge suggestion:
Generate a key event for a null key¹ at specific intervals.

I know, it won’t work because:
long list follows, including someone near here probably not knowing what he’s talking about.

For the people that get the problem, is it single key actions or key combinations that trigger things?

¹ I’m aware there isn’t an abundance of unused key codes.

bq. Pressing any key on the keyboard should fix it.

Umm, 1986 is calling, it wants its keyboard handler back.

I know, it won’t work because:

because you’d need to modify your keyboard firmware? :-) Remember that the keyboard will only send a packet if it thinks something has changed (although, it is possible that they will send packets at regular intervals while keys are held down – I haven’t actually checked the spec to see if any of what I’ve said is correct!)

I think I do sometimes get stuck keys, but I am using a wireless keyboard+trackball, so it’s possible the problems I’m seeing are down to the wireless link or the batteries being loose (or flat) rather than the Pi. I should probably pay more attention!

I’ve had stuck keys on the Pi too—mine is a CJE Raspberry Ro so should not be a power supply issue. I don’t get this very often—but I never get it with Linux on the Pi.

I’ve sometimes encountered the same issue with RO4.02/Red Squirrel, but VRPC/RO 4.39 is fine.

because you’d need to modify your keyboard firmware? :-) Remember that the keyboard will only send a packet if it thinks something has changed

I was thinking of generating a pseudo keypress event, as opposed to having the keyboard generate an event from a keypress.

I think I do sometimes get stuck keys, but I am using a wireless keyboard+trackball, so it’s possible the problems I’m seeing are down to the wireless link.

Bluetooth frequency range IIRC, great for interference from microwave ovens with naff supression, DECT phones (generally crap), wireless doorbells, keyfob car locks (we got random doorbell events from that)…

Would it be fair to say that the RPi 1(B) is more stable than the RPi 2 at the moment, then?

My keypress issues are occurring on a 1 (B+); I don’t own a 2. I haven’t had a chance to try Raspbian yet.

I still get daily keyboard issues even when powering the keyboard and mouse through a powered USB hub, I can’t say I’ve ever had a problem under Raspbian.

I still get daily keyboard issues even when powering the keyboard and mouse through a powered USB hub

In my last posting (elsewhere; csa) on this subject I mentioned that I have my kbd and mouse connected to the RPi directly via a simple hub, having my other peripherals connected via a second powered hub, but what I failed to emphasise/mention there was that this hub has a very short lead (it’s from a kit-in-a-case of connection leads and basic peripherals), and that it’s probably an original USB1 hub, as it’s unmarked.

And my problems have gone away.

Hope that helps somebody!