Asking Canon to release their source code

[RaduP]

I was wondering, did anyone attempt to contact Canon about releasing their firmware code, or at the very least some more specifications, so that people can spend more time on developing additional features, rather than hacking the existing firmware?
Now, I am pretty sure the answer will be negative (or no answer at all), but if we start some petition, and get a lot of support, who knows, they might eventually realize that having a series of camers where people can write their own firmware might give them a competitive advantage in the P&S market.
Some companies, after enough public pressure, did release some of their proprietary code, especially stuff like drivers for Linux.

[DataGhost]

... So other companies can go ahead and see what's the magic stuff that makes Canon cameras work and possibly use it (build a cheap camera, put Canon firmware on it and sell them as 'Canon' without having to invest in software)
... So other companies can reverse the flash protocol to create products to compete with the Speedlite flashes
... So other companies won't have to pay Canon for whatever informatin they might need

I think the fact that the firmware update files are actually encrypted (instead of just packed or whatever) says enough. Also, as you may have noticed, they seem to have changed the encryption method in the DryOS- and again in the newer DSLR cameras.

Oh and Linux drivers are something completely different than firmware code. I think they *might* want to share some datasheets or whatever describes the camera's inner workings in order to create a complete open-source camera firmware from scratch, but I even doubt that very much (and it'd take a LOT of time to build something like that).

[RaduP]

I am assuming that a lot of the 'magic' actually happens in the hardware, not in the software.
So releasing some of the specifications and the code that just calls the hardware functions to do its stuff can't really hurt them too much.

And the Linux drivers are not that different than a firmware code. They both contain sensitive stuff, which is why ATI and Nvidia are a little bit reluctant to open source their drivers. However, ATI is moving in this direction, and they are helping the developers of the OSS drivers.

P.S. If the chinese people want actually 'compete' with Canon, I am sure they have the resources to reverse engineer their software and hardware as well, it's not like some firmware encryption can stop them.

[acseven]

I don't think this to be a wise move.

[dzsemx]

a hardware documentation would be great... we could make our CHDKOS

[RaduP]

I don't think this to be a wise move.

Can you please explain why you think so?

Personally, I do not think it is an unreasonable request to ask for some sort of SDK, or at least the specs list. There are companies who do open source their drivers, and in some cases colaborate with the developers for alternate firmware. Compaq/HP for example even sponsored a community project to port a Linux version on their PDAs.
Some companies use OS software on their devices (Asus with EEE PC, Google and other companies with Android, and so on).

Of course, the most likely answer from Canon would be a no (or no answer at all), but what can people lose by trying?

[DataGhost]

I am assuming that a lot of the 'magic' actually happens in the hardware, not in the software.
So releasing some of the specifications and the code that just calls the hardware functions to do its stuff can't really hurt them too much.

The stuff that happens in hardware also needs to be coded... something which likely happens in firmware. I've seen some things happen that are probably handled by other chips in the camera (0xC0200000 memory area for example) but I still see the majority of stuff happen in the firmware itself. For the S5IS, the amount of code surrounding the image shooting is HUGE, with probably just a couple of ops actually telling the sensor to shoot. Besides that, everything seems to be done by the firmware.

And the Linux drivers are not that different than a firmware code. They both contain sensitive stuff, which is why ATI and Nvidia are a little bit reluctant to open source their drivers. However, ATI is moving in this direction, and they are helping the developers of the OSS drivers.

Well, they are. Granted, a great deal about some hardware can be learned from the drivers, but the firmware is a completely different thing. From a driver you can learn how to just talk to the device/firmware, from the firmware you can learn how to actually operate it.

P.S. If the chinese people want actually 'compete' with Canon, I am sure they have the resources to reverse engineer their software and hardware as well, it's not like some firmware encryption can stop them.

If it were this easy, CHDK would be packed with a lot more features and it'd be waaaaaaay easier to properly integrate it into the camera. A firmware binary is completely different from actual source code. A binary does not contain readable variable names (none at all, actually) from which the behaviour of a function may be determined. It also does not contain any source code comments which will probably tell you how to operate a function, what it does and what values it returns. It is a LOT more difficult to figure out what the camera does from a binary than source.
Oh yeah, and because of some limitations in the ARM architecture, it's very hard to find out where a specific memory address is used, since it's usually composed of a base address with an offset.


Anyway, I think it's ok to ask, but just for data sheets, specifications and maybe an SDK (keep in mind that you'll probably have to pay for at least the last one). Still then, it's possible that they require you to sign an NDA in order to receive the asked documents, which render them completely useless for CHDK.
Oh yeah, also keep in mind that they crippled these cameras for a reason (money) so they'll probably not give you anything for free (use).

[RaduP]

The stuff that happens in hardware also needs to be coded... something which likely happens in firmware. I've seen some things happen that are probably handled by other chips in the camera (0xC0200000 memory area for example) but I still see the majority of stuff happen in the firmware itself. For the S5IS, the amount of code surrounding the image shooting is HUGE, with probably just a couple of ops actually telling the sensor to shoot. Besides that, everything seems to be done by the firmware.

Ok, you obviously have more experience than me (I just got an A570 IS today, so that I can play with it).
My main camera is a Rebel 300D, but this project seems very interesting, so I decided to give it a try.
Anyway, my understanding of how it works is this:
Hardware:
Set the sensor parameters (iso, exposure)
Read the image from the sensor (probably done by some DMA)
Demosaicing
Face detection
Jpeg/Avi compression
Color filters/special effects (it can be done in software too, but dedicated hardware can do it much faster)
Auto focus, exposure (dedicated hardware can do it faster)
Image sharpening (again, hardware can do it faster)
Dark frame substraction.
Noise reduction.
A/V out.

