USB Bounty

I’ve been following the work Colin and Dave have been doing on the USB system with interest. It seems to me that between them they’ve achieved some or all of the USB Bounty goals at least. The actual specification here is a little vague, though, so I’d be interested to know:

- Should we class this Bounty as being fulfilled, and release the cash to Colin, Dave and others who’ve done work on the USB system (Jeffrey Lee? Perhaps others?)
- Would it be worth coming up with a more precise USB Bounty Step 2 (as with the File system improvements), to set out future work? It might be useful to have a fairly detailed statement on what, if anything, needs doing to complete work on the USB system.

If Colin, Dave and the others are not interested in the money (as I believe they may have indicated before, though I could be wrong), would it be worth either rolling over the current cash into a Step 2 Bounty, or perhaps allocating it to another topic? I’m thinking of ways to up the figures in the File System Bounty 2, for example.

Just some thoughts. Feel free to disregard, but it might be nice to recognise all the hard work that’s gone into the improvements.

Sorry Chris they returned my code.

IIRC, you said it was returned to you unopened. As others pointed out at the time, this makes it very likely that it never even reached ROOL at all.

If Colin, Dave and the others are not interested in the money (as I believe they may have indicated before, though I could be wrong)

When I last wrote anything on the subject, the situation was that Colin had made the isochronous transfer mode work (something I wanted to do several years ago, but failed). I hadn’t contributed any code. The only contribution I had made was to keep asking questions; from this at least some of the answers came out, for which I’m very happy. Also I had tested Colin’s code and helped him find his last bug.

So, at that stage, I would have considered myself a fraud to have claimed any significant part of the bounty.

I’m now working hard (obsessively?) on a USBAudio module, which, I hope, will make it easier for application writers to see what devices are there, what facilities they offer, and use the available controls. Once this is done to a reasonable state, I will consider myself to have contributed something worthwhile. Then, if an appropriate bounty is available, I would be happy to accept some of it.

I’m now working hard (obsessively?) on a USBAudio module, which, I hope, will make it easier for application writers to see what devices are there, what facilities they offer, and use the available controls. Once this is done to a reasonable state, I will consider myself to have contributed something worthwhile. Then, if an appropriate bounty is available, I would be happy to accept some of it.

In line with what I said on an earlier occasion: I’m quite happy to let you and Colin discuss how you’d wish to divvy up the prize I’ve offerred. Although in the event of a failure ¹ to agree I’d probably make it a 50:50 split. (ahem) Purely to make the maths easier I’ll increase the amount to 400 quid, regardless. Should help you both toward getting a good USB DAC.:-)

¹ The term ‘failure’ here would include the case where you both were saying “No, give more/it to him, not me!” :-)

Jim

It may help if I give you my assessment of the state of USB on RISC OS. It’ll give an idea of the work to be done.

I see USB layed out like this. If anyone disagrees with this – most likely Jeffrey Lee – feel free to enlighten me.

                            RISC OS USB

+-------------+    +----------+
| SCSISoftUSB |    | EtherUSB |
+-------------+    +----------+
        |               |
        +---------------+
            +-----------|------------------------------------------+
            |           |    USBDriver                             |
            |   +----------+   +----------+   +-------+  +-----+   |
            |   |DeviceFS  |   | Keyboard |   | Mouse |  | Hub |   |
            |   |Interface |   +----------+   +-------+  +-----+   |
            |   +----------+                                       |
            |            Device Management                         |
            |                                                      |
            +------------------------------------------------------+ 
                                |
    +---------------------------+------------------------+
    |                   |               |                |
+------------+   +------------+   +-----------+   +------------+
| OHCIDriver |   | EHCIDriver |   | DWCDriver |   | MUSBDriver |
+------------+   +------------+   +-----------+   +------------+

  Iyonix            Iyonix        Raspberry Pi      OMAP3
                    OMAP3                           OMAP3Live
                    OMAP4

                   Controller Drivers  
                    
