[Request] b43 broadcom wireless backport from linux-next.

DeltaKilo · 2014-08-16 09:32:41

Linux-next brings many improvements to b43 driver as well as a plenty of new devices support, see: http://wireless.kernel.org/en/users/Dri … ed_devices. OpenWRT devs already backported it but these patches currently don't land properly on Arch kernels. See 800-section of https://dev.openwrt.org/browser/trunk/p … 11/patches
Broadcom wireless is a pain for its users for years, so i think it would be cool to backport it to linux and linux-lts kernels for at least to better prerelease testing and early feedback not even mention that pain to cease & desist as early as possible.
UPD: currently testing nightly build of OpenWRT on my Netgear 3500L/U/v2 powered by BCM4718 and it works great and thanks god support N-mode on b43 driver. Can't wait to bring new driver on my BCM43227 powered laptop that not supported by current b43.

Last edited by DeltaKilo (2014-08-16 09:51:18)

jdbrown · 2014-08-16 09:51:57

AFAIK Arch tends to ship vanilla software. So backporting drivers can be greatly against that philosophy.

Also, you can always get the newest software when you use arch. You can just wait until 3.17 releases in 2 or 3 months. One of the reasons that many other distributions backport drivers is that they don't upgrade their kernel to a newer major version. Apparently, that's invalid for Arch.

If you really want to try the cool features of new drivers, you can apply patches yourself and build your own kernel. I sometimes build patched software myself when I'm not satisfied with the ones in repo.

DeltaKilo · 2014-08-16 10:22:14

jdbrown wrote:

AFAIK Arch tends to ship vanilla software. So backporting drivers can be greatly against that philosophy.

We are now speaking in the AUR section.
I do think AUR intended to solve real problems and satisfy user needs. That one is the real pain, and i believe that it will find userbase at least in midterm for lts kernel, while for regular one, we are(users of BCM wireless) definedly need as much testing as possible.
You cannot even imagine that black magic to install system with wireless only connection without that weird and only online BLOB or lack of Wireless-N for the most of supported devices.

Lone_Wolf · 2014-08-16 11:34:18

DeltaKilo,

A solution more in line with The Arch Way would be to build linux-next yourself and use that.
There is a linux-next package in AUR, although it may need updating.

DeltaKilo · 2014-08-16 12:08:57

Lone_Wolf wrote:

DeltaKilo,
A solution more in line with The Arch Way would be to build linux-next yourself and use that.

I did not post that to question is this an Arch Way or not. I believe that Arch Way is to be KISS and to be close to developers. My solution hits both. And an undocumented thing in Arch Way is that Arch is for power users. Most power users of broadcom hardware, as i think, needs that patch published on that forum on an AUR, no matters. I've post that to find any collaboration cause beeing rails developer and not programming in C for 10y from the 1st term of university and obviously haven't enought skills in kernel programming.
Personally, I'll be satisfied if someone just adapt these patches for Arch kernel here.

tomk · 2014-08-16 12:29:31

I don't think you're making yourself clear. You say that linux-next brings b43 improvements, so why not just use linux-next from the AUR? You don't need C programming skills to build an AUR package.

Another way of getting newer drivers is by building them from the backports project, but imo the package above would be easier.

DeltaKilo · 2014-08-16 12:34:53

tomk wrote:

I don't think you're making yourself clear.

Do you think i'm handless Ubuntu intruder?
I just want to use stable kernel with the new broadcom wireless stack not having problems with nvidia or virtualbox modules. There are plenty strange bloatware packages in aur, why not to add new one?

tomk · 2014-08-16 12:38:24

OK sure - go ahead.

jdbrown · 2014-08-16 13:21:28

DeltaKilo wrote:

I did not post that to question is this an Arch Way or not. I believe that Arch Way is to be KISS and to be close to developers. My solution hits both. And an undocumented thing in Arch Way is that Arch is for power users. Most power users of broadcom hardware, as i think, needs that patch published on that forum on an AUR, no matters. I've post that to find any collaboration cause beeing rails developer and not programming in C for 10y from the 1st term of university and obviously haven't enought skills in kernel programming.
Personally, I'll be satisfied if someone just adapt these patches for Arch kernel here.

Well, you get some point here. But I guess putting the patch on AUR may not be worthwhile. First, the package will become pointless as soon as linux 3.17 hits the repo. Second, the support added in 3.17 is (in my mind, maybe wrong) not that significant (only four models added, and at least my BCM43142 is still not supported yet so I have to stick to proprietary blobs). Third, if that package is going to be well-maintained, it has to follow each minor releases as the repo does. That's a lot of effort which may not benefit a lot of people or for a long time.

So IMHO backporting that driver and put it to AUR may not worth it. But I don't mind if someone is willing to make that effort.

Arch Linux

#1 2014-08-16 09:32:41

[Request] b43 broadcom wireless backport from linux-next.

#2 2014-08-16 09:51:57

Re: [Request] b43 broadcom wireless backport from linux-next.

#3 2014-08-16 10:22:14

Re: [Request] b43 broadcom wireless backport from linux-next.

#4 2014-08-16 11:34:18

Re: [Request] b43 broadcom wireless backport from linux-next.

#5 2014-08-16 12:08:57

Re: [Request] b43 broadcom wireless backport from linux-next.

#6 2014-08-16 12:29:31

Re: [Request] b43 broadcom wireless backport from linux-next.

#7 2014-08-16 12:34:53

Re: [Request] b43 broadcom wireless backport from linux-next.

#8 2014-08-16 12:38:24

Re: [Request] b43 broadcom wireless backport from linux-next.

#9 2014-08-16 13:21:28

Re: [Request] b43 broadcom wireless backport from linux-next.

Board footer