4 ms·

The assumption that they would prefer to handicap their main product because of some unknown deal they have on an accessory seems biased to me. The SoCs that th

The assumption that they would prefer to handicap their main product because of some unknown deal they have on an accessory seems biased to me. The SoCs that they use are Broadcomm ones, a company known for being hostile to open source. Perhaps the fact that they have now sold over 25 million units of what is essentially their old designs that wheren't selling anymore is opening their eyes on the money that can be made. The developer of the new open source gpu driver is a Broadcomm employee. The point is that for some unknown to us reason they deemed it a good idea to add DRM on a side-project they have. But that doesn't mean they can't make a new camera at some point.

hlandau 7y ago
I agree that if rpi decides not to do camera DRM anymore, this motivation not to get rid of the boot blobs in the main product disappears. Currently they are defending this practice, however. It logically follows that as long as they institute this policy of using DRM on the main product to prevent use of third party camera modules, the boot blobs will remain...
- HeadsUpHigh 7y ago
  I think people misunderstand what this DRM is about. The Pi has a special connector for a camera. Anyone can use this connector to build their own camera module and they can use the kernel driver that the RPi foundation paid for. But you also need to develop an App for it. The RPi foundation made their own camera accessory and an accompanying app for it. What the DRM does is that it only allows their own accessory to work with the app. So it's more like brand protection than it's market control. There are plenty of other cameras on the market that you can buy. Why they chose the camera to DRM out of all the peripherals I don't know, but the only reasonable place that they can stick it into is the blob that Broadcomm provided. Btw the situation with the binary blob has been going for years and from what I've gathered in the past what's happening is that the foundation members signed an agreement to not reverse engineer anything on the SoC when they made the first Pi. Since then they offered a price for an open source gpu driver but didn't follow it up with more competions. So either Broadcomm shut them down or it paid off in internal pressure since Broadcomm paid and provided the mainline driver used in this version.

hlandau 7y ago

I agree that if rpi decides not to do camera DRM anymore, this motivation not to get rid of the boot blobs in the main product disappears. Currently they are defending this practice, however. It logically follows that as long as they institute this policy of using DRM on the main product to prevent use of third party camera modules, the boot blobs will remain...

HeadsUpHigh 7y ago
I think people misunderstand what this DRM is about. The Pi has a special connector for a camera. Anyone can use this connector to build their own camera module and they can use the kernel driver that the RPi foundation paid for. But you also need to develop an App for it. The RPi foundation made their own camera accessory and an accompanying app for it. What the DRM does is that it only allows their own accessory to work with the app. So it's more like brand protection than it's market control. There are plenty of other cameras on the market that you can buy. Why they chose the camera to DRM out of all the peripherals I don't know, but the only reasonable place that they can stick it into is the blob that Broadcomm provided. Btw the situation with the binary blob has been going for years and from what I've gathered in the past what's happening is that the foundation members signed an agreement to not reverse engineer anything on the SoC when they made the first Pi. Since then they offered a price for an open source gpu driver but didn't follow it up with more competions. So either Broadcomm shut them down or it paid off in internal pressure since Broadcomm paid and provided the mainline driver used in this version.