OHCIDriver - Fully implemented
EHCIDriver - Fully implemented except for USB1 isochronous devices
             plugged into a USB2 hub.
DWCDriver  - Doesn't support isochronous.
MUSBDriver - Doesn't support isochronous.

I’ve fixed bugs in DeviceFS – external to USB – so at least the DeviceFS interface is working as it should. Those fixes were included in RO5.20. I’m modifying USBDriver and have isochronous USB working. I haven’t implemented all isochronous modes – which are easy enough to add – as I’m in 2 minds as to whether they belong in the USBDriver.

Getting isochronous working in USBDriver doesn’t mean that isochronous works everywhere. That depends on whether the individual controller drivers support isochronous. Which controller drivers you have depends on your machine. If you look at the diagram the Iyonix uses OHCIDriver and EHCIDriver so will handle both USB1 and USB2 isochronous transfers – though USB2 is untested. It won’t handle USB1 isochronous plugged into a USB2 hub.

Unfortunately Audio devices tend to be USB1 which means at present they only work on an iyonix.

The EHCIDriver is the latest from NetBSD so for it to support USB1 transfers someone needs to write the support for split transactions needed.

I haven’t looked into DWCDriver and MUSBDriver – I don’t have a machine that uses them – other than to see if they support isochronous. It may be that the inability to test it was a factor in not supporting isochronous and the code the driver is ported from supports isochronous. If this is the case then with my usbdriver it can now be tested.

In the absence of a mad rush to update the individual controller drivers I may get around to having a go at the EHCIDriver but feel free to DIY :-)

Just to clarify things ROOL don’t have my USBDriver changes.

So, having taken a look at the original wording again, in the light of this should we count the Bounty as being satisfied once:

- The EHCIDriver supports isochronous USB1 from a USB2 hub;
- DWCDriver and MUSBDriver support isochronous USB;
- The modified USBDriver has been submitted, tested and incorporated by ROOL?

I’m not sure how much extra work that is, nor how the money would be divided up exactly, but any thoughts on whether it’s a sensible milestone to mark?

AIUI the USB Audio Bounty is a different project, and I guess that would be up to Jim and contributors to decide when it’s complete and how to disburse any funds.

AIUI the USB Audio Bounty is a different project, and I guess that would be up to Jim and contributors to decide when it’s complete and how to disburse any funds.

Nominally, its a ‘prize’ rather than a ‘bounty’ for various reasons. FWIW The original terms were as shown on

http://jcgl.orpheusweb.co.uk/ROAudioPrize.html

but I’m happy to flex that in various ways. e.g. I’ve already extended the old deadline and upped the amount! I’m basically happy to award it when I get the code/modules/whatever that lets me drive a modern USB DAC like the DACMagics, etc, on my ARMiniX and people seem happy it will also be workable with other RO hardware. I’ll test this by its ability to play the audio OK. Happy to explain / discuss / vary this if people raise it with me.

Jim

I see USB layed out like this. If anyone disagrees with this – most likely Jeffrey Lee – feel free to enlighten me.

That looks accurate to me.

The EHCIDriver is the latest from NetBSD so for it to support USB1 transfers someone needs to write the support for split transactions needed.

“Latest” in only so much as it’s what was latest a couple of years ago when I updated USBDriver & EHCIDriver. I’m sure that by now it’s woefully out of date again.

I haven’t looked into DWCDriver and MUSBDriver – I don’t have a machine that uses them – other than to see if they support isochronous. It may be that the inability to test it was a factor in not supporting isochronous and the code the driver is ported from supports isochronous. If this is the case then with my usbdriver it can now be tested.

Yes, without having any isochronous devices/device drivers to test with I decided it was best to skip trying to implement isochronous support for DWCDriver & MUSBDriver. Once we have a relatively stable USB audio driver I can probably be persuaded to have a go at getting isochronous working properly with all the USB host controller drivers (i.e. DWCDriver, MUSBDriver, and EHCI USB1). But that’s likely to be several months down the line, as I’m still knee-deep in GraphicsV and SpriteExtend.

