Forgot your password?
typodupeerror
Open Source Wireless Networking Linux

Broadcom Releases Source Code For Drivers 350

Posted by timothy
from the they-sure-get-my-goodwill dept.
I'm Not There (1956) writes "Broadcom, the world's largest manufacturer of Wi-Fi transceivers, open sources its Linux device drivers. This is a big win for Linux users, as there are a lot of users that face Wi-Fi problems when they use Linux on their laptops. With these device drivers now open source, distributions can ship them out-of-the-box, and that means no Linux Wi-Fi problems for new devices and upcoming distributions at all."
This discussion has been archived. No new comments can be posted.

Broadcom Releases Source Code For Drivers

Comments Filter:
  • by h4rm0ny (722443) on Thursday September 09, 2010 @03:44PM (#33526522) Journal
    Broadcom wirelss. Cause of a 100 page thread [ubuntuforums.org] on the Ubuntu forums (and innumerable posts elsewhere) by people trying to get those bloody cards working under Linux.

    So speaking as one of the many sufferers, how long before I can just slap Linux on an old Acer laptop and expect the wireless to just work?
  • Re:Hahahahahaha (Score:4, Informative)

    by JonJ (907502) <jon.jahren@gmail.com> on Thursday September 09, 2010 @03:56PM (#33526682)
    They've had a binary driver out for some time, I'm using broadcom-sta on my IdeaPad.
  • by miknix (1047580) on Thursday September 09, 2010 @04:01PM (#33526724) Homepage

    $ lspci
    (...)
    03:00.0 Network controller: Broadcom Corporation BCM4311 802.11b/g WLAN (rev 02)

    $ lsmod | grep b43
    b43 153329 0
    rng_core 3158 1 b43
    mac80211 128164 1 b43
    ssb 33383 1 b43

    My broadcom BCM5311 has been working just fine using the b43 drivers included in Linux; they are there for quite some time..
    Good news for everyone though. This means new broadcom hardware support and improvement of current GPLd drivers.

  • Re:This is fantastic (Score:5, Informative)

    by BobNET (119675) on Thursday September 09, 2010 @04:05PM (#33526784)

    While you're at it, any chance of releasing the source for your video decoders?

    You mean like this [broadcom.com], or something else?

  • Thanks (Score:5, Informative)

    by msclrhd (1211086) on Thursday September 09, 2010 @04:06PM (#33526792)

    To the Broadcom team and everyone else who made this happen: you have my heartfelt thanks.

  • Re:Where's the code? (Score:4, Informative)

    by NiteMair (309303) on Thursday September 09, 2010 @04:17PM (#33526922)
  • Re:Hahahahahaha (Score:4, Informative)

    by ciggieposeur (715798) on Thursday September 09, 2010 @04:18PM (#33526936)

    See the b43 driver and b43-fwcutter utility.

  • by LWATCDR (28044) on Thursday September 09, 2010 @04:18PM (#33526940) Homepage Journal

    Yes and it opens up the option to use Broadcom chips on all sorts of embedded devices.
    Including those running on ARM, PPC, Mips, SH4 and goodness knows what else.

  • by FrankSchwab (675585) on Thursday September 09, 2010 @04:22PM (#33526988) Journal

    My company manufactures devices for PCs. We do NOT open source our drivers; I'll give you my two cents as to why:

    1. Licensing. Our drivers include licensed code from at least two other companies - code that implements algorithms seen as proprietary and valuable by those companies. We don't have the right to publish that code, and couldn't conceivably convince them to do so.
    2. Competitive advantage. We have several competitors in our market. The specs that Marketing puts on our datasheets might be optimistic in some scenarios. If we open-sourced our drivers, our competitors could easily demonstrate that to potential customers - if their drivers were closed, we would not have the equivalent opportunity to prove that their liars were worse than our liars.
    3. Support. If we publish source, we will end up fielding all kinds of questions from all kinds of people about all kinds of aspects of our product. Even if we simply answer "Go away" to all those queries, there's a lot of time spent reading and replying (or simply ignoring) them. Considering that we sell our products to OEMs for a few dollars, there just isn't any margin for end user support.
    4. Security. Say what you will about "security through obscurity", it still has a huge following in the corporate world. Publishing all your source code provides all kinds of opportunities for the scoundrels of the world to take advantage, from the PHB point of view.
    5. Financial. There is no business case to be made to disclose this proprietary information. If I'm not going to make money from something, why should I spend the time/effort to open source it, and perhaps give away information that my competitor could use?

    In Broadcom's case, there are probably others also - for example, publishing source for a Wireless card could allow operating the RF section beyond regulatory limits - transmitting/receiving out of band, transmitting with too much power, etc. This could jeopardize certification (such as FCC certification in the US) or subject the company to unwanted regulatory scrutiny.

    Does this help?

  • by Anonymous Coward on Thursday September 09, 2010 @04:29PM (#33527054)

    Ubuntu has been able to install the propietary drivers automatically for a long time now.

  • by Anonymous Coward on Thursday September 09, 2010 @04:34PM (#33527096)

    I asked about this and someone from the Ubuntu kernel team responded [stackexchange.com], looks like we'll even get a backport for 10.04!

  • by Kjella (173770) on Thursday September 09, 2010 @04:43PM (#33527202) Homepage

    I know in the case ATI, when it was taken over by AMD, they wanted to release Open Source drivers as quickly as possible but couldn't straight away because third party companies had contributed parts of the driver software and it was under NDAs. I think it took them a little while to work around some of those issues, secure agreements, etc.

    Actually, far more than that. They gave up on "washing" the internal code base and the open source drivers are essentially written from scratch with only slight one-way code sharing. In some cases yes they look at it to figure out how to program specific bits of hardware, but that's about it. And even that almost-from-scratch rewrite has to pass through a fairly serious legal review to make sure they're not revealing too much IP. Most of the shit in the graphics drivers is caused by DRM though, they can't release any low-level stuff or you would be able to see the DRM'd bits being moved around and decrypted, even if you don't know the DRM bits.

  • LiveCD win! (Score:2, Informative)

    by scrib (1277042) on Thursday September 09, 2010 @04:54PM (#33527326)

    One of the biggest problems I faced was using a LiveCD to show off Linux.

    "Here, boot with this and check it out!"
    "Eh, kinda neat lookin'. How do I get online?"
    "Well, hook your laptop to the router for a bit, or download some stuff onto a flash drive with another computer. Then you have to figure out exactly what model of wireless card you have and follow these arcane steps. No, it's easy, but you have to download these tools, too, to split the Windows driver files in... Wait, why are you booting back into Windows?"

    It's really difficult to convince someone that Linux is as easy to use as Windows (in general, day to day work) when their first experience is struggling to make such basic things work.

  • by miknix (1047580) on Thursday September 09, 2010 @05:13PM (#33527524) Homepage

    I don't usually reply to trolls but..

    From the B43 development website [linuxwireless.org]:

    not working yet * IEEE 802.11n

    That's all 802.11n devices. You know, those things that have been on the market for like 2 or 3 years? From TFA:

    IEEE 802.11n is obviously backwards compatible with 802.11b/g, meaning that 802.11n chipsets should work with 802.11b/g protocols in b43.

    Besides, I was just informing people that the Broadcom BCM4311 *802.11b/g* (in case you missed it) works just fine with b43. 802.11n support or not, it doesn't change that fact.

  • by arth1 (260657) on Thursday September 09, 2010 @05:27PM (#33527696) Homepage Journal

    IEEE 802.11n is obviously backwards compatible with 802.11b/g, meaning that 802.11n chipsets should work with 802.11b/g protocols in b43.

    Yes and no. This is only the case if the access point has fallback to the 2.4 GHz band, not if it runs exclusively in the 5 GHz band.

    I have two access points with 802.11 a/n, and can't connect to them with a b43 driver. I had to reconnect my old 802.11 b/g access point for that.

  • Re:Hahahahahaha (Score:1, Informative)

    by Anonymous Coward on Thursday September 09, 2010 @05:30PM (#33527728)

    Who's "we all"? I haven't touched wpa_supplicant.conf for a long time. The two leading wireless configuration systems, NetworkManager and Wicd, both have GUIs making it very easy to connect. Any modern GUI distro will have one of them.

  • by Lord Ender (156273) on Thursday September 09, 2010 @05:33PM (#33527768) Homepage

    There is no business case to be made to [release linux drivers]

    Before I buy personal hardware, I check to see if it works well in Linux. Before my organization buys hardware, it requires that it work in linux, as the vast majority of our datacenter runs RedHat.

    Do you sell to businesses or computing enthusiasts? There's your business case. If you're selling to soccer mom's, well, then you would have a point.

  • Re:Hahahahahaha (Score:3, Informative)

    by Guspaz (556486) on Thursday September 09, 2010 @05:40PM (#33527834)

    Keep in mind that Broadcom wireless chipsets are used in a staggering number of linux-based embedded devices, such as the venerable WRT54G.

  • by gknoy (899301) <gknoy@anaLISPsaz ... m minus language> on Thursday September 09, 2010 @05:40PM (#33527840)

    1. I should spend a month or two of engineering time to write specifications for a block that isn't part of my core competency?

    Don't try to describe it all, just point out that function calls X/Y/Z are used, point them out, and talk about what they're expected to do.

    I don't believe the "implemented in a week" claim, but at least someone could build a black box that might meet your needs. If you said, "This sorts the $FLORBS", or "This needs to quickly calculate checksums for integrity" or "This needs to do ${COMPLICATED_MATH} quickly on ${STUFF}", people can at least try to implement it. An inefficient but working implementation will meet some people's needs, even if your proprietary drivers use code thich has been heavily optimized for speed, reliability, or correctness. Assuming anyone cares enough to write them.

  • by ScrewMaster (602015) * on Thursday September 09, 2010 @06:28PM (#33528286)

    If you had the firmware source code you could all sorts of crazy stuff that would be against regulations.

    Yes. I run Tomato on my WRT54G. It has an option to directly set the desired output power in milliwatts. Don't know how accurate it is, but it does do something. I actually used that feature to reduce the power output. I set it to provide good connectivity throughout the house, yet make it very difficult to get a connection outside.

    Nevertheless, I don't like the idea of the FCC essentially requiring hardware vendors to keep source code proprietary when even the vendor wants to release it. That's not the way to advance the state-of-the-art.

  • Re:Firmware? (Score:4, Informative)

    by david.given (6740) <dg AT cowlark DOT com> on Thursday September 09, 2010 @07:02PM (#33528600) Homepage Journal
    Right, I found the source (for some reason cut-and-paste isn't working into a Slashdot text box, but it's prominently linked by another story).

    Yes, these drivers require firmware. No, this release does not include source for the firmware. You still need to have the binary blob from Broadcom to make the drivers work.

  • Re:Hahahahahaha (Score:3, Informative)

    by LingNoi (1066278) on Friday September 10, 2010 @01:30AM (#33530932)

    You're a troll because you quoted out of context..

    Your quote..

    and that means no Linux Wi-Fi problem for new devices and upcoming distributions at all.

    Full quote..

    With these device drivers now open source, distributions can ship them out-of-the-box, and that means no Linux Wi-Fi problems for new devices and upcoming distributions at all.

    It was obviously about distribution problems however you misquoted and made a strawman out of the issue, hence why you've been modded troll.

  • by the_womble (580291) on Friday September 10, 2010 @02:16AM (#33531130) Homepage Journal

    First you say that Linux is too hard for developers, then you say that it works well for developers but not for end users.

    Apart from sound (and that is not too hard a problem, given everyone uses Pulseaudio these days, and it can play ALSA and OSS stuff if the distro configures it correctly, and ALSA can also emulate OSS), I have never heard either developers or end users complain.

  • by helios17 (617082) on Friday September 10, 2010 @10:21AM (#33533528) Homepage
    Five years ago, my company budgeted for the purchase of several dozen printers at a cost of over $4000.00...having just migrated to Linux, I had the task of researching the most productive printers for the Linux environment. I was told to "lean" toward Canon printers. Like that was going to happen. I took the time to write to Canon and tell them that we would not be purchasing their product due to their lack of support for Linux. You can see a copy of their response here half way down the page here: http://linux-blog.org/more-printer-mayhem/ [linux-blog.org] Canon may have, by now, released drivers for Linux. I could care less. They were not available for me when I needed them. HP and Samsung were and still are and any printer purchases we make will be through those companies. I wonder at how many decision-makers have done the same.
  • Re:Hahahahahaha (Score:3, Informative)

    by HermMunster (972336) on Friday September 10, 2010 @01:24PM (#33535772)

    Most drivers under Ubuntu/Linux don't need to be installed. It just works. It isn't like Windows.

    To address your question, I would reply that you do it the same way you do it in Windows. Connect up the wired port or use a second machine.

    In the case that the drivers aren't there you often, in the case of Ubuntu, are prompted telling you that you have proprietary drivers available. At that point you can just click a few buttons and have them installed. They will automatically be downloaded and installed.

    If there are none, which is exceptionally rare, then you can get the windows driver, extract them, and use the tool provided with ndiswrapper to install them by pointing to the folder where the drivers are located, select your driver, and go from there. The tool has a graphical UI and is exceptionally easy.

    But, that's only useful about 1/2 the time. When you consider the vast number of installs already covered the failed percentage isn't bad. Under Windows I have had the same issue where drivers weren't available. In fact, on a current unit I'm working on there are no SiS drivers for video for Win7. To get the wired drivers working I had to use XP drivers to start, which isn't always a good idea.

    In the past when there was a large number of people that wanted to go from Vista to XP the computer manufacturer often wouldn't provide XP drivers. That meant that you had to have some pretty expansive knowledge of computers to know to go looking for models, even from other manufacturers that provided XP drivers for the chip-sets governing the device you wanted drivers for and to download those from them. Often you had to look far and wide, and you had to have the knowledge to identify the chip-sets because you weren't given this information by XP. To help you could always boot from an Ubuntu live CD, open a terminal prompt and type "lspci" (without the quotes). Then write down the components and look for the appropriate driver as described above.

Aren't you glad you're not getting all the government you pay for now?

Working...