Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Wireless Networking Intel Hardware

Intel Releases Linux Driver For Centrino WLAN 285

Posted by timothy from the usefulness dept.
Werner Heuser writes "Finally Intel has made their different announcements about Linux support for the WLAN part of the Centrino technology become true. Though not yet officially announced an Open-Source driver with included firmware is available at SourceForge. The driver is still experimental and supposed to work with 2.4 Kernels as well as with 2.6 ones." (See these previous stories for some background.)
This discussion has been archived. No new comments can be posted.

Intel Releases Linux Driver For Centrino WLAN More

Intel Releases Linux Driver For Centrino WLAN

Comments Filter:

  • Intel Feeling the Pressure? (Score:5, Insightful)

    by CrankyFool ( 680025 ) on Wednesday March 10, 2004 @11:23AM (#8521717)
    This really feels like Intel's finally feeling its stranglehold on the industry wavering a little (given AMD's 64bit success). I'd like to believe that this is going to lead them to start treating us like customers, rather than prisoners. Certainly, this is a nice first step.
    • I think the same... big hardware companies are changing the way they see Linux community and the computer market at all. Everyday we are more and more and more!!!
      (I feel as the Agent Smith a little... he he he)

    • Re:Intel Feeling the Pressure? (Score:5, Interesting)

      by Oriumpor ( 446718 ) on Wednesday March 10, 2004 @12:18PM (#8522251) Homepage Journal
      This is no first step, it's the begining of the end of many steps Intel has taken forth with it's centrino *line.* The only remaining piece was the WLAN component they have already facilitated the release of the speed stepping and other integrated components.

      Wintel isn't ALWAYS the badguy.

      NOW, I can say THANK GOODNESS no more lockups in Fedora from DriverLoader BS, now my only question is how will they allow Linux users to flash their firmware when the manufacturers don't provide floppy drives on most of the Centrino lines.
    • We must treat this as a good thing. They really have done as promised, done what everyone has wanted them to do for a while, and they started with a piece of hardware that is probably in the top 10 list for desired support (I know its the #1 driver on my "need" list).

      Thank you Intel! For a company that has gotten a lot of flack on Slashdot, thank you for listening to community desires and responding in a very positive way. You went up a point in my book (which I'm sure is your goal).

  • From ipw2100_main.c (Score:4, Interesting)

    by tcopeland ( 32225 ) * <.tom. .at. .thomasleecopeland.com.> on Wednesday March 10, 2004 @11:24AM (#8521726) Homepage
    Whew!
    if (!((r <= w && (e < r || e >= w)) || (e < r && e >= w))) {
    IPW2100_DEBUG_TX("exit - no processed packets ready to release.\n");
    return 0;
    }
    Fortunately there's a little ASCII art right above it that helps explain what that if condition does:
    /*
    * Quick graphic to help you visualize the following
    * if / else statement
    *
    * ===>| s---->|===============
    * e>|
    * | a | b | c | d | e | f | g | h | i | j | k | l
    * r---->|
    * w
    *
    * w - updated by driver
    * r - updated by firmware
    * s - start of oldest BD entry (txq->oldest)
    * e - end of oldest BD entry
    *
    */

    • Re:From ipw2100_main.c (Score:4, Funny)

      by Anonymous Coward on Wednesday March 10, 2004 @11:44AM (#8521950)
      Whatever happened to meaningful variables (which is taught at age 12 before you even touch a language)

      • Re:From ipw2100_main.c (Score:5, Funny)

        by Anonymous Coward on Wednesday March 10, 2004 @11:49AM (#8522000)
        Duh!
        This is high performance code! Single-letter variable names execute more faster.
        U R teh st00p3d.

      • Re:From ipw2100_main.c (Score:5, Insightful)

        by Shisha ( 145964 ) on Wednesday March 10, 2004 @12:07PM (#8522141) Homepage
        Judging by the scope of these variables and the fact that they seem to be docummented right at the top, I don't think anyone could have an issue with that.

        In fact, sometimes explaining what a variable means and then using just a one letter name is much more helpful than names like "thisOneINeedToDoThisBecauseOfThat".

        Just think of the use of "i" in for loops, no one in the right set of mind would use something like "loopCounter".

        It's a bit like in PDE theory, if you use t, then you don't have to bother specifying that t belongs to [0,T] and that it's time - everyone expects that.

        • Re:From ipw2100_main.c (Score:5, Insightful)

          by sydb ( 176695 ) <michael@Nospam.wd21.co.uk> on Wednesday March 10, 2004 @12:24PM (#8522338)
          Just think of the use of "i" in for loops, no one in the right set of mind would use something like "loopCounter"

          Quite, but if you're choosing decent variable names, you would never think of chooseing loopCounter!

          What are you counting? That's what the variable name should be.

          Iterating over rows in a matrix (or whatever)? then the variable name should be 'row'! Not rowCount or RowNumber or count or r, simply 'row'.

          Then row++ makes sense - next row.

        • On the other hand, with nested loops I can't count how many times I've mixed up j and i, and not seen it at a cursory glance of the bugridden code. If I used outerCounter and innerCounter that wouldn't happen (as much). Not that I'm going to abandon my i's and j's ofcourse.
    • Haven't you ever used a circular buffer before? r and w are the read and write positions within the buffer; e is the "end of oldest BD entry" (BD = buffer descriptor, at a guess). The condition for throwing out a "BD entry" is that the end of it is within the free space in the buffer after w and before r, allowing for wrap-around.

  • NDISWRAPPER (Score:4, Informative)

    by cuban321 ( 644777 ) on Wednesday March 10, 2004 @11:28AM (#8521769) Homepage
    Until these drivers stabilize you can use NDISWRAPPER [sourceforge.net].

    This tool allows you to run the Windows driver for some wireless cards that have little or no Linux support.

    Daniel

    • Re:NDISWRAPPER (Score:5, Interesting)

      by gspr ( 602968 ) on Wednesday March 10, 2004 @11:33AM (#8521816)
      Do not encourage the use of NDISWRAPPER! Someone will probably moderate this as Troll, but come on - we all know that having such a "fallback option" makes the hardware makers relax more when it comes to releasing natively running, opensource Linux drivers!

      • Re:NDISWRAPPER (Score:5, Interesting)

        by Zakabog ( 603757 ) <john@jmaugNETBSD.com minus bsd> on Wednesday March 10, 2004 @11:56AM (#8522049)
        But for them to relax more they'd have to be working on something in the first place, most of the hardware makers that are willing to support linux are gonna do it with the best drivers they can, not have people running their software in linux with some little hack. And the ones that don't support linux don't care that some little app lets people run windows drivers, they weren't going to support linux anyway it's not worth it for them. If NDISWRAPPER works then people should use it, I know I'd deffinitely use it if it supports my laptops network card (haven't been able to get this thing to work at all, some fairly old lucent technologies wireless card, I think there is support for some newer version of this card but not mine.) I'd use a newer card with linux support but the laptop itself doesn't support these (dunno why, tried some netgear card it didn't like that very much I think the PCMCIA slot in my laptop is 16 bit or something like that it's an old laptop.)

  • SCO (Score:3, Funny)

    by Youssef Adnan ( 669546 ) on Wednesday March 10, 2004 @11:29AM (#8521778) Homepage
    Here goes my karma: Are you sure this code doesn't belong to SCO? I mean, we all know that all open source projects belong to them but we're hiding it. :)

  • Thanks, Intel... (Score:5, Insightful)

    by MsGeek ( 162936 ) on Wednesday March 10, 2004 @11:29AM (#8521784) Homepage Journal
    I'm impressed. A real open-source driver from a major company...this shames the NVidias and the Lucents of the world who give stupid excuses for their closed-source drivers.

    Looks like I'm going to be sniffing around for a refurbed IBM T41 ThinkPad with Centrino tech in the future.

    • Re:Thanks, Intel... (Score:5, Insightful)

      by Iscariot_ ( 166362 ) on Wednesday March 10, 2004 @11:33AM (#8521812)
      this shames the NVidias and the Lucents of the world who give stupid excuses for their closed-source drivers.

      Better than no driver at all...

      • Re:Thanks, Intel... (Score:5, Insightful)

        by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Wednesday March 10, 2004 @12:03PM (#8522105) Homepage Journal
        Barely. I'd pine for the closed NVidia driver if I were a gamer (I still wouldn't use it, but I'd at least be tempted). For 2d stuff, XFree's 'nv' driver is fast, rock solid, and works out of the box - and it's Free.

        Closed source drivers are evil, and are in fact what triggered RMS to begin the Free Software movement. They encourage complacency while giving nothing.

        • Re:Thanks, Intel... (Score:3, Insightful)

          by spitzak ( 4019 )
          We all know the closed-source driver is better. But it is not better *because* it is closed source. Some argue that it would be even better open-source because people would fix it, but even if nothing was changed, it would be exactly the same open-source.

          The argument is that Intel might demonstrate that releasing the source for something does not cause you to go out of business tomorrow.
      • Is it really? There being a non-free driver strongly discourages any hacker to implement a free software (or open source if that's your thing) driver.

        Ironically, who this hurts most are the *BSD folks. No 3D acceleration for them on NVidia cards since there are only proprietary drivers that work with Linux.

        In the long run it has some very dark implications for the Linux users also, though. Some might (myself included) be unhappy about not being able to run an operating system based completely on free soft

    • Re:Thanks, Intel... (Score:4, Informative)

      by /dev/trash ( 182850 ) on Wednesday March 10, 2004 @11:46AM (#8521968) Homepage Journal
      Read the article.....it's not really there yet.

    • Re:Thanks, Intel... (Score:4, Interesting)

      by dave420 ( 699308 ) on Wednesday March 10, 2004 @12:02PM (#8522093)
      Stupid excuses like "this cost us millions to produce, so we're not going to give the code away to you and our competitors, which would eventually cause us to lose so much revenue we'd not be able to make any more cards/drivers for you at all"?

      • Re:Thanks, Intel... (Score:5, Insightful)

        by Jeffrey Baker ( 6191 ) on Wednesday March 10, 2004 @12:06PM (#8522135)
        Intel makes $0 from the sale of their drivers. Also the marginal cost to produce a Linux driver when you already have 1) a Windows driver, and 2) a staff of Linux hackers is very much lower than "millions of dollars". However, the marginal cost of sales of Intel Centrino laptops to Linux users will be several hundred dollars each.

        The economics are pretty simple. Probably some large client like Goldman Sachs or a similarly sized outfit wants to run Linux on laptops and told Intel to get their act together.

        • Yes, they make $0 from the sale of their drivers. They do, however make money from the sale of the hardware they produce. If their competitors can use the drivers they release to boost their products development/sales, intel loses money on hardware sales. That's the real economics of the situation, and as you can see, it's in Intel's (and every other hardware manufacturer who's leading the market) best interests to keep closed source exactly that - closed.
          • Please, it is extremely difficult to produce and market a wireless chipset. Only a handful of very sophisticated companies can do so, and those that can have already done so. Intel's driver has boring crap like ring buffers and queues. It doesn't have ths secret sauce. Take a look for yourself.

      • Stupid excuses like "this cost us millions to produce, so we're not going to give the code away to you and our competitors, which would eventually cause us to lose so much revenue we'd not be able to make any more cards/drivers for you at all"?

        While I wouldn't go so far as to call this excuse "stupid", it is certaintly far from "convincing".

        "This cost us millions to produce" doesn't imply "we'll lose something by disclosing it". How exactly would this cause losses? By reducing sales? Perhaps, if the dri

        • The drivers are free, but if a competitor got their hands on the code, they can use that development and "stand on the shoulders of giants" and further their own products enough to play Intel's game. That smaller manufacturer would be in a real position to take sales away from Intel, which obviously Intel doesn't want. That's what's going on here. With most manufacturers (nVidia, Intel (for their modems), etc.) binary drivers are free as in beer, not speech. That's the main difference. If the contents

          • That's still a load of BS. Video card manufacturers have plans laid out years ahead of time. When nVidia purchased all the 3dfx IP, it took them two years to incorporate any of it into their own product line. By that time, the entire industry had moved on. So it's hardly realistic to believe that a 3D manufacturer is going to be able to look at the specifications for a competitors current product, and produce anything with that learned knowledge in a competitive time frame.

            Dinivin
    • I'm impressed. A real open-source driver from a major company...

      You haven't browsed the Linux source code lately, have you?

      There are at least two other Intel drivers in them.

      • Re:Thanks, Intel... (Score:2, Insightful)

        by Anonymous Coward
        Intel has stated that they are treating Linux as a "Tier 1" platform -- same support as Windows. Only that the Centrino wireless was a bit of a fuckup on their part.

        Intel is also responsible for Linux ACPI, EFI, and all of the modern Intel chipset support -- including AGP, SATA, etc, and NIC drivers. I think they also do the XFree drivers for their graphics chipsets.

        Compare this to NVidia (100% binary) or VIA/SIS/etc (reverse engineering by Linux devs, many bugs), and Intel is really THE top notch Linux h
    • And to reiterate --- an OpenGL driver is an order of magnitude more complex than a network driver! NVIDIA open-sourcing their OpenGL driver would be the equivilent of Microsoft open-sourcing Direct3D!

    • Re:Thanks, Intel... (Score:5, Insightful)

      by Unregistered ( 584479 ) on Wednesday March 10, 2004 @12:05PM (#8522122)
      this shames the NVidias and the Lucents of the world who give stupid excuses for their closed-source drivers.

      Quit bitching. IICRC, NVidia doesn't own all the code in their drivers and anyway, why should they be forced to disclose stuff they consider a trade secret? They provide solid, working drivers for an OS used by like 1% of the desktop market. That's pretty impressive, imo.
      • This is a great argument - except for one thing. Why can't they release all of their code? If there is somebody else's code in there that has to be binary only why can't THOSE be the parts that are binary only? A couple of ".o" files in a mass of ".c" files named "sgi.o", "ms.o", "sun.o", etc to hide the non-disclosable binary bits. At the very least the bugs in the rest of it could be hunted down and squashed. It's just an excuse, they don't want to release it. I'd rather they said so than blame it o
      • > NVidia doesn't own all the code in their drivers

        And their reason for not releasing their HARDWARE specs would be what exactly?

        Could it be that they understand all too well that were they to tell us how their stuff works the X hackers would be beating their framerates within a year?

    • Re:Thanks, Intel... (Score:3, Interesting)

      by Tore S B ( 711705 )
      ...this shames the NVidias and ...

      Well, nVidia has a good reason - they use proprietary algorithms lisenced from companies who makes them for a living. Their lisence disallows them from releasing the source. Thus, it is not a stupid excuse. Their hands are really tied. Intel also had some completely valid concerns that an Open-Source driver would allow their chip to tune to frequencies out of the legal WLAN band, and at signal strengths way higher than the legal limit, to name a few.

      Luckily, Intel (jus
      • Most of those "proprietary algorithms" are not essential to getting quality 3D support for most applications. Look at ATI's DRI drivers. Most of their Radeon lineup works very well with the DRI drivers. Only the recent cores do not have DRI support (in favor of closed source drivers). They gave programming documentation to the project, and the drivers have been very high-quality so far, in spite of missing a few features like S3TC (which can be implemented with a patch - probably legally).

        Their hands a
    • Yeah for shame NVidia for taking your time to support linux, how dare you do that. Don't ever do it again! As much as I love your driver, and how amazingly easy it is to insall, and how great it works in linux, don't EVER do that again! YOU BASTARDS! How dare you corrupt us with some closed source driver! Even though you probably can't open source the driver because it might contain trade secrets or liscensed materials that you're not allowed to show us, but still! Don't you dare make a closed source

  • Open Source Driver + Firmware (Score:5, Interesting)

    by alex_tibbles ( 754541 ) on Wednesday March 10, 2004 @11:29AM (#8521787) Journal
    Is this a full driver or is the firmware a subtle way of making a closed-source driver?

    (Honest question)

    • Re:Open Source Driver + Firmware (Score:5, Insightful)

      by vranash ( 594439 ) on Wednesday March 10, 2004 @11:39AM (#8521893)
      Given the supposed lack of foresight in their hardware design that most wlan vendors have taken recently (using basically 'soft wlan' cards), it is probably more akin to a 'partially closed driver', in that you probably won't have access to the channel frequencies, adding new network modes (master, monitor, etc). HOWEVER given that, it should allow future patching to the kernel side of the driver to support whatever future interface changes happen to ensure the card won't suddenly become useless.

      IMHO, this is what all wlan dealers should be doing... if you can't give direct access to the hardware due to possible legal/FCC constraints, then you should have firmware to handle the interfacing so that you can at least release firmware interface specs, and hopefully be able to cut down on cross development costs by having your firmware patches enhance both linux and windows functionality while stomping out mutual bugs.

    • Re:Open Source Driver + Firmware (Score:5, Informative)

      by alex_tibbles ( 754541 ) on Wednesday March 10, 2004 @11:41AM (#8521928) Journal
      to answer my own question (partly):
      "As the firmware is licensed under a restricted use license, it can not be included within the kernel sources. To enable the IPW2100 you will need a firmware image to load into the wireless NIC's processors." From http://ipw2100.sourceforge.net/README.ipw2100 [sourceforge.net].
      And look at the firmware license [sourceforge.net]!

    • Re:Open Source Driver + Firmware (Score:5, Informative)

      by david.given ( 6740 ) <dg@cowlark.com> on Wednesday March 10, 2004 @12:22PM (#8522315) Homepage Journal
      Is this a full driver or is the firmware a subtle way of making a closed-source driver?

      That's a rather more complicated question than you might think.

      The way most wireless cards work is that there's some radio hardware, hooked up to a microprocessor on the card that handles the low-level 802.11 frames, and some host software that talks to the microprocessor.

      The microprocessor --- which tends to be an embedded ARM, these days --- runs a tiny nearly-an-operating-system out of flash or RAM. If RAM, then you need to download the microprocessor's code when you power up the card. That's the firmware.

      This has a number of advantages: it means that the crucial, real-time processing is done with a custom processor that doesn't have to worry about running user code; it means that the vendor can change the hardware without having to change the driver, because the driver's just talking to a well-defined interface provided by the microprocessor; and it means that it's much easier to make cross-platform drivers.

      It also means that the vendor can hide stuff in the firmware that they really, really don't want the user to play with. Such as the power, channel and timing settings that are mandated by the FCC.

      I don't know if there are any wireless vendors out there who actually release source code to their firmware. (I'd be interested to find out if there are.) Which means that the answer to your question is both yes and no: the firmware's not open source, but the driver is.

    • Re:Open Source Driver + Firmware (Score:5, Insightful)

      by Fluffy the Cat ( 29157 ) on Wednesday March 10, 2004 @12:41PM (#8522588) Homepage
      Not really. Most hardware nowadays contains firmware (modern wireless cards are often just ARM cores attached to a radio transmitter), but in many cases it's in ROM or flash and you've never noticed. Older wireless cards with entirely open drivers (such as the orinocos) had similar quantities of firmware, but the cards shipped with it in flash. Requiring it to be loaded by the OS makes hardware implementation slightly easier, and you can upgrade the firmware along with the drivers without involving potentially risky reflashing.

      Would you consider Linux closed-source because on most hardware it requires a closed-source BIOS or firmware in order to boot?

      (Yes, I know about LinuxBIOS. It supports a subset of x86 hardware)

  • No WEP (Score:5, Informative)

    by gspr ( 602968 ) on Wednesday March 10, 2004 @11:31AM (#8521793)
    WEP currently no support
    Notice how WEP support is not yet done [sourceforge.net].

    • Re:No WEP (Score:3, Informative)

      by michich ( 679957 )
      WEP is weak. Use OpenVPN [sourceforge.net] if you can.
      • Wanna explain that to my CIO who dictates WEP?

        OK, I don't actually have a CIO, but that's to illustrate my point. I'd say that the majority of people using wireless in the first place do have usage policies in place, and I imagine that the bulk of those require WEP to join the WLAN.

        • If you're in a corporate environment that actually allows access to anything via a wireless LAN and rely on WEP, then you have much bigger problems with your organization. Seriously - WEP is pathetic. Use a VPN. In my case I tunnel everything through SSH (web, IMAP, SMTP, etc).
          • That's like saying that passwords are pointless because they can be broken.

            Using WEP as the sole security on your WLAN is bad. Using it as an additional layer of security is perfectly reasonable and recommended.

            • Yes, agreed. The security provided by WEP may be poor, but it is better than nothing and every little bit counts.

              • No Tresspassing! (Score:3, Insightful)

                by BLKMGK ( 34057 )
                WEP on an AP also makes it crystal clear that you're not expecting "visitors" so any legal proceedings later on are much more likely to bear fruit. Kind of hard for someone to say they just "stumbled" upon your network when the network is encrypted by default and requires effort to access...

  • Hardly Intel... (Score:5, Insightful)

    by damieng ( 230610 ) on Wednesday March 10, 2004 @11:33AM (#8521813) Homepage Journal
    I fail to see how "Finally Intel has made their different announcements about Linux support for the WLAN part of the Centrino technology become true."

    when the SourceForge web site clearly states in the first paragraph.

    "This project was created to enable support for the Intel PRO/Wireless 2100 (IPW2100) mini PCI adapter. This project is intended to be a community effort as much as is possible given some working constraints (mainly, no HW documentation is available)"

    Sounds like Intel haven't helped at all and some enterprising folks have done their own. Kudos to them, shame on Intel.

    And shame on Werner and Timothy for getting basic cursory facts right. Unless of course the SF website is failing to give credit to Intel.

    • Re:Hardly Intel... (Score:5, Informative)

      by javatips ( 66293 ) on Wednesday March 10, 2004 @11:42AM (#8521933) Homepage
      My first reaction was the same as yours... But if you browse at the end of the page and hover your mouse on the maintainer name, you'll see that he has an Intel e-mail address.

      So yes Intel is, kind of, supporting Linux driver for the Centrino chip as the pay the guy...

      However, I don't beleive this is a priority for them. If it was so, they would have released something that is fully functional... What it seems to me is that they are paying one guy to do it and hope the OS community will jump in and help them out! I don't see any real corporate backing behind this project.

    • Bzzt. Wrong. Look who's doing this. (Score:5, Interesting)

      by petard ( 117521 ) on Wednesday March 10, 2004 @11:42AM (#8521941) Homepage
      Read the copyright on the source code, and look at the contact info posted on the sf site. It's intel. (Hint: "Copyright 2003 - 2004 Intel Corporation" and the contact is jketreno AT linux.intel.com)

      Just because they aren't loudly tooting their own horn by splashing "intel" all over the sf.net website doesn't mean they're not helping/having their people do the work. What you saw simply means they haven't been able to work out how to get the HW docs out the door to the community, and are being candid about this in the first sentence of their page.

      And shame on you for making bad assumptions about helpful people, and unfairly criticizing an accurate news article.

      I suppose I may have been trolled here, and I hate to bite, but this needs to be corrected :-)
      • Okay, I'll retract the statement "Sounds like Intel haven't helped at all" although I did mention at the end of my statement it could be that the SF site wasn't crediting intel with any assistance.

        Frankly I think the rest of my posting stands. While it's obvious some people have put hard work into this I don't think Intel have met the promises covered in the previous stories.

  • if only.... (Score:4, Interesting)

    by thedude13 ( 457454 ) on Wednesday March 10, 2004 @11:33AM (#8521817)
    broadcom would follow intel's lead and release a linux driver. while driverloader and ndiswrapper work, it would be nice to see the hardware vendor stop making crappy excuses (fcc regulations other stupid ones) about releasing a linux driver.

  • I don't get it (Score:5, Interesting)

    by edbarrett ( 150317 ) on Wednesday March 10, 2004 @11:34AM (#8521831)
    The contact email address is ipw2100<dash>admin<at>linux<dot>intel<dot>co m, the readme says it's copyright intel, but the home page says
    This project is intended to be a community effort as much as is possible given some working constraints (mainly, no HW documentation is available)
    So intel is not releasing the necessary documentation for the hardware, but has set up a SF project for "The Open Source Community" to figure it out?

    • Re:I don't get it (Score:4, Funny)

      by Halthar ( 669785 ) on Wednesday March 10, 2004 @11:39AM (#8521896)
      Maybe they are truly in touch with open source projects everywhere, and when it comes to documentation simply said "screw it, someone else will write it!"

    • Re:I don't get it (Score:5, Insightful)

      by MWelchUK ( 585458 ) on Wednesday March 10, 2004 @11:45AM (#8521957)
      They probably can't release the documentation for some reason, however as long as there are a number of intel people on the project _with_ access to the documentation this isn't as huge a problem as it would otherwise be.

      This allows the community to help stear the portions of the code that don't require the documentation and to help them properly tie the driver into Linux.

      As long as the code isn't a complete mess it will also be possible to get some understanding of the workings of the chip from the code.

      I agree that it is not ideal, however it's better than a binary-only driver.
    • It's a "clean room" effort, dude!

      The guy(s) doing this are working without documentation, just capabilities, and are producing a driver that works. Reverse engineering, to protect Intel's IP.

      Nothing new about that, except maybe that they are doing it within the same company.

  • Hooray! (Score:2, Funny)

    by mrseigen ( 518390 )
    Maybe now I'll reconsider buying that Thinkpad over a Powerbook for a split second.

  • Don't bother yet, its not finished (Score:4, Informative)

    by Anonymous Coward on Wednesday March 10, 2004 @11:36AM (#8521853)
    TODO

    - long/short preamble support
    - enhance wireless extension support
    - adhoc
    - encryption (WEP)
    - continue to add support for addtional SW RF kill switch implementations
    - "shared" authentication
    - transmit power control
    - power states support (ACPI)

    Yes you read that right. So is there anything this driver does do?

    After promising and promising to support Linux we get this. A crappy not finished driver. I suppose I'm supposed to be happy that Intel finally started to work on this after like what, a year after we should have had support? Sorry Intel but screw off. I already bought a PCMCIA Wireless NIC. And I'm sure as heck not going to replace it with you crappy nic and unfinished drivers. Thanks for nothing. Next notebook I buy is going to be AMD powered.

    • Re:Don't bother yet, its not finished (Score:5, Insightful)

      by Neophytus ( 642863 ) * on Wednesday March 10, 2004 @11:51AM (#8522015)
      and that's why it hasn't been announced apart to a list mainly inhabited by developers
    • Looks like you didn't do your pre-sales research. I did, so I am running a Thinkpad X31 with a Cisco 350 miniPCI wireless card. EVERYTHING on this laptop is supported except hot dock/undock. There is a partially closed driver installed for the slmodem, but since I haven't actually used the modem outside of a quick test it isn't a critical issue. I also have to disable AGP video access when on battery power to avoid a problem with suspend, but it works fine when I'm docked.

      And yes I made damned sure the
  • And building their own driver.

    Like the eepro100 driver from before? Or those Texas Instruments wireless chipsets in the DLink 650+? And a whole mess of other drivers for other devices from hardware companies that won't release technical specifications. Heck, are Broadcom 11g drivers out yet?

  • Good news, but... (Score:3, Interesting)

    by biendamon ( 723952 ) on Wednesday March 10, 2004 @11:51AM (#8522021)
    ...I'm curious why it took so long for this to finally happen. Intel knew, for a long time, that there was extensive interest.

    The Centrino is a good chipset, and Centrino-based laptops are fairly popular. Even without the wireless support, I've been happy using a Linux-based Centrino laptop for the last six months. The lack of wireless access was the one thing that had been sticking in my craw.

    Now, I'll be able to unequivocally recommend these laptops to friends who use Linux. This will mean more sales for Intel. This, I would think, would be considered a Good Thing (tm). So why the wait?

  • Wireless extensions (Score:2, Interesting)

    by fdawg ( 22521 )
    Anyone know if this implementation uses wireless extensions? Will these drivers use iwconfig and the rest of wireless tool or will you have to use some proprietary intel (probably binary only) tools? If it doesnt use wireless extensions, all of the neat scripts that come with stock distributions (debian, redhat, etc) wont work without some modification.

  • Open Source?? (Score:3, Funny)

    by Stiletto ( 12066 ) on Wednesday March 10, 2004 @12:06PM (#8522131)
    If it's like many "open source with firmware" drivers, it's probably a lot like this:


    unsigned char firmware[] = { 0x22, 0x45, ...[many thousands of bytes].... };

    void driver(void)
    {
    run_firmware(firmware);
    }

    Uh, yea, I'd consider that open source all right...

    • Re:Open Source?? (Score:3, Informative)

      by michich ( 679957 )

      In a post to LKML James Ketrenos said this:

      Yes, it is really firmware. It is loaded from disk as a block of data and passed to the card. The system CPU doesn't execute anything out of the firmware, nor does the firmware know anything about the kernel.

    • Re:Open Source?? (Score:5, Informative)

      by T5 ( 308759 ) on Wednesday March 10, 2004 @01:20PM (#8523073)
      Keyspan [keyspan.com] USB to serial converters are like this as well. This sparked a lot of debate on lkml on whether the firmware, clearly not open source, could be included in the kernel driver code. The upshot of that lengthy discussion [debian.org] was that yes, firmware can be bundled in the kernel code since it's not actually run by the host processor that's running the kernel.

  • *BSD Driver? (Score:5, Interesting)

    by nurb432 ( 527695 ) on Wednesday March 10, 2004 @12:17PM (#8522225) Homepage Journal
    Thats really nice the released for linux, but how about us FBSD folks.. or are we out of luck on this one...

    • Re:*BSD Driver? (Score:3, Informative)

      by Imperator ( 17614 )
      Well since they're giving you a closed firmware with an open interface, presumably you can code a driver to it. Or you can just port the Linux driver.

  • not excited (Score:4, Insightful)

    by asv108 ( 141455 ) <asv@i[ ]s.com ['vos' in gap]> on Wednesday March 10, 2004 @12:18PM (#8522253) Homepage Journal
    Only a year after there was an official announcement for linux drivers, which was later recanted, intel releases incomplete drivers. I'm sorry but Intel could of handled this situation a LOT better. I feel really sorry for the people who have had a "centrino" laptop for the past year and a useless wifi card.

    When I purchased my X31 from IBM a year ago, instead of going for a wireless option, I bought the machine "wireless rdy" and put in my own linux compatible prism2 minipci card, purchased off ebay. Because of this incident, I will certainly stay away from purchasing any item from intel where linux support is promised in the near future.

    Hopefully companies like Intel will start to realize that Desktop Linux is here and people who are decision makers & influencer's in IT make up a significant portion of the desktop linux populous.

  • Open source? (Score:4, Informative)

    by Anonymous Coward on Wednesday March 10, 2004 @12:28PM (#8522407)
    More like an open-source interface to a closed-source firmware.
    You still have to go here [sf.net], agree to a EULA and download a binary image to be able to use this module (I found it humorous that Intel's download site admonished me for using Firefox on linux, and suggested I upgrade to IE6 or NS6).
    You use the driver by doing:
    modprobe ipw2100 firmware=/usr/share/firmware/ipw2100-1.0.fw
    where ipw2100-1.0.fw is the current binary firmware image.

    • Re:Open source? (Score:3, Insightful)

      by kju ( 327 )
      This is utter nonsense. Prism54 is utilizing firmware as well, as do a bunch of other linux drivers. Every fricking wlan card out there has a firmware, it happens only that in the past most had the firmware flashed on the card / into the hardware, while nowadays the firmware is loaded by the driver into the card at runtime. Which is better, as upgrading the driver can (and will often) update the firmware too, without having to reflash first.

      Somewhere you need to draw a line, and having firmware is nothing

    • Re:Open source? (Score:3, Insightful)

      by dmaxwell ( 43234 )
      At least the firmware approach means that the drivers will work on non-x86 arches as well. I realize that video cards are whole nother kettle of fish but it would be nice if video cards just exposed a 3D api and all the interesting stuff happened on the card itself. It would be more optimal that what nvidia does now. Yeah it would be nice if the entire piece of hardware was open but least this approach lets us treat the hardware as a periphreal and not a black box that gets chucked into the kernel.

Slashdot Top Deals

On a clear disk you can seek forever. -- P. Denning

Close