“Latest” in only so much as it’s what was latest a couple of years ago when I updated USBDriver & EHCIDriver. I’m sure that by now it’s woefully out of date again.

Looking at the NetBSD cvs update logs for ehci.c it seems to me little has changed. I wouldn’t make it top priority, it still doesn’t support full/low speed isochronous transaction translation.

Hi all. Just a quick update to say that we re-opened the USB bounty to give everyone a chance to make it happen.

I think DavidS ran into some problems shipping documents to ROOL but I have to say nothing ever arrived at our end. Realistically, we need code submissions in electronic format so that we can build, test and review them as quickly and efficiently as possible.

So Colin no longer has this? Ok news to me.

I never claimed the bounty. It’s not worth the hassle. Whilst I understand the ’I’ve paid something so want to know what is happening brigade’ I wouldn’t want to deal with them. For me the USB bounty is all wrong. USB is never going to be ‘fixed’ its constantly evolving. It should be looked at from the other direction ie you want etherusb to work better on the pi have a bounty to do it. That may involve improving other parts of the usb stack to get it to work so the usb stack gets updated by stealth.

Hi Colin. If you have an alternative description of what you think the USB bounty should say, we’d love to hear it. Clearly, it’s been rumbling along for a while and the bounty doesn’t have to be set in stone; really all everyone wants is for USB to be a) faster b) more reliable and c) support more peripherals. :) So the trick will be trying to describe an achievable package of work which moves us a reasonable way towards as many of those goals as possible.

Its obvious the job of bringing all of USB up to date for all machines is beyond 1 person in a reasonable time scale so it needs breaking up to managable chunks.

Part of the problem is the proliferation of new hardware. To port a new computer a HAL is written and to get the keyboard and mouse working a ‘minimal’ USB controller driver is added but it appears to end there. The USB controller driver isn’t brought up to standard.

The controller drivers – OHCIDriver, EHCIDriver, DWCDriver, MUSBDriver could each be given their own bounty as each is a self contained project and dependant on the machine you have. Each driver needs bringing up to their relevant USB Standard.

OHCIDriver is fully compliant with USB1 so should only require updating from the latest NetBSD sources to fix bugs.

EHCIDriver needs updating from NetBSD sources for bug fixes and full-speed isochronous support adding to it to make if fully USB2 compliant.

DWCDriver needs making fully USB2 compliant – mainly adding high and full speed Isochonous support

MUSBDriver needs making fully USB2 compliant – mainly adding high and full speed Isochonous support

Then there is the USBDriver which contains the programmers API for writing the device drivers – which is what I’m working with at the moment.

Doing all this will make what USB device drivers we have work across all machines and give device driver programmers a wider base for their efforts.

And that I think should be the extent of the USB Bounty. With all of the above working all USB1/2 devices will ‘just’ need individual drivers which will work on all machines.

SCSISoftUSB, EtherUSB, USBKeyboard and USBmouse are clients of USBDriver. And as such deserve a bounty of their own as and when required as much as !Paint does. Just because Paint needs updating you wouldn’t say update Draw in the same bounty

a) faster b) more reliable and c) support more peripherals

a) faster than what? a mouse, hard disk, everything? Do you not pay someone for not being fast enough?

b) more reliable. I’d like to write the perfect program, I’d like to fix all bugs but I don’t delude myself that I can do either :-)

c) hopefully adding a new API to USBDriver will give an alternative to DeviceFS will help solve problems people are having writing drivers.

If you have an alternative description of what you think the USB bounty should say, we’d love to hear it.

Steve (et al) I rather think that the underlying problem is that:
As it stands, the people that know enough to do anything are doing it because they want to do it. In some respects they feel that taking a payment for their hobby activity is wrong. At the same time some of them need some money to buy “bits” however knowing the financial constraints they don’t want to ask.

