Slashdot Mirror

← Back to Stories (view on slashdot.org)

'Open Funding' For Driver Development

Posted by timothy on from the how-about-kernel-drivers-for-usb-802.11 dept.

Doc Ruby writes "The TreoCentral community has announced a bounty for the first BlueTooth SDIO driver delivered for the Treo 600 (PalmOS 5). The thread shows the development of both the requirements of the quarry, and the contributions to the bounty. If this process works, is 'open funding' of development the next wave of the emerging online community? How will the 'traditional' vision/scope> requirements> features> >recode> retest> demo> cycle expand to include the user community in the financing?" Update: 06/16 19:43 GMT by T : Updated the bounty link to a server better able to handle it.

5 of 100 comments (clear)

  1. This is not the first time for Palm Os by jomas1 · · Score: 4, Informative

    Cliesource.com had created a contest for the development of a compact flash driver for the Sony Clie line. Some developers said that Cliesource did not give developers enough time to develop a working driver but the contest did help getting a working driver into circulation.

    --
    http://nyamenation.org/
  2. Better link by braindead · · Score: 5, Informative

    There's a more readable version of the story on treocentral's stories page

  3. Already tried... by Anonymous Coward · · Score: 5, Informative

    Remember SourceXchange? Remember CoSource?

    They occurred during the height of the .COM madness, and have since gone the way of the do-do. I was involved with one SourceXchange project and they had the most robust/complete bidding process of the two.

    I remember that CoSource had trouble attracting people to bid on projects. There were a number of interesting ideas, but little money.

    With SourceXchange the typical project was a semi-large idea with semi-real funding from somewhere (in my case it was Ricoh's research lab). I participated as an expert/reviewer and the coder-guy received only $10,000 or so for a whole lotta work. Not a good hourly rate if you ask me.

    - David

  4. Great idea but.... by WareW01f · · Score: 5, Informative

    It's not bloody likely. On two counts. The first being that the Treo 600 may not be compatable. I chased down individuals at the last PalmSource and tried to get to the bottom of why the 802.11 SD drivers where not being released. The main answer was that on some devices, the card would draw too much power (802.11 suck current, fancy that!) and could even fry the unit. ouch!

    The second is more political than anything else. Starting with OS 5.0 (and someone correct me if I'm wrong) the drivers aren't as easy to hack, the least of which is that they have to be in native ARM (as opposed to the PACE layer) Hell Armlets^H^H^H^H^H^H^H PNO's where like pulling teeth to write till resently). Things get worse in OS 6.0/Cobalt where the vendor can choose (and PalmOne will, if they ever release a Cobalt device) to require the drivers be signed in order to run. Great for preventing viruses, sucks for hackers such as myself that might want to hack on a device that I may not care to sell/commit to developer fees that may apply.

    And all this before reverse engineering the card itself. Better off to wait and hope that PalmOne releases a Treo with Bluetooth built in (nudge, wink)

    That aside, no hurt in trying!

  5. The odd thing... by Fnkmaster · · Score: 5, Informative
    I started mildly hacking on this very project about 2 days ago because I was so frustrated by my Treo 600's lack of Bluetooth, when the SDIO Bluetooth cards are right there for a reasonable price, but PalmOne refuses to release OS 5 driver support to avoid cannabalizing sales of their precious high-end OS 5 PDAs with integrated BT. The best starting point I found was this guy's site. Which prompted me to download the bluetooth drivers I could find from PalmSource and the remnants of the PluggedIn program from PalmOne. This segregation of Palm into a hardware and OS company has made it mighty difficult to even get decent developer information these days.


    Anyway, it sounds like Peter Easton at Whizoo has already suggested a starting point - rip the BT drivers from the Tungsten|T and rewrite the Palm OS 4 SD-BT transport layer PRC for ARM/OS 5. If all this driver does is receive calls from the main BT driver and dispatch calls/receive callbacks to/from the documented SD API, then perhaps it's not too difficult to rip it apart and figure out what it's doing and rewrite it? That's a big if of course. I've never really reverse engineered a Palm app myself, though I've done a decent amount of Palm OS programming (games and apps).


    But apparently IDA Pro supports Palm OS and M68k, so that might provide a reasonable route to disassembling the OS 4 transport layer PRC. Anyway, that's about as far as I've gotten with this - if anybody is interested, let me know, I do have some free time right now and I wouldn't mind putting it into solving this rather annoying problem (no, I don't really give a hoot about the bounty, but I'm going to go contribute 50 bucks to it anyway - I'd pay 100 bucks right now just for a copy of a BT driver that let me use my damn Treo 600).