Analysis of VIDCBandwidthLimit
Pages: 1 2
Sprow (202) 1155 posts |
As part of scraping the limpets off the bottom of the boot sequence I figure it’s probably worth doing something about VIDCBandwidthLimit, so here’s what I know
I can’t quite decide what to do, so here are some options
Or something else? |
Jeffrey Lee (213) 6048 posts |
I’d vote for removing it altogether, and letting GraphicsV_VetMode deal with any limits. I’d also vote for removing the vidc_type variable from ScreenModes and making the module assume/require GraphicsV to be in use. I can’t think of any compelling reason for someone to want to softload our version of ScreenModes on a non-GraphicsV OS, and having pre-GraphicsV logic knocking around when I/we come to update the module to deal with multiple displays/drivers is only going to result in more headaches. |
Rick Murray (539) 13806 posts |
I concur. In the future we will want to teach RISC OS about different pixel formats (RGB vs BGR etc), I feel this would be more complicated than it should be if we have a lot of legacy code kicking around. |
Andrew Flegg (1574) 28 posts |
What’s the impact currently if Following on from Jeffrey’s point – is the revamped, tidied, sanitised |
Sprow (202) 1155 posts |
Too low, and there will be modes that can be displayed but are rejected.
That’s the idea. However, the bandwidth limit is set inside ‘Choices:Boot’ which is copied from the respective hook directory, so lower numbered hook directories can still use the command but share the rest of the boot sequence. Likewise X VIDCBandWidthLimit 1 2 3 4for dual booting would be harmless. At present, it should be universal for 3.50/3.60/3.71/4.01/4.02/4.04. You need to copy in the !System from the downloads page, and if using 4.xx you’ll need to copy the configure plugins into ‘RO400Hook.Res’ from the RO4 CD-ROM. The icons are probably a bit confused at present too. Support for 3.10 is currently lacking, some of the central assembler macros output unconditional MSR/MRS sequences which wouldn’t work on crusty ARMs. Depending on mood I might stretch to 4.39 at some point too so at least all the ROM chip versions are covered, though 4.39 might have diverged too much to be worth the bother. |
Andrew Flegg (1574) 28 posts |
The reason I ask is cos it overlaps with the purposes of MDFs on RISC OS 3.7 and above. What that means in terms of sensible architecture, I’m not sure ;-) |
Sprow (202) 1155 posts |
The command is now gone. For reference, there is a faint echo of it in the boot sequence still. Basically, for RO350/360/370/400Hook it is left in place untouched, and for RO500/510Hook I’ve just prefixed it with an ‘X’ so it doesn’t halt the boot sequence where it is no longer available. The reason it was ever needed in RISC OS 5 was because if unset the ScreenModes module uses the OS value, and the HAL based kernel sets an arbitrary value of 100MB/s. It’s also worth noting that both !Configure (pre RISC OS 3.80) and the !ScrnSetup plugin will attempt to issue ‘VIDCBandLimit’ (note – this is an alias set in PreDesk) when a new instantiation of the ScreenModes module is made to temporarily test out the selected monitor. Since both check for the alias being set before issuing this can safely be left in Configure/ScrnSetup when RO520Hook is needed – so that they continue to run on previous OS’. |
Andrew Rawnsley (492) 1443 posts |
Just had a report from a user who was trying out a new ROM, and ran into some fairly major problems because this command caused an error, and stopped any more of Predesk executing. I really think that for compatibility reasons, any removal of commands which might have previously been executed during boot (especially during predesk) should have dummy placeholders to prevent errors. As it stands, if I issue a new ROM to our users without them having first modified their !Boot, they will get errors/crashes at Boot. In the case I saw, it resulted in Fat32FS not softloading, so subsequent references to the secondary drive failed resulting in more problems. Basically, this problem is exasperated by the way errors early in PreDesk result in skipping execution of any remaining (alphabetically) entries in PreDesk. |
Martin Bazley (331) 379 posts |
…Exacerbated? I see where you’re coming from, but if this approach is taken too far, it can lead to things like the WindowUtils ROM module, which hasn’t contained any code since RISC OS 2 (it’s literally just a blanked-out header), but remains in place just in case anybody should ever want to RMEnsure it. |
Chris Evans (457) 1614 posts |
I agree with Andrew, removing it will be nightmare. Can we please have a dummy placeholder? |
Rick Murray (539) 13806 posts |
I would be inclined to say that the part I have highlighted is the part that needs to be fixed. I think we’d need a shell command interpreter that can run through the stuff in PreDesk (etc) and log its status to a file. Nothing too complex, could just be a BASIC proggy to read the files and XOS_CLI the stuff. |
Sprow (202) 1155 posts |
In this instance the error is that the person in question has upgraded their ROM but failed to make the corresponding change to the boot sequence, the boot sequence is fully backwards compatible (tested back to RISC OS 3.50 currently). Remember, RISC OS is not just a ROM (that accounts for only 1/7 of the total bytes).
Though not currently made use of, you can add a ‘-continue’ switch to the repeat command (as of boot commands 1.44) which will do as you suggest. It too carries risk, for example if a later part of the boot sequence relies on an earlier part having completed without error! |
Jeffrey Lee (213) 6048 posts |
Although it’s a nuisance for people to have to update their boot sequences, I think I’m with Sprow & Martin when it comes to removing obsolete stuff from the ROM. If it was something which third party apps relied upon (like WindowUtils) then I could see the point of keeping it around. But VIDCBandwidthLimit is something that should only be used by the boot sequence. We control the boot sequence (or at least strongly suggest what users should use as their boot sequence), so there’s no reason why we can’t make ROM changes which require the user to update their boot as well, especially if the updated boot remains backwards-compatible with old ROMs. I think part of the problem we’re facing is that there aren’t really any release notes supplied with the ROM images/disc build, so unless people constantly watch the forums or CVS they won’t know if there are any dependencies between the ROM & disc or if any special steps need taking when upgrading. This is a problem that affects anyone working with development images – regular users, budding alpha/beta testers, OS developers, etc. Likewise, there’s nowhere describing which new features are supported in a port, or which new/improved APIs have been added, etc. I’m tempted to say that the ROOL diary could fill this role, although it would also be nice to have an offline copy of the release notes within the ROM download archives (I guess the build script could just do a wget of the latest diary page?) |
nemo (145) 2529 posts |
I don’t think it is particularly onerous to keep it as a NOP. We’re not quite that short of bytes, surely. |
Chris Evans (457) 1614 posts |
In an ideal world you are correct Sprow & Jeffrey. Andrew and I though, have to live with the unideal day to day! |
Andrew Rawnsley (492) 1443 posts |
I’d normally agree with what Jeffrey and Sprow say, and their point is extremely reasonable (I have no problem rolling updated !Boot sequences out to support new OS builds), but users don’t always follow our advice, or indeed logic at all. Recently I had people installing year-old versions on new machines, because they thought they had to install every update or none-at-all! Clearly you can’t legislate for such things, but this is an instance very similar to WindowUtils in that it directly affects something very critical (and to users, very scary) – the boot sequence, which has a fundamental knock-on effect to anything after it (ie. everything). If, for example, this problem just stopped an individal app from functioning until updated, I wouldn’t bat an eyelid. But in this case, it could royally mess up users, rendering them with an almost unusable machine. There’s another scenario which may not be immediately obvious. Many users keep a “shipping backup” or “monthly backup” of !Boot in case it gets messed up, due to the importance of !Boot. Indeed, on dual-drive systems I routinely back up the whole system, just in case. If a user messes up, and then rolls back, they’re left with an unbootable system, probably without internet access (I doubt !Internet would have been run) and hence without recourse for a fix, short of me supplying a new copy through the post. Granted, some phonecall tech-support should sort them in this instance, but nevertheless, I suspect you see the point! (Tongue firmly in cheek) One wonders if the dreaded WindowUtils module could become a dummy store for such legacy commands! At least it’d then have a purpose! |
Steve Revill (20) 1361 posts |
Hang on, are you talking about users who’ve installed (parts of) an odd-numbered ROM or the work-in-progress HardDisc4 image? Maybe we need to emphasise this more on our site but you get what you’re given if you use those things. You’re expected to know what you’re doing. If you don’t, you wait for an official software release from Castle, RComp, etc. I’m afraid I don’t have an enormous amount of sympathy for users who get themselves in a pickle by using beta-quality code. These are development releases for a very good reason; so the developers have access to the nightly builds. |
Steve Revill (20) 1361 posts |
I always assumed it’s part of the job of the people building the commercial products who ‘ratify’ the even-numbered releases to think around the issues of user upgrades and reverting. As you quite rightly say, you can’t legislate for users getting themselves in a mess by installing stuff from the beta releases on the ROOL site. To that end, I’ve updated the downloads page to make it clear that the HardDisc4 images are works-in-progress. |
Steve Pampling (1551) 8155 posts |
I always assumed it’s part of the job of the people building the commercial products who ‘ratify’ the even-numbered releases to think around the issues of user upgrades and reverting. Perhaps the maintainers of the commercial products should be encouraged to tell their users to beware of development releases, unless they have taken proper precautions etc. As you quite rightly say, you can’t legislate for users getting themselves in a mess by installing stuff from the beta releases on the ROOL site. To that end, I’ve updated the downloads page to make it clear that the HardDisc4 images are works-in-progress. My use of the development releases is to see what I can break and feed the information back via these forums. |
Steve Revill (20) 1361 posts |
That’s exactly right. Having got on my high horse last night, I have to admit, I do have sympathy for Chris, Andrew, et al. Customer support can often be the most demanding and least rewarding part of selling stuff. :( |
Frederick Bambrough (1372) 837 posts |
Well the warnings aren’t exactly hidden (Oo, more bright red). I’m neither programmer nor developer (& the last thing I did write was in 6502 assembler) but then I don’t depend on my BB to run my pacemaker and I do make too many backups. Otherwise I wouldn’t play. Like to think the odd bug find helps. |
Rick Murray (539) 13806 posts |
Ouch! But quite true. The cutting edge stuff may go bang. For what it is worth; is there a mechanism to download older revisions of the nightly builds? Is a rolling rotation (say, the builds of the last week + milestone builds) retained anywhere? |
Steve Pampling (1551) 8155 posts |
Customer support is a pain. |
Steve Revill (20) 1361 posts |
Nope, sorry. Once the new ones roll in, the old ones are deleted at present. We may revisit that idea when we’re less full of RPi-related work. |
Andrew Rawnsley (492) 1443 posts |
Whilst I completely agree it is up to the likes of ourselves to ensure our upgrades are smooth an painless, it is also our responsibility to alert developers to potential problems that users could experience, and discuss the risk/reward ratio (ie. what’s the risk of problems, vs what’s the benefit). In this case, restoring a backup of their computer could potentially render the machine unbootable (or close to). I’m merely asking that developers have a think about how a safety net could be introduced in that scenario. Not in every scenario, but certainly ones that involve !boot (esp predesk). As others have stated, merely implementing the star-command with a NOOP would be perfectly sufficient. I honestly fail to see a downside to such a fix, except that purists could say “awww, but we don’t need that *command”. I may be missing something, but a *command in and of itself doesn’t take more than a few bytes does it (ie. it is just an entry in a lookup table followed by the NOOP behaviour)? To those mentioning “running betas…” you’ve entirely missed the point – this won’t always be beta. If things remain as they are, and 5.20 rolls round without this being resolved, then anyone who inadvertently has to restore their backup of the original !Boot will have a problem. It is the role of beta-testers to report such problems so they don’t happen when 5.20 is ready. Let’s give another example – your Iyonix ships with a CD containing a backup of !Boot. Your hard disc dies, so you replace it, and restore !Boot from the CD. Regardless of what OS build you’re running, you’d hope that the CD version of !Boot would still work to give a basic, bootable system which you could then update online. This is no longer the case as things stand. A 5.18 !Boot will error in Predesk (probably before !InetSetup is run) if run on 5.20 (as things stand). This is not a desirable situation if it can be avoided. |
Pages: 1 2