6 ms·

Anybody have any idea why this isn't enabled out o the box?

cbhl 6y ago
I imagine screen tearing, especially under the default compositing window manager, would be unacceptable for the out-of-the-box configuration. Another possibility is just that nobody has gotten to it yet.
jandrese 6y ago
The answer is probably that Broadcom's documentation is dogshit and this required a herculean effort to reverse engineer to get everything working.
- 908B64B197 6y ago
  That's something I've wondered for a long time: Doesn't Broadcom want users to be able to use the full feature range of it's silicon?
  - justin66 6y ago
    Broadcom doesn't sell its processors to end users.
    - 908B64B197 6y ago
      Good point. I assumed Broadcom would be happy to have a platform as popular as the Pi using it's SoC. There must be a lot of companies out there prototyping on the Pi (because it's probably one of the easiest dev-board to get started on).
      - barkingcat 6y ago
        You misunderstand the point of a company like broadcom. The Pi is a rounding error money wise.
        salawat 6y ago
        Can you go into a bit more detail on this? I mean, I get that they supply parts for specialized devices, but why would a company pass up on the opportunity to reap as much goodwill and brand recognition as the position of "the people that made the Raspberry Pi economical" could engender? I mean think about it for a minute. This is this generations 486 or Commodore or VIC-20. I scratch my head at trying to imagine the thought process of those in management to completely throw away this opportunity unless they really have something big to hide.
        atonse 6y ago
        It’s because it’s not an opportunity. When you are going after selling millions or tens of millions of units every year in cell phones, these chips at this point are old for them. A lot of tech in this chip was probably in a cell phone 5-7 years ago. So they’ve made their profits from it. Having it out in a few hundred thousand RPis won’t make much of a difference at this point.
        barkingcat 6y ago
        That said, it is a good way to clear out their warehouse inventory I guess.
        justin66 6y ago
        > Having it out in a few hundred thousand RPis won’t make much of a difference at this point. Many millions of Raspberry Pis are sold in a year. They aren't Broadcom's highest priority but the foundation is a legitimate customer now.
        lozaning 6y ago
        Lets say that they start playing nice and fully support the rpi project. How would you as a consumer show your increased support for broadcom? Go out and buy a bunch of products that contain specifically broadcom chips? A bulk order of modems off Digikey?
        6y ago
  - rektide 6y ago
    most companies are only interested in selling chips to companies with teams & teams of engineers willing to sign nda's & slave away until some final appliance thing is shipped. really sad state of affairs across a wide range of the industry.
  - barkingcat 6y ago
    Of course not. The Pi itself was a herculean feat just to get broadcom stop suing consumers for using the chips as an individual consumer. Broadcom itself is about as anti-user as they come. What they really want to do is to sell you the features - you want decoding that's already on the chip? Sign NDA and pay them a few million dollars for each seat / license and they'll let you use it.
  - cosmie 6y ago
    Poor documentation can be as much an asset as a liability, depending on your perspective. - The more comprehensive your documentation, the easier it is for your competition to get a complete read on your product and it's capabilities. Which makes it both easier for competitors to strategically outcompete you, as well as counterfeiters to more accurately counterfeit your chips. - The more precise your documentation, the more stringent your customer's expectations become. Poor documentation can act as a form of liability insurance - if someone uses a feature and things get weird, you can claim their use is out of spec. Harder to weasel out if things are clearly documented. - The more expansive your documentation, the less dependent your (potential) customers will be on actually talking to you when evaluating if your product is fit for their use. I could see this being a negative in this industry - Feature X may be fine to use, but introduce intermittent instability if used for extended periods of time simultaneously with Feature Y, which can be compensated for via Z but doing so shortens expected lifespan by 30%. Wargaming out every possible contingency ahead of time would both be extraordinarily expensive, and result in documentation that would overwhelm the people using it. But not doing so while providing otherwise expansive/comprehensive documentation may lead to a false sense of understanding from your customers such that they write you off when your product would have in fact been a good fit. - A corollary to the above - poor documentation trains your (potential) customers to just reach out directly and have a conversation about it. Which provides the chance for you to truly evaluate their situation and provide a more considered response that takes into account their use/circumstances. Which can either be using the product they may be familiar with, or suggesting a different one that's more appropriate that they may not have thought of. - Ditto the above for implementation. Directly supporting them during their implementation can be more effective than them relying on generic documentation, since you can provide more contextually relevant details/instructions/direction. Which cycles back to the second bullet above, where you have the opportunity to provide information that steers customers in the right direction, addressing potential issues preventatively rather than playing damage control if their use wasn't completely aligned with the documentation they blindly followed. You can also directly put the costs of this work against the customer, rather than eating it via the comprehensive wargaming scenarios mentioned above. Which sounds harsh, but is far more efficient for everyone involved. Customers with a cookie cutter use case get cheaper per unit prices since you didn't inflate the amount of QC and experimentation required to flesh out the documentation, and you didn't waste time and resources chasing down contingencies that were never actually applicable to any of your customers. So it sucks for a subset of people - hobbyists who aren't direct customers in the first place, cash strapped hardware shops who can't pay for that support, and the engineers at BigCos who aren't willing to pay for that support. But can still be rationalized when you consider it's an absolute non-issue for their primary target market, while also indirectly benefiting everyone else via the lower unit costs afforded by this mentality/approach.
rektide 6y ago
chromium has been resistant to enabling Linux acceleration until very recently. https://bugs.chromium.org/p/chromium/issues/detail?id=463440 https://bugs.chromium.org/p/chromium/issues/detail?id=463440 from the article, this seems to require setting up an advanced video card config on the pi side & allocating 128mb ram. that used to be a significant portion of ram. rpi3 came with 1gb.