Maybe the whole setup needs a turn around with a set of people given small authority to administer/co-ordinate small aspects of development with authorisation to request payment for enabling items.
The current system strikes me as being designed from the point of view of an organisation that has money and is looking to decide where to spend it rather than looking at the other version of looking at what you want to do and figuring out what you can do with a available money(or volunteer capital)¹

Vague? Yes, deliberately to avoid prescriptive stultification of other ideas

¹ Sorry, maybe something of a rant, but the thing is I’ve been involved with volunteer organisations for over 30³ years and along the way, general experience, in training sessions and working with the various personalities², I learned that the volunteers have far more capital than either they or they or many “officials” realise.
This may not be the only time I say this, but ROOL need to loosen up the shackles. There are people outside the ROOL tight group that have the skills needed but they aren’t being used to the Max or possibly at all.

² Fact: if you can successfully organise volunteers herding cats is pretty easy

³ Er, yeah, commented to the wife about this quoted the stuff above and she pointed out that it is actually over 30 years of volunteer management.

Steve (et al) I rather think that the underlying problem is that:

I’m hesitant to wade into a general pontificating as any kind of system is better than none, and I have basically zero time to do any coding these days, but here’s 2p…

I think Steve P has a point in that bounties need to be matched to volunteers, not the other way around.

I tend to work on two models: either it’s a major time-consuming project, in which case I’ll think carefully about it, or it’ll be a neat thing that sounds like a good idea for a couple of hours on a wet Sunday afternoon, which is basically time that comes for free because I would have been fixing the car (or whatever) if it wasn’t raining.

The What do people want from RISC OS 6 thread that Martin Bazley started in comp.sys.acorn.misc the other day is interesting, because the feature list that came out of it has some fairly minor things on it. Some of those would be easy to pick up and do as short one-day tasks.

I’d suggest a bit more promotion of the smaller tasks rather than the larger ones, to get more people involved. To pick one of the RISC OS 6 examples, how complicated would it be to implement numerical sort in the Filer? I suspect not very. Implement it and claim £10. After claiming that one, you’d be in a better position to make more significant Filer changes – implement toolbars, for example.

This is way of getting people more involved by focusing their energies on tasks that need to be done, rather than just doing what interests them (and nobody else). A similar idea would be to attach microbounties to particular bug reports that want fixing. It isn’t really about the money as such, merely a listing of what’s deemed to be important to the community.

This is more admin overhead which is a pain, but I’d suggest that the decision of whoever commits the code is final. Code included, bounty pays out. If there’s a major clash, paying out two lots of £10 isn’t going to break the bank.

I think for many people time is in short supply. So not many people can present a project plan with goals and deliverables if all their free time is wet Sunday afternoons. So try to get the small jobs done and the large jobs might eventually follow… this is how wikis work.

The other deficit is skills, and we’ve been traditionally poor at developing them. That’s where I’d suggest microbounties might come in handy for training people up who might later take on larger tasks.

Good suggestions, guys. We don’t want the bounty scheme to be inflexible or unchanging. Next time we review things, I’ll make sure these comments are part of the discussion. Who knows, we might be able to roll out Bounty Scheme Mk.II. In some ways I’m reluctant to open the scheme up to lots of little tasks because a) they don’t really move the OS forward and b) they dilute our already small pool of donations meaning the bigger jobs are even less likely to see the light of day. However, I agree there’s merit in leading people gently into the process of doing larger tasks by starting off with smaller, simpler problems. But are those the sorts of developers who are ever going to be at the requisite skill level to tackle the bigger issues?

It’s an interesting question. And I’m not the sole arbiter for how the bounty scheme should be implemented – we really do listen to you all and the other ROOL guys are more than happy to shoot me down when I’m wrong!

Just to explain a bit about way we chose to do things the way we have up to now, it was based upon what the people in Amiga-land seem to have been doing quite successfully. The idea is to allow tasks to accumulate donations until a developer thinks there’s enough there to make it worth doing. I concede that doing things this way around assumes that we’ve got an decent-sized pool of donors.