Software:
Reading the buttons
Displaying the whole GUI stuff (menus, grids, etc.)
USB related stuff (but not the USB protocol implementation, that's usually done by an USB controller chip)
Reading/writting files.
Controlling various I/O stuff (LEDs, motors)
Intervalometer.

Since you did more hacking then me, please let me know if I am wrong. It would be much better if those who hacked more can make some sort of wiki with all their knowledge on the subject.

Well, they are. Granted, a great deal about some hardware can be learned from the drivers, but the firmware is a completely different thing. From a driver you can learn how to just talk to the device/firmware, from the firmware you can learn how to actually operate it.

The way I see it, both the drivers and the firmware's purpose is to interface the hardware with something (software, hardware, or the end user).
Since the firmware of a camera does the interface between the hardware and the user (rather than interfacing the hardware with a software, like in the case of a sound or video card), the firmware of the camera does more than the drivers do, so they are obviously not the same.
But on the other hand, they both do the interfacing with the hardware, and that's what we are really interested about, no?

A binary does not contain readable variable names (none at all, actually) from which the behaviour of a function may be determined. It also does not contain any source code comments which will probably tell you how to operate a function, what it does and what values it returns. It is a LOT more difficult to figure out what the camera does from a binary than source.
Oh yeah, and because of some limitations in the ARM architecture, it's very hard to find out where a specific memory address is used, since it's usually composed of a base address with an offset.

Yes, I know all that, I used to program in assembly (x86) for a few years. But reverse engineering is possible with enough effort. And the Chinese people (and Russians too) are pretty good at it.
I was reading an article on how in China they have teams of software and hardware hackers, and in as little as 1 month since a product comes on the market, they already have that product cloned.

[toinech]

May rather want to ask Google to start an open firmware camera initiative...
Sorry there is not much money that can be made (as yet perceived) in such a project.

[fingalo]

Just to compare the effort made when the Timex clock was hacked (about 10 years ago) . Very briefly, you could download small Timex apps to the clock. Of course the first thing you wonder is can I make my own app? And after some period you had development system for making  apps, a fullblown PC emulator run the clock and apps. The interesting part is that the original modifier (John A. Toebes) was actually able to visit and talk to the programmer(s) who made to SW in the clock.
And now, Timex supply an environment to make these kind of apps..
So I really believe that CHDK development will have an impact in this direction, more so as CHDK really add value to tha cameras and make people want to buy them.

[RaduP]

Yes, that's the idea.
Right now, there are maybe 9 companies involved in making P&S cameras: Fuji, Olympus, Canon, Sony, Nikon, Panasonic, Casio, Samsung, Kodak.
None of them, AFAIK, allows (officially) for custom software to run on their camera.
So far, the only cameras where you can do that (unofficially) is Canon.

The reason why I got my a570 camera is so that I can run custom software and for having a small camera with me when I don't feel like taking my DSLR. If not for CHDK, I would have probably bought something else, possibly a Panasonic camera.

So in the end, every little thing counts in such a competitive market. If Canon doesn't release a SDK, maybe some other company will, and then everyone will focus their effort in developing software for that camera.

[BB]

If the other thread about the A590--it sounds like Canon may be actively trying to prevent further porting of CHDK to their new cameras.

A590

Kind of counter to the intent of this thread.

-Bill

[Psychokitty]

I don't think this to be a wise move.

Can you please explain why you think so?

...Of course, the most likely answer from Canon would be a no (or no answer at all), but what can people lose by trying?

Well, it seems pretty obvious to me. Canon, as far as I know, has not asked the fine folks here at CHDK forums to stop their development. Perhaps it's only because CHDK is not a business entity, and so it would become close to impossible to litigate against them, I don't know.
What I do know is that if someone representing CHDK did ask Canon for an official release of software, they would have an electronically written document of intent by the requester, as well as an electronically written record of notification of denial by Canon to the representative of CHDK.
As CHDK developers continues to decode Canon's encrypted softwares, they may well encounter friction in the form of the threat of litigation.
It is for this reason that I earlier suggested that the developers of CHDK should have their own section of this forum where others could read but not post. I also think that putting the title "developer" beside a members user ID is a poor idea.

If you think the folks at Canon Corporation are ignorant of CHDK and it's developments, I'm quite certain you are mistaken. Furthermore, to my knowledge, Canon is the only camera manufacturer to have their code cracked wide open and exploited to it's full potential, thus negating reason to purchase many of their "intermediate" models. Perhaps when the "Canon digital camera" becomes synonymous with "hackable" to a large enough percentage of Canon's consumers, we'll see Canon do more than just change their code encryption/OS.

In my opinion it's merely a matter of time before Canon becomes frustrated enough to actually attempt action against CHDK. Even if they can't take legal action against a phantom entity, they certainly have the resources to take action against individuals. Corporate entities know that they hardly ever have to "win" a litigation against an individual, because the battle itself would more than likely deplete any of our life savings.

Maybe nothing at all will happen. But let's not poke the lion who's bounty we've been helping ourselves to.

[RaduP]

I don't think that Canon will ever try to mess with CHDK for the following reasons:
1. CHDK breaks no law (not even DMCA)
2. That will be a lot of bad publicity for them. I for one would not hesitate to boycott them if they do such a stupid thing.
3. They indirectly benefit from it. More sold P&S cameras.

[PhyrePhoX]

one thing for sure: i cant even get my hands on one of the official canon SDKs (for remote controlling my P&S cams), how the hell will i be allowed getting the sourcecode? if ever, the code would only be released in exchange for a written NDA i suppose. same thing with the sdks, i guess this is the reason you cannot download them anywhere on the web.