cbhl 6y ago

I imagine screen tearing, especially under the default compositing window manager, would be unacceptable for the out-of-the-box configuration. Another possibility is just that nobody has gotten to it yet.

jandrese 6y ago

The answer is probably that Broadcom's documentation is dogshit and this required a herculean effort to reverse engineer to get everything working.

908B64B197 6y ago
That's something I've wondered for a long time: Doesn't Broadcom want users to be able to use the full feature range of it's silicon?
- justin66 6y ago
  Broadcom doesn't sell its processors to end users.
  - 908B64B197 6y ago
    Good point. I assumed Broadcom would be happy to have a platform as popular as the Pi using it's SoC. There must be a lot of companies out there prototyping on the Pi (because it's probably one of the easiest dev-board to get started on).
    - barkingcat 6y ago
      You misunderstand the point of a company like broadcom. The Pi is a rounding error money wise.
      - salawat 6y ago
        Can you go into a bit more detail on this? I mean, I get that they supply parts for specialized devices, but why would a company pass up on the opportunity to reap as much goodwill and brand recognition as the position of "the people that made the Raspberry Pi economical" could engender? I mean think about it for a minute. This is this generations 486 or Commodore or VIC-20. I scratch my head at trying to imagine the thought process of those in management to completely throw away this opportunity unless they really have something big to hide.
        atonse 6y ago
        It’s because it’s not an opportunity. When you are going after selling millions or tens of millions of units every year in cell phones, these chips at this point are old for them. A lot of tech in this chip was probably in a cell phone 5-7 years ago. So they’ve made their profits from it. Having it out in a few hundred thousand RPis won’t make much of a difference at this point.
        barkingcat 6y ago
        That said, it is a good way to clear out their warehouse inventory I guess.
        justin66 6y ago
        > Having it out in a few hundred thousand RPis won’t make much of a difference at this point. Many millions of Raspberry Pis are sold in a year. They aren't Broadcom's highest priority but the foundation is a legitimate customer now.
        lozaning 6y ago
        Lets say that they start playing nice and fully support the rpi project. How would you as a consumer show your increased support for broadcom? Go out and buy a bunch of products that contain specifically broadcom chips? A bulk order of modems off Digikey?
        6y ago
- rektide 6y ago
  most companies are only interested in selling chips to companies with teams & teams of engineers willing to sign nda's & slave away until some final appliance thing is shipped. really sad state of affairs across a wide range of the industry.
- barkingcat 6y ago
  Of course not. The Pi itself was a herculean feat just to get broadcom stop suing consumers for using the chips as an individual consumer. Broadcom itself is about as anti-user as they come. What they really want to do is to sell you the features - you want decoding that's already on the chip? Sign NDA and pay them a few million dollars for each seat / license and they'll let you use it.
- cosmie 6y ago
  Poor documentation can be as much an asset as a liability, depending on your perspective. - The more comprehensive your documentation, the easier it is for your competition to get a complete read on your product and it's capabilities. Which makes it both easier for competitors to strategically outcompete you, as well as counterfeiters to more accurately counterfeit your chips. - The more precise your documentation, the more stringent your customer's expectations become. Poor documentation can act as a form of liability insurance - if someone uses a feature and things get weird, you can claim their use is out of spec. Harder to weasel out if things are clearly documented. - The more expansive your documentation, the less dependent your (potential) customers will be on actually talking to you when evaluating if your product is fit for their use. I could see this being a negative in this industry - Feature X may be fine to use, but introduce intermittent instability if used for extended periods of time simultaneously with Feature Y, which can be compensated for via Z but doing so shortens expected lifespan by 30%. Wargaming out every possible contingency ahead of time would both be extraordinarily expensive, and result in documentation that would overwhelm the people using it. But not doing so while providing otherwise expansive/comprehensive documentation may lead to a false sense of understanding from your customers such that they write you off when your product would have in fact been a good fit. - A corollary to the above - poor documentation trains your (potential) customers to just reach out directly and have a conversation about it. Which provides the chance for you to truly evaluate their situation and provide a more considered response that takes into account their use/circumstances. Which can either be using the product they may be familiar with, or suggesting a different one that's more appropriate that they may not have thought of. - Ditto the above for implementation. Directly supporting them during their implementation can be more effective than them relying on generic documentation, since you can provide more contextually relevant details/instructions/direction. Which cycles back to the second bullet above, where you have the opportunity to provide information that steers customers in the right direction, addressing potential issues preventatively rather than playing damage control if their use wasn't completely aligned with the documentation they blindly followed. You can also directly put the costs of this work against the customer, rather than eating it via the comprehensive wargaming scenarios mentioned above. Which sounds harsh, but is far more efficient for everyone involved. Customers with a cookie cutter use case get cheaper per unit prices since you didn't inflate the amount of QC and experimentation required to flesh out the documentation, and you didn't waste time and resources chasing down contingencies that were never actually applicable to any of your customers. So it sucks for a subset of people - hobbyists who aren't direct customers in the first place, cash strapped hardware shops who can't pay for that support, and the engineers at BigCos who aren't willing to pay for that support. But can still be rationalized when you consider it's an absolute non-issue for their primary target market, while also indirectly benefiting everyone else via the lower unit costs afforded by this mentality/approach.

rektide 6y ago

chromium has been resistant to enabling Linux acceleration until very recently. https://bugs.chromium.org/p/chromium/issues/detail?id=463440 https://bugs.chromium.org/p/chromium/issues/detail?id=463440 from the article, this seems to require setting up an advanced video card config on the pi side & allocating 128mb ram. that used to be a significant portion of ram. rpi3 came with 1gb.