I don’t know the relative size of the Amiga vs RISC OS communities, but it looks like a lot more cash it going into their scheme – one of their bounties accrued over 6000 EUR, another nearly 3000 EUR. Those are the sorts of figures many of the hard tasks done.

In some ways I’m reluctant to open the scheme up to lots of little tasks because a) they don’t really move the OS forward and b) they dilute our already small pool of donations meaning the bigger jobs are even less likely to see the light of day.

I was rather thinking that some of the smaller tasks could be done by volunteer labour.
As Theo says those smaller tasks could make good training items for people who haven’t done such things before.

I was rather thinking that some of the smaller tasks could be done by volunteer labour.

Everything is done by volunteer labour.

Everything is done by volunteer labour.

Er, yes, that I know. What I meant was “unpaid and not expecting to claim a bounty” labour.

I work¹ at the Great British Beer Festival each year and put in hours that probably don’t fit with the Working Time Directive. I pay for own accommodation, the food is subsidised but paid for and like the other volunteers in general I don’t drink a great deal². At the end of the 14 days my feet ache and may have blisters³ Why do I do it? Because I want to, which is why the 1000 other people working on it turn up. If people had to be paid to that stuff it would never happen.

The latter is where I’m coming from – ALL the RO work I’ve seen done has been done by people who wanted to do it, not because they could get some cash. People seem to be losing sight of the purpose of the bounty cash: to cover out of pocket expenses where people are spending to do the testing.
In various cases (most cases?) people are spending their own money on that as well.

The thing is to plan on the basis that you get free labour and then parcel out the tasks as the labour appears rather than waiting for the cash to rise to a level that might generate an interest.

Unless of course someone knows of a multi-millionaire desperate to pour in funds to pay programmers to do the work.

¹ Far harder physically than at any other time in the year.
² Most of us tend to drink out at pubs at the beginning and end of the whole event despite free stuff on site. It’s a culture thing rather than an available payment in kind thing.
³ Concrete floors are evil

Unless of course someone knows of a multi-millionaire desperate to pour in funds to pay programmers to do the work.

I gathered that’s something we’re waiting for. No sign of him/her yet though…

Perhaps a (completely hypothetical, and commercial) killer app would generate enough sales for some of the profit to be directed towards further OS improvement; this could in turn encourage those using such a killer app to also use RISC OS for other means.

I was rather thinking that some of the smaller tasks could be done by volunteer labour. As Theo says those smaller tasks could make good training items for people who haven’t done such things before.

So if the theory is that there are N people (where N is greater than zero) who want to help but don’t know where to start, perhaps we need a wiki page/section to provide a list of tasks and to guide people through getting involved? The main wiki page has a beginner’s guide for new users, but there’s no clearly labelled beginner’s guide for new contributors.

There are also several places on the wiki containing todo lists, but no one place collecting them all together:

• The status pages for each hardware port have todo lists of varying length (OMAP3, OMAP4, IOMD, Tungsten, Pi)
• RISC OS Roadmap
• Kernel todo list
• HAL TODO
• The bug tracker, bugs forum, and wishlist forum are also a good source of tasks

Of course not all of the above are small tasks, so it might make sense to have a page dedicated to just small, interesting/fun tasks that are good for a beginner.

Yep. What you said+

so it might make sense to have a page dedicated to just small, interesting/fun tasks that are good for a beginner.

If they are small enough, the fact that more than one person might attempt them (assuming no co-ordinating person in current working “staff”) is just work based learning and small duplication.

Of course if people want to ensure no duplication then you’re looking at someone spending time managing the new volunteers.

Of course if people want to ensure no duplication then you’re looking at someone spending time managing the new volunteers.

Or people could just mark them as claimed when they start work on them.

Or people could just mark them as claimed when they start work on them.

Assuming there is a simple to use system for such things.

Well I was thinking along the lines of all the tasks being listed (or at least linked from) a wiki page. If a programmer can’t work out how to edit a wiki page (or post a comment in a forum thread or bug ticket) then I’m not sure if I’d trust them to work on the OS!