Current status of rt2800usb and staging/rt2870
Hi,
In 2.6.31, there are USB device IDs common between both drivers. Should a distribution enable both drivers? What do you suggest? Are there any *known issues* stuff for one of them?
Regards, thanks
Ozan Caglayan
Hi,
Quoted 1 line
In 2.6.31, there are USB device IDs common between both drivers.
That is because they are drivers for the same hardware.
Quoted 2 lines
Should a distribution enable both drivers? What do you suggest? Are there any *known issues* stuff for one of them?
The staging/rt2870 should actually be removed from the kernel tree, I am going to merge rt2800pci soon as well and after that I'll send a patch to remove all Ralink drivers from the staging tree.
As for known issues:
- staging/rt2870 is a piece of crap which apparently works for some people but isn't generally stable or reliable
- wireless/rt2800usb follows the kernel coding style/rules and uses mac80211 but isn't showing a high quality for usability.
Ivo
Hi,
Quoted 5 lines · On Tuesday 13 October 2009 13:24:48 Ozan Çağlayan wrote:
Hi,
In 2.6.31, there are USB device IDs common between both drivers. Should a distribution enable both drivers? What do you suggest? Are there any *known issues* stuff for one of them?
My advice to distributions for such situations is to ship both but make one driver the default one. This provides users with better overall hardware coverage and flexibility. Additionally by providing the ability for direct comparison of both drivers it makes driver authors/maintainers try really hard at making the final solution work for everybody (instead of just making it work for their needs only etc.).
Best regards,
Bartlomiej
Quoted 1 line · On Tuesday 13 October 2009 17:52:52 Ivo van Doorn wrote:
I am going to merge rt2800pci soon as well and after that I'll send a patch
Great, I've been waiting for this for a long time.
Quoted 1 line
to remove all Ralink drivers from the staging tree.
Till new drivers obtain support for all hardware currently covered by the unified staging drivers the latter shouldn't be removed as they serve well their role as a temporary solution allowing real Linux users to user their real hardware and as a reference material for developers willing to work on adding the missing bits to new drivers.
Best regards,
Bartlomiej
Quoted 6 lines · Bartlomiej Zolnierkiewicz
Quoted 1 line · On Tuesday 13 October 2009 17:52:52 Ivo van Doorn wrote:
I am going to merge rt2800pci soon as well and after that I'll send a patch
Great, I've been waiting for this for a long time.
Quoted 7 lines
Quoted 1 line
to remove all Ralink drivers from the staging tree.
Till new drivers obtain support for all hardware currently covered by the unified staging drivers the latter shouldn't be removed as they serve well their role as a temporary solution allowing real Linux users to user their real hardware and as a reference material for developers willing to work on adding the missing bits to new drivers.
The rt2800pci and rt2800usb drivers cover support for rt2860/rt2870/rt3070 devices, which are present as individual drivers in the staging tree. So far it only managed to confuse developers which wanted to work on Ralink support, so I haven't found a benefit for having those drivers in the staging tree yet. But I am sure there are plenty of people who like the idea of having the original Ralink drivers inside the staging tree, so they can continue debugging that, so I won't talk about the staging downsides further. Ivo
Quoted 9 lines · On Tuesday 13 October 2009 20:17:47 Ivo van Doorn wrote:
Quoted 8 lines · Bartlomiej Zolnierkiewicz
Quoted 1 line · On Tuesday 13 October 2009 17:52:52 Ivo van Doorn wrote:
I am going to merge rt2800pci soon as well and after that I'll send a patch
Great, I've been waiting for this for a long time.
Quoted 1 line
to remove all Ralink drivers from the staging tree.
Quoted 8 lines
Quoted 5 lines
Till new drivers obtain support for all hardware currently covered by the unified staging drivers the latter shouldn't be removed as they serve well their role as a temporary solution allowing real Linux users to user their real hardware and as a reference material for developers willing to work on adding the missing bits to new drivers.
The rt2800pci and rt2800usb drivers cover support for rt2860/rt2870/rt3070 devices, which are present as individual drivers in the staging tree. So far it only managed
There are no longer individual drivers.
Instead there is one shared source code and two device drivers:
- rt2860 covering RT2860 and RT3090 devices
- rt2870 covering RT2870 and RT3070 devices
In comparison rt2800usb currently lacks RT3070 support and rt2800pci's RT3090 support is basic at best (not to mention that it didn't work for RT2860 last time that I tried)..
Quoted 1 line
to confuse developers which wanted to work on Ralink support, so I haven't found
I bet they are truly grateful for being shown "the one and only way"..
Quoted 1 line
a benefit for having those drivers in the staging tree yet. But I am sure there are plenty
I was able to use my Eee 901 successfully with them for a last year and I'm pretty sure that I'm not the only. I understand my sin now -- I should have had help in fixing the proper and clean code before using my hardware.. [*]
Quoted 2 lines
of people who like the idea of having the original Ralink drivers inside the staging tree, so they can continue debugging that, so I won't talk about the staging downsides further.
Well, it would be much more productive if people concentrate on improving _their_ projects and looking at downsides of _their_ code instead of going around and looking at _obvious_ downsides of other people's projects.
[*] [Slightly off-topic but it shows the same problem with the approach]
I now also see why some distributions keep pushing some known non-working things on their users (Fedora maintainers -- I'm talking to you), the best example is PulseAudio -- it simply doesn't work reliably even on modern hardware and/or using all scheduler tricks (it seems that making Linux into full RT OS is a prerequisite for fixing latency issues observed)..
So yeah desktop/laptop/mobile users, do not worry -- you will get your sound support back in few years time and if you're developer: don't dare to complain you fussy saboteur!!
Quoted 10 lines
Quoted 2 lines
The rt2800pci and rt2800usb drivers cover support for rt2860/rt2870/rt3070 devices, which are present as individual drivers in the staging tree. So far it only managed
There are no longer individual drivers.
Instead there is one shared source code and two device drivers:
- rt2860 covering RT2860 and RT3090 devices
- rt2870 covering RT2870 and RT3070 devices
Cool, now you only need somebody to update those drivers to mac80211, and you can merge those drivers to the main drivers/net/wireless/ folder.
Can't be more happy with this progress, since that means I can finally abandon rt2800pci and rt2800usb which have been nothing more then a pain.
Ivo
P.S.
It is up to you to decide if this mail was intented as serious, sarcastic or pointless ranting.
Quoted 27 lines · Bartlomiej Zolnierkiewicz
Quoted 9 lines · On Tuesday 13 October 2009 20:17:47 Ivo van Doorn wrote:
Quoted 8 lines · Bartlomiej Zolnierkiewicz
Quoted 1 line · On Tuesday 13 October 2009 17:52:52 Ivo van Doorn wrote:
I am going to merge rt2800pci soon as well and after that I'll send a patch
Great, I've been waiting for this for a long time.
Quoted 1 line
to remove all Ralink drivers from the staging tree.
Quoted 8 lines
Quoted 5 lines
Till new drivers obtain support for all hardware currently covered by the unified staging drivers the latter shouldn't be removed as they serve well their role as a temporary solution allowing real Linux users to user their real hardware and as a reference material for developers willing to work on adding the missing bits to new drivers.
The rt2800pci and rt2800usb drivers cover support for rt2860/rt2870/rt3070 devices, which are present as individual drivers in the staging tree. So far it only managed
There are no longer individual drivers.
Instead there is one shared source code and two device drivers:
- rt2860 covering RT2860 and RT3090 devices
- rt2870 covering RT2870 and RT3070 devices
Quoted 7 lines
In comparison rt2800usb currently lacks RT3070 support and rt2800pci's RT3090 support is basic at best (not to mention that it didn't work for RT2860 last time that I tried)..
Quoted 1 line
to confuse developers which wanted to work on Ralink support, so I haven't found
I bet they are truly grateful for being shown "the one and only way"..
There *is* only one way: mac80211. If the driver is softmac, but does not use mac82011, then it *is* the wrong way. We will not have multiple 802.11 stacks in the mainstream kernel. If a softmac driver uses mac80211, hey, that's great! Lets add it!
If it doesn't, then that driver needs to be updated to use mac80211. Period.
Quoted 5 lines
Quoted 1 line
a benefit for having those drivers in the staging tree yet. But I am sure there are plenty
I was able to use my Eee 901 successfully with them for a last year and I'm pretty sure that I'm not the only. I understand my sin now -- I should have had help in fixing the proper and clean code before using my hardware.. [*]
That's nice, and everyone appreciates the work that you've done. Nobody can tell you what to work on, but it would be nice to get more people working on the *mac80211* versions of the various drivers. Imagine how much better rt2x00 would be if all the effort that had gone into cleanup up the ralink vendor drivers had instead gone into making rt2x00 work on the new hardware. Then you'd have cfg80211 support, background scanning, etc all for free with no effort on your part.
Maybe it would have taken 6 months longer to get good support for your hardware but at least the work would have a future. But now we're stuck in a situation where either:
1) the vendor driver never gets converted to cfg80211/mac80211, and stays in staging forever, or finally gets booted out of staging because nobody is working on converting it to mac80211. mac80211/cfg80211 is a hard requirement for being an accepted wireless driver. And drivers do have a shelf-life in staging.
2) the vendor driver starts getting converted to use mac80211. But I would argue that a better use of *anyone's* time is to make rt2x00 better, instead of porting the ralink vendor drivers to mac80211. It would probably take less time to fix up rt2x00 for new hardware than to port the ralink vendor drivers to mac80211.
Quoted 8 lines
Quoted 2 lines
of people who like the idea of having the original Ralink drivers inside the staging tree, so they can continue debugging that, so I won't talk about the staging downsides further.
Well, it would be much more productive if people concentrate on improving _their_ projects and looking at downsides of _their_ code instead of going around and looking at _obvious_ downsides of other people's projects.
Quoted 7 lines
[*] [Slightly off-topic but it shows the same problem with the approach]
I now also see why some distributions keep pushing some known non-working things on their users (Fedora maintainers -- I'm talking to you), the best example is PulseAudio -- it simply doesn't work reliably even on modern hardware and/or using all scheduler tricks (it seems that making Linux into full RT OS is a prerequisite for fixing latency issues observed)..
Pulseaudio works for many, many people. The most productive use of your time here is to file a bug report with the specific details of your audio chipset, let upstream diagnose whether it's a Pulseaudio-specific problem, a codec driver problem, or an ALSA problem.
You can wait until the cows come home to deploy new technology, and then of course you'll still have to fix up all the bugs because you waited too long and nobody was testing it, or you can deploy new technology that works for most people and fix those bugs much earlier. Release early, release often. The tricky thing is how early.
Dan
Quoted 6 lines · Bartlomiej Zolnierkiewicz
Hi,
Quoted 2 lines · On Tuesday 13 October 2009 13:24:48 Ozan Çağlayan wrote:
Hi,
Quoted 7 lines
Quoted 4 lines
In 2.6.31, there are USB device IDs common between both drivers. Should a distribution enable both drivers? What do you suggest? Are there any *known issues* stuff for one of them?
My advice to distributions for such situations is to ship both but make one driver the default one.
By saying to make one driver the default one, you mean avoiding the other from getting probed automatically by clearing the device id tables?
Quoted 9 lines · On Tuesday 13 October 2009 22:00:48 Ivo van Doorn wrote:
Quoted 9 lines
Quoted 2 lines
The rt2800pci and rt2800usb drivers cover support for rt2860/rt2870/rt3070 devices, which are present as individual drivers in the staging tree. So far it only managed
There are no longer individual drivers.
Instead there is one shared source code and two device drivers:
- rt2860 covering RT2860 and RT3090 devices
Quoted 7 lines
Quoted 1 line
- rt2870 covering RT2870 and RT3070 devices
Cool, now you only need somebody to update those drivers to mac80211, and you can merge those drivers to the main
drivers/net/wireless/folder.Can't be more happy with this progress, since that means I can finally abandon rt2800pci and rt2800usb which have been nothing more then a pain.
I will be glad to take over the maintenance of those two drivers if this is so burdensome for you..
Quoted 12 lines · On Tuesday 13 October 2009 22:41:50 Ozan Çağlayan wrote:
Quoted 11 lines · Bartlomiej Zolnierkiewicz
Hi,
Quoted 6 lines · On Tuesday 13 October 2009 13:24:48 Ozan Çağlayan wrote:
Hi,
In 2.6.31, there are USB device IDs common between both drivers. Should a distribution enable both drivers? What do you suggest? Are there any *known issues* stuff for one of them?
Quoted 5 lines
Quoted 2 lines
My advice to distributions for such situations is to ship both but make one driver the default one.
By saying to make one driver the default one, you mean avoiding the other from getting probed automatically by clearing the device id tables?
Yes but rather using /etc/modprobe.d/blacklist.conf than clearing id tables so it is easier to switch drivers..
Quoted 32 lines · On Tuesday 13 October 2009 22:15:40 Dan Williams wrote:
Quoted 31 lines · Bartlomiej Zolnierkiewicz
Quoted 9 lines · On Tuesday 13 October 2009 20:17:47 Ivo van Doorn wrote:
Quoted 8 lines · Bartlomiej Zolnierkiewicz
Quoted 1 line · On Tuesday 13 October 2009 17:52:52 Ivo van Doorn wrote:
I am going to merge rt2800pci soon as well and after that I'll send a patch
Great, I've been waiting for this for a long time.
Quoted 1 line
to remove all Ralink drivers from the staging tree.
Quoted 8 lines
Quoted 5 lines
Till new drivers obtain support for all hardware currently covered by the unified staging drivers the latter shouldn't be removed as they serve well their role as a temporary solution allowing real Linux users to user their real hardware and as a reference material for developers willing to work on adding the missing bits to new drivers.
The rt2800pci and rt2800usb drivers cover support for rt2860/rt2870/rt3070 devices, which are present as individual drivers in the staging tree. So far it only managed
There are no longer individual drivers.
Instead there is one shared source code and two device drivers:
- rt2860 covering RT2860 and RT3090 devices
- rt2870 covering RT2870 and RT3070 devices
In comparison rt2800usb currently lacks RT3070 support and rt2800pci's RT3090 support is basic at best (not to mention that it didn't work for RT2860 last time that I tried)..
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
to confuse developers which wanted to work on Ralink support, so I haven't found
I bet they are truly grateful for being shown "the one and only way"..
There *is* only one way: mac80211. If the driver is softmac, but does not use mac82011, then it *is* the wrong way. We will not have multiple 802.11 stacks in the mainstream kernel. If a softmac driver uses mac80211, hey, that's great! Lets add it!
Nobody never ever suggested merging Ralink drivers as they are into kernel proper.
Quoted 9 lines
If it doesn't, then that driver needs to be updated to use mac80211. Period.
Quoted 5 lines
Quoted 1 line
a benefit for having those drivers in the staging tree yet. But I am sure there are plenty
I was able to use my Eee 901 successfully with them for a last year and I'm pretty sure that I'm not the only. I understand my sin now -- I should have had help in fixing the proper and clean code before using my hardware.. [*]
Quoted 7 lines
That's nice, and everyone appreciates the work that you've done. Nobody can tell you what to work on, but it would be nice to get more people working on the *mac80211* versions of the various drivers. Imagine how much better rt2x00 would be if all the effort that had gone into cleanup up the ralink vendor drivers had instead gone into making rt2x00 work on the new hardware. Then you'd have cfg80211 support, background scanning, etc all for free with no effort on your part.
No effort, right. Debugging things is the hardest part of any project..
Quoted 2 lines
Maybe it would have taken 6 months longer to get good support for your hardware but at least the work would have a future. But now we're stuck
You miss one tiny and irrelevant detail. Until the work is finished I cannot use the hardware and real testers/users are using the vendor driver anyway for the simple fact that it exists and works.
Quoted 8 lines
in a situation where either:
1) the vendor driver never gets converted to cfg80211/mac80211, and stays in staging forever, or finally gets booted out of staging because nobody is working on converting it to mac80211. mac80211/cfg80211 is a hard requirement for being an accepted wireless driver. And drivers do have a shelf-life in staging.
Quoted 5 lines
2) the vendor driver starts getting converted to use mac80211. But I would argue that a better use of *anyone's* time is to make rt2x00 better, instead of porting the ralink vendor drivers to mac80211. It would probably take less time to fix up rt2x00 for new hardware than to port the ralink vendor drivers to mac80211.
Nobody is saying anything about porting the vendor drivers to mac80211.
3) After the vendor driver gets cleaned up to the point that people are able to make any sense out of it the missing bits will get added to rt2x00. Several months later (after all current users are happy with the improved drivers) the old drivers will be removed from staging..
Quoted 10 lines
Quoted 10 lines
Quoted 2 lines
of people who like the idea of having the original Ralink drivers inside the staging tree, so they can continue debugging that, so I won't talk about the staging downsides further.
Well, it would be much more productive if people concentrate on improving _their_ projects and looking at downsides of _their_ code instead of going around and looking at _obvious_ downsides of other people's projects.
[*] [Slightly off-topic but it shows the same problem with the approach]
Quoted 7 lines
Quoted 5 lines
I now also see why some distributions keep pushing some known non-working things on their users (Fedora maintainers -- I'm talking to you), the best example is PulseAudio -- it simply doesn't work reliably even on modern hardware and/or using all scheduler tricks (it seems that making Linux into full RT OS is a prerequisite for fixing latency issues observed)..
Pulseaudio works for many, many people. The most productive use of your
Yeah, I trust you on both points..
Quoted 3 lines
time here is to file a bug report with the specific details of your audio chipset, let upstream diagnose whether it's a Pulseaudio-specific problem, a codec driver problem, or an ALSA problem.
Right..
I see no point BTW -- time make proper bug-report is much bigger than throwing in few local hacks and since my experience with upstream so far was that my bug-reports end up in some black-hole I deal with issues in the most pragmatic and productive for everybody way..
Quoted 5 lines
You can wait until the cows come home to deploy new technology, and then of course you'll still have to fix up all the bugs because you waited too long and nobody was testing it, or you can deploy new technology that works for most people and fix those bugs much earlier. Release early, release often. The tricky thing is how early.
It was new technology in F8 days.. It was included in F9 (released on 13th May 2008) and the current rawhide is still broken (no chance it will get fixed for F12).. Getting stereo sound to play skip-lessly on standard AC97 or HDA cards on a freshly installed system is impossible..
Other distributions are really not that much better (to be honest with Fedora it is the bleeding edge by definition) as their mode of operations sometimes consists of copying features (regardless of the quality and current state) from other distributions just for the sake of to not staying behind eventually..
Quoted 134 lines · Bartlomiej Zolnierkiewicz
Quoted 32 lines · On Tuesday 13 October 2009 22:15:40 Dan Williams wrote:
Quoted 31 lines · Bartlomiej Zolnierkiewicz
Quoted 9 lines · On Tuesday 13 October 2009 20:17:47 Ivo van Doorn wrote:
Quoted 8 lines · Bartlomiej Zolnierkiewicz
Quoted 1 line · On Tuesday 13 October 2009 17:52:52 Ivo van Doorn wrote:
I am going to merge rt2800pci soon as well and after that I'll send a patch
Great, I've been waiting for this for a long time.
Quoted 1 line
to remove all Ralink drivers from the staging tree.
Quoted 8 lines
Quoted 5 lines
Till new drivers obtain support for all hardware currently covered by the unified staging drivers the latter shouldn't be removed as they serve well their role as a temporary solution allowing real Linux users to user their real hardware and as a reference material for developers willing to work on adding the missing bits to new drivers.
The rt2800pci and rt2800usb drivers cover support for rt2860/rt2870/rt3070 devices, which are present as individual drivers in the staging tree. So far it only managed
There are no longer individual drivers.
Instead there is one shared source code and two device drivers:
- rt2860 covering RT2860 and RT3090 devices
- rt2870 covering RT2870 and RT3070 devices
In comparison rt2800usb currently lacks RT3070 support and rt2800pci's RT3090 support is basic at best (not to mention that it didn't work for RT2860 last time that I tried)..
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
to confuse developers which wanted to work on Ralink support, so I haven't found
I bet they are truly grateful for being shown "the one and only way"..
There *is* only one way: mac80211. If the driver is softmac, but does not use mac82011, then it *is* the wrong way. We will not have multiple 802.11 stacks in the mainstream kernel. If a softmac driver uses mac80211, hey, that's great! Lets add it!
Nobody never ever suggested merging Ralink drivers as they are into kernel proper.
Quoted 9 lines
If it doesn't, then that driver needs to be updated to use mac80211. Period.
Quoted 5 lines
Quoted 1 line
a benefit for having those drivers in the staging tree yet. But I am sure there are plenty
I was able to use my Eee 901 successfully with them for a last year and I'm pretty sure that I'm not the only. I understand my sin now -- I should have had help in fixing the proper and clean code before using my hardware.. [*]
Quoted 7 lines
That's nice, and everyone appreciates the work that you've done. Nobody can tell you what to work on, but it would be nice to get more people working on the *mac80211* versions of the various drivers. Imagine how much better rt2x00 would be if all the effort that had gone into cleanup up the ralink vendor drivers had instead gone into making rt2x00 work on the new hardware. Then you'd have cfg80211 support, background scanning, etc all for free with no effort on your part.
No effort, right. Debugging things is the hardest part of any project..
Quoted 2 lines
Maybe it would have taken 6 months longer to get good support for your hardware but at least the work would have a future. But now we're stuck
You miss one tiny and irrelevant detail. Until the work is finished I cannot use the hardware and real testers/users are using the vendor driver anyway for the simple fact that it exists and works.
Quoted 8 lines
in a situation where either:
1) the vendor driver never gets converted to cfg80211/mac80211, and stays in staging forever, or finally gets booted out of staging because nobody is working on converting it to mac80211. mac80211/cfg80211 is a hard requirement for being an accepted wireless driver. And drivers do have a shelf-life in staging.
Quoted 5 lines
2) the vendor driver starts getting converted to use mac80211. But I would argue that a better use of *anyone's* time is to make rt2x00 better, instead of porting the ralink vendor drivers to mac80211. It would probably take less time to fix up rt2x00 for new hardware than to port the ralink vendor drivers to mac80211.
Nobody is saying anything about porting the vendor drivers to mac80211.
3) After the vendor driver gets cleaned up to the point that people are able to make any sense out of it the missing bits will get added to rt2x00. Several months later (after all current users are happy with the improved drivers) the old drivers will be removed from staging..
Quoted 10 lines
Quoted 10 lines
Quoted 2 lines
of people who like the idea of having the original Ralink drivers inside the staging tree, so they can continue debugging that, so I won't talk about the staging downsides further.
Well, it would be much more productive if people concentrate on improving _their_ projects and looking at downsides of _their_ code instead of going around and looking at _obvious_ downsides of other people's projects.
[*] [Slightly off-topic but it shows the same problem with the approach]
Quoted 7 lines
Quoted 5 lines
I now also see why some distributions keep pushing some known non-working things on their users (Fedora maintainers -- I'm talking to you), the best example is PulseAudio -- it simply doesn't work reliably even on modern hardware and/or using all scheduler tricks (it seems that making Linux into full RT OS is a prerequisite for fixing latency issues observed)..
Pulseaudio works for many, many people. The most productive use of your
Yeah, I trust you on both points..
Quoted 3 lines
time here is to file a bug report with the specific details of your audio chipset, let upstream diagnose whether it's a Pulseaudio-specific problem, a codec driver problem, or an ALSA problem.
Right..
I see no point BTW -- time make proper bug-report is much bigger than throwing in few local hacks and since my experience with upstream so far was that my bug-reports end up in some black-hole I deal with issues in the most pragmatic and productive for everybody way..
Quoted 5 lines
You can wait until the cows come home to deploy new technology, and then of course you'll still have to fix up all the bugs because you waited too long and nobody was testing it, or you can deploy new technology that works for most people and fix those bugs much earlier. Release early, release often. The tricky thing is how early.
It was new technology in F8 days.. It was included in F9 (released on 13th May 2008) and the current rawhide is still broken (no chance it will get fixed for F12).. Getting stereo sound to play skip-lessly on standard AC97 or HDA cards on a freshly installed system is impossible..
Quoted 10 lines
Other distributions are really not that much better (to be honest with Fedora it is the bleeding edge by definition) as their mode of operations sometimes consists of copying features (regardless of the quality and current state) from other distributions just for the sake of to not staying behind eventually..
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
I will make only a small comment on all this issue, from the point of view of a project admin, which writes little to no code at all in rt2x00.
Every once in a while, usually when Ralink releases new chipsets, there is the question of whether or not our rt2x00 project will support that new chipset.
Quoted 1 line
From being in the project since almost the beginning, and looking on
and off into the crap code, I do know how hard it is to port crap code into rt2x00.
That been said, i also know that with the complexity brought in by the new chipsets, it makes it even harder to port the code over.
But then there's the users, who bitch about everything and simply do not understand what it is at stake.
And all this is becoming way too messy for us to handle.
Personally all I see around me is people bitching and complaining, and no code being ported.
I've said this way too many times now, all code is welcome.
Since some days now, we have someone in the team which works for Ralink, I'm hopefull that he can find some time to help us make the driver better.
And now, i'm going back to my lovely hole, having added nothing to this conversation.
Luis Correia,
rt2x00 project admin
Quoted 129 lines · Bartlomiej Zolnierkiewicz
Quoted 32 lines · On Tuesday 13 October 2009 22:15:40 Dan Williams wrote:
Quoted 31 lines · Bartlomiej Zolnierkiewicz
Quoted 9 lines · On Tuesday 13 October 2009 20:17:47 Ivo van Doorn wrote:
Quoted 8 lines · Bartlomiej Zolnierkiewicz
Quoted 1 line · On Tuesday 13 October 2009 17:52:52 Ivo van Doorn wrote:
I am going to merge rt2800pci soon as well and after that I'll send a patch
Great, I've been waiting for this for a long time.
Quoted 1 line
to remove all Ralink drivers from the staging tree.
Quoted 8 lines
Quoted 5 lines
Till new drivers obtain support for all hardware currently covered by the unified staging drivers the latter shouldn't be removed as they serve well their role as a temporary solution allowing real Linux users to user their real hardware and as a reference material for developers willing to work on adding the missing bits to new drivers.
The rt2800pci and rt2800usb drivers cover support for rt2860/rt2870/rt3070 devices, which are present as individual drivers in the staging tree. So far it only managed
There are no longer individual drivers.
Instead there is one shared source code and two device drivers:
- rt2860 covering RT2860 and RT3090 devices
- rt2870 covering RT2870 and RT3070 devices
In comparison rt2800usb currently lacks RT3070 support and rt2800pci's RT3090 support is basic at best (not to mention that it didn't work for RT2860 last time that I tried)..
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
to confuse developers which wanted to work on Ralink support, so I haven't found
I bet they are truly grateful for being shown "the one and only way"..
There *is* only one way: mac80211. If the driver is softmac, but does not use mac82011, then it *is* the wrong way. We will not have multiple 802.11 stacks in the mainstream kernel. If a softmac driver uses mac80211, hey, that's great! Lets add it!
Nobody never ever suggested merging Ralink drivers as they are into kernel proper.
Quoted 9 lines
If it doesn't, then that driver needs to be updated to use mac80211. Period.
Quoted 5 lines
Quoted 1 line
a benefit for having those drivers in the staging tree yet. But I am sure there are plenty
I was able to use my Eee 901 successfully with them for a last year and I'm pretty sure that I'm not the only. I understand my sin now -- I should have had help in fixing the proper and clean code before using my hardware.. [*]
Quoted 7 lines
That's nice, and everyone appreciates the work that you've done. Nobody can tell you what to work on, but it would be nice to get more people working on the *mac80211* versions of the various drivers. Imagine how much better rt2x00 would be if all the effort that had gone into cleanup up the ralink vendor drivers had instead gone into making rt2x00 work on the new hardware. Then you'd have cfg80211 support, background scanning, etc all for free with no effort on your part.
No effort, right. Debugging things is the hardest part of any project..
Quoted 2 lines
Maybe it would have taken 6 months longer to get good support for your hardware but at least the work would have a future. But now we're stuck
You miss one tiny and irrelevant detail. Until the work is finished I cannot use the hardware and real testers/users are using the vendor driver anyway for the simple fact that it exists and works.
Quoted 8 lines
in a situation where either:
1) the vendor driver never gets converted to cfg80211/mac80211, and stays in staging forever, or finally gets booted out of staging because nobody is working on converting it to mac80211. mac80211/cfg80211 is a hard requirement for being an accepted wireless driver. And drivers do have a shelf-life in staging.
Quoted 5 lines
2) the vendor driver starts getting converted to use mac80211. But I would argue that a better use of *anyone's* time is to make rt2x00 better, instead of porting the ralink vendor drivers to mac80211. It would probably take less time to fix up rt2x00 for new hardware than to port the ralink vendor drivers to mac80211.
Nobody is saying anything about porting the vendor drivers to mac80211.
3) After the vendor driver gets cleaned up to the point that people are able to make any sense out of it the missing bits will get added to rt2x00. Several months later (after all current users are happy with the improved drivers) the old drivers will be removed from staging..
Quoted 10 lines
Quoted 10 lines
Quoted 2 lines
of people who like the idea of having the original Ralink drivers inside the staging tree, so they can continue debugging that, so I won't talk about the staging downsides further.
Well, it would be much more productive if people concentrate on improving _their_ projects and looking at downsides of _their_ code instead of going around and looking at _obvious_ downsides of other people's projects.
[*] [Slightly off-topic but it shows the same problem with the approach]
Quoted 7 lines
Quoted 5 lines
I now also see why some distributions keep pushing some known non-working things on their users (Fedora maintainers -- I'm talking to you), the best example is PulseAudio -- it simply doesn't work reliably even on modern hardware and/or using all scheduler tricks (it seems that making Linux into full RT OS is a prerequisite for fixing latency issues observed)..
Pulseaudio works for many, many people. The most productive use of your
Yeah, I trust you on both points..
Quoted 3 lines
time here is to file a bug report with the specific details of your audio chipset, let upstream diagnose whether it's a Pulseaudio-specific problem, a codec driver problem, or an ALSA problem.
Right..
I see no point BTW -- time make proper bug-report is much bigger than throwing in few local hacks and since my experience with upstream so far was that my bug-reports end up in some black-hole I deal with issues in the most pragmatic and productive for everybody way..
Quoted 5 lines
You can wait until the cows come home to deploy new technology, and then of course you'll still have to fix up all the bugs because you waited too long and nobody was testing it, or you can deploy new technology that works for most people and fix those bugs much earlier. Release early, release often. The tricky thing is how early.
Quoted 4 lines
It was new technology in F8 days.. It was included in F9 (released on 13th May 2008) and the current rawhide is still broken (no chance it will get fixed for F12).. Getting stereo sound to play skip-lessly on standard AC97 or HDA cards on a freshly installed system is impossible..
Really? That's not my experience with F11 or F12 on any of 5 different laptops from 5 different vendors. HP 2530p, Thinkpad T42, Dell D410, Fujitsu Lifebook P7230, Apple iBook G3/800. Sound just works, and I can switch between USB speakers, internal, headphone jack without manually screwing around with module parameters for the alsa default device and reloading them just to redirect sound where I want it to go. I can listen to Pandora via flash all day and that doesn't skip (except when the 3G dies, of course).
The point here is, often stuff works for some and not for others. That doesn't mean it's "broken". It's broken for you, and that should get fixed, but the whole system is by no means a loss and its pretty stupid to generalize things like "play skip-lessly on standard AC97/HDA cards is impossible" when it clearly isn't.
Dan
Quoted 144 lines · On Wednesday 14 October 2009 00:24:58 Dan Williams wrote:
Quoted 129 lines · Bartlomiej Zolnierkiewicz
Quoted 32 lines · On Tuesday 13 October 2009 22:15:40 Dan Williams wrote:
Quoted 31 lines · Bartlomiej Zolnierkiewicz
Quoted 9 lines · On Tuesday 13 October 2009 20:17:47 Ivo van Doorn wrote:
Quoted 8 lines · Bartlomiej Zolnierkiewicz
Quoted 1 line · On Tuesday 13 October 2009 17:52:52 Ivo van Doorn wrote:
I am going to merge rt2800pci soon as well and after that I'll send a patch
Great, I've been waiting for this for a long time.
Quoted 1 line
to remove all Ralink drivers from the staging tree.
Quoted 8 lines
Quoted 5 lines
Till new drivers obtain support for all hardware currently covered by the unified staging drivers the latter shouldn't be removed as they serve well their role as a temporary solution allowing real Linux users to user their real hardware and as a reference material for developers willing to work on adding the missing bits to new drivers.
The rt2800pci and rt2800usb drivers cover support for rt2860/rt2870/rt3070 devices, which are present as individual drivers in the staging tree. So far it only managed
There are no longer individual drivers.
Instead there is one shared source code and two device drivers:
- rt2860 covering RT2860 and RT3090 devices
- rt2870 covering RT2870 and RT3070 devices
In comparison rt2800usb currently lacks RT3070 support and rt2800pci's RT3090 support is basic at best (not to mention that it didn't work for RT2860 last time that I tried)..
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
to confuse developers which wanted to work on Ralink support, so I haven't found
I bet they are truly grateful for being shown "the one and only way"..
There *is* only one way: mac80211. If the driver is softmac, but does not use mac82011, then it *is* the wrong way. We will not have multiple 802.11 stacks in the mainstream kernel. If a softmac driver uses mac80211, hey, that's great! Lets add it!
Nobody never ever suggested merging Ralink drivers as they are into kernel proper.
Quoted 9 lines
If it doesn't, then that driver needs to be updated to use mac80211. Period.
Quoted 5 lines
Quoted 1 line
a benefit for having those drivers in the staging tree yet. But I am sure there are plenty
I was able to use my Eee 901 successfully with them for a last year and I'm pretty sure that I'm not the only. I understand my sin now -- I should have had help in fixing the proper and clean code before using my hardware.. [*]
Quoted 7 lines
That's nice, and everyone appreciates the work that you've done. Nobody can tell you what to work on, but it would be nice to get more people working on the *mac80211* versions of the various drivers. Imagine how much better rt2x00 would be if all the effort that had gone into cleanup up the ralink vendor drivers had instead gone into making rt2x00 work on the new hardware. Then you'd have cfg80211 support, background scanning, etc all for free with no effort on your part.
No effort, right. Debugging things is the hardest part of any project..
Quoted 2 lines
Maybe it would have taken 6 months longer to get good support for your hardware but at least the work would have a future. But now we're stuck
You miss one tiny and irrelevant detail. Until the work is finished I cannot use the hardware and real testers/users are using the vendor driver anyway for the simple fact that it exists and works.
Quoted 8 lines
in a situation where either:
1) the vendor driver never gets converted to cfg80211/mac80211, and stays in staging forever, or finally gets booted out of staging because nobody is working on converting it to mac80211. mac80211/cfg80211 is a hard requirement for being an accepted wireless driver. And drivers do have a shelf-life in staging.
Quoted 5 lines
2) the vendor driver starts getting converted to use mac80211. But I would argue that a better use of *anyone's* time is to make rt2x00 better, instead of porting the ralink vendor drivers to mac80211. It would probably take less time to fix up rt2x00 for new hardware than to port the ralink vendor drivers to mac80211.
Nobody is saying anything about porting the vendor drivers to mac80211.
3) After the vendor driver gets cleaned up to the point that people are able to make any sense out of it the missing bits will get added to rt2x00. Several months later (after all current users are happy with the improved drivers) the old drivers will be removed from staging..
Quoted 10 lines
Quoted 10 lines
Quoted 2 lines
of people who like the idea of having the original Ralink drivers inside the staging tree, so they can continue debugging that, so I won't talk about the staging downsides further.
Well, it would be much more productive if people concentrate on improving _their_ projects and looking at downsides of _their_ code instead of going around and looking at _obvious_ downsides of other people's projects.
[*] [Slightly off-topic but it shows the same problem with the approach]
Quoted 7 lines
Quoted 5 lines
I now also see why some distributions keep pushing some known non-working things on their users (Fedora maintainers -- I'm talking to you), the best example is PulseAudio -- it simply doesn't work reliably even on modern hardware and/or using all scheduler tricks (it seems that making Linux into full RT OS is a prerequisite for fixing latency issues observed)..
Pulseaudio works for many, many people. The most productive use of your
Yeah, I trust you on both points..
Quoted 3 lines
time here is to file a bug report with the specific details of your audio chipset, let upstream diagnose whether it's a Pulseaudio-specific problem, a codec driver problem, or an ALSA problem.
Right..
I see no point BTW -- time make proper bug-report is much bigger than throwing in few local hacks and since my experience with upstream so far was that my bug-reports end up in some black-hole I deal with issues in the most pragmatic and productive for everybody way..
Quoted 5 lines
You can wait until the cows come home to deploy new technology, and then of course you'll still have to fix up all the bugs because you waited too long and nobody was testing it, or you can deploy new technology that works for most people and fix those bugs much earlier. Release early, release often. The tricky thing is how early.
Quoted 4 lines
It was new technology in F8 days.. It was included in F9 (released on 13th May 2008) and the current rawhide is still broken (no chance it will get fixed for F12).. Getting stereo sound to play skip-lessly on standard AC97 or HDA cards on a freshly installed system is impossible..
Really? That's not my experience with F11 or F12 on any of 5 different laptops from 5 different vendors. HP 2530p, Thinkpad T42, Dell D410, Fujitsu Lifebook P7230, Apple iBook G3/800. Sound just works, and I can switch between USB speakers, internal, headphone jack without manually screwing around with module parameters for the alsa default device and reloading them just to redirect sound where I want it to go. I can listen to Pandora via flash all day and that doesn't skip (except when the 3G dies, of course).
Quoted 5 lines
The point here is, often stuff works for some and not for others. That doesn't mean it's "broken". It's broken for you, and that should get fixed, but the whole system is by no means a loss and its pretty stupid to generalize things like "play skip-lessly on standard AC97/HDA cards is impossible" when it clearly isn't.
Interesting, do you mean that you are able to get skipless mp3 playback under i.e. audacious (using the default pulseaudio output plugin) under heavy load (i.e. kernel build) with internal speakers (or headphones)?
If so must by my luck then -- F11 on old Acer laptop (Intel 8x0 in ICH4M) and fedora-rawhide on new Asus K50AB one (Intel HDA in AMD/ATI SB710)..
Quoted 23 lines · Bartlomiej Zolnierkiewicz
Quoted 9 lines · On Tuesday 13 October 2009 20:17:47 Ivo van Doorn wrote:
Quoted 8 lines · Bartlomiej Zolnierkiewicz
Quoted 1 line · On Tuesday 13 October 2009 17:52:52 Ivo van Doorn wrote:
I am going to merge rt2800pci soon as well and after that I'll send a patch
Great, I've been waiting for this for a long time.
Quoted 1 line
to remove all Ralink drivers from the staging tree.
Quoted 8 lines
Quoted 5 lines
Till new drivers obtain support for all hardware currently covered by the unified staging drivers the latter shouldn't be removed as they serve well their role as a temporary solution allowing real Linux users to user their real hardware and as a reference material for developers willing to work on adding the missing bits to new drivers.
The rt2800pci and rt2800usb drivers cover support for rt2860/rt2870/rt3070 devices, which are present as individual drivers in the staging tree. So far it only managed
There are no longer individual drivers.
Instead there is one shared source code and two device drivers:
Quoted 7 lines
- rt2860 covering RT2860 and RT3090 devices
- rt2870 covering RT2870 and RT3070 devices
In comparison rt2800usb currently lacks RT3070 support and rt2800pci's RT3090 support is basic at best (not to mention that it didn't work for RT2860 last time that I tried)..
(or RT2870 here)
Quoted 138 lines · Bartlomiej Zolnierkiewicz
Quoted 37 lines · On Tuesday 13 October 2009 22:15:40 Dan Williams wrote:
Quoted 36 lines · Bartlomiej Zolnierkiewicz
Quoted 16 lines · On Tuesday 13 October 2009 20:17:47 Ivo van Doorn wrote:
Quoted 6 lines · Bartlomiej Zolnierkiewicz
Quoted 2 lines · On Tuesday 13 October 2009 17:52:52 Ivo van Doorn wrote:
I am going to merge rt2800pci soon as well and after that I'll send a patch
Great, I've been waiting for this for a long time.
Quoted 8 lines
Quoted 1 line
to remove all Ralink drivers from the staging tree.
Till new drivers obtain support for all hardware currently covered by the unified staging drivers the latter shouldn't be removed as they serve well their role as a temporary solution allowing real Linux users to user their real hardware and as a reference material for developers willing to work on adding the missing bits to new drivers.
Quoted 3 lines
The rt2800pci and rt2800usb drivers cover support for rt2860/rt2870/rt3070 devices, which are present as individual drivers in the staging tree. So far it only managed
There are no longer individual drivers.
Instead there is one shared source code and two device drivers:
- rt2860 covering RT2860 and RT3090 devices
- rt2870 covering RT2870 and RT3070 devices
In comparison rt2800usb currently lacks RT3070 support and rt2800pci's RT3090 support is basic at best (not to mention that it didn't work for RT2860 last time that I tried)..
Quoted 2 lines
to confuse developers which wanted to work on Ralink support, so I haven't found
Quoted 6 lines
Quoted 1 line
I bet they are truly grateful for being shown "the one and only way"..
There *is* only one way: mac80211. If the driver is softmac, but does not use mac82011, then it *is* the wrong way. We will not have multiple 802.11 stacks in the mainstream kernel. If a softmac driver uses mac80211, hey, that's great! Lets add it!
Nobody never ever suggested merging Ralink drivers as they are into kernel proper.
Quoted 11 lines
If it doesn't, then that driver needs to be updated to use mac80211. Period.
Quoted 7 lines
Quoted 2 lines
a benefit for having those drivers in the staging tree yet. But I am sure there are plenty
I was able to use my Eee 901 successfully with them for a last year and I'm pretty sure that I'm not the only. I understand my sin now -- I should have had help in fixing the proper and clean code before using my hardware.. [*]
Quoted 7 lines
That's nice, and everyone appreciates the work that you've done. Nobody can tell you what to work on, but it would be nice to get more people working on the *mac80211* versions of the various drivers. Imagine how much better rt2x00 would be if all the effort that had gone into cleanup up the ralink vendor drivers had instead gone into making rt2x00 work on the new hardware. Then you'd have cfg80211 support, background scanning, etc all for free with no effort on your part.
No effort, right. Debugging things is the hardest part of any project..
Quoted 2 lines
Maybe it would have taken 6 months longer to get good support for your hardware but at least the work would have a future. But now we're stuck
You miss one tiny and irrelevant detail. Until the work is finished I cannot use the hardware and real testers/users are using the vendor driver anyway for the simple fact that it exists and works.
Quoted 8 lines
in a situation where either:
1) the vendor driver never gets converted to cfg80211/mac80211, and stays in staging forever, or finally gets booted out of staging because nobody is working on converting it to mac80211. mac80211/cfg80211 is a hard requirement for being an accepted wireless driver. And drivers do have a shelf-life in staging.
Quoted 5 lines
2) the vendor driver starts getting converted to use mac80211. But I would argue that a better use of *anyone's* time is to make rt2x00 better, instead of porting the ralink vendor drivers to mac80211. It would probably take less time to fix up rt2x00 for new hardware than to port the ralink vendor drivers to mac80211.
Nobody is saying anything about porting the vendor drivers to mac80211.
3) After the vendor driver gets cleaned up to the point that people are able to make any sense out of it the missing bits will get added to rt2x00. Several months later (after all current users are happy with the improved drivers) the old drivers will be removed from staging..
Quoted 13 lines
Quoted 13 lines
Quoted 3 lines
of people who like the idea of having the original Ralink drivers inside the staging tree, so they can continue debugging that, so I won't talk about the staging downsides further.
Well, it would be much more productive if people concentrate on improving _their_ projects and looking at downsides of _their_ code instead of going around and looking at _obvious_ downsides of other people's projects.
[*] [Slightly off-topic but it shows the same problem with the approach]
Quoted 8 lines
Quoted 6 lines
I now also see why some distributions keep pushing some known non-working things on their users (Fedora maintainers -- I'm talking to you), the best example is PulseAudio -- it simply doesn't work reliably even on modern hardware and/or using all scheduler tricks (it seems that making Linux into full RT OS is a prerequisite for fixing latency issues observed)..
Pulseaudio works for many, many people. The most productive use of your
Yeah, I trust you on both points..
Quoted 3 lines
time here is to file a bug report with the specific details of your audio chipset, let upstream diagnose whether it's a Pulseaudio-specific problem, a codec driver problem, or an ALSA problem.
Right..
I see no point BTW -- time make proper bug-report is much bigger than throwing in few local hacks and since my experience with upstream so far was that my bug-reports end up in some black-hole I deal with issues in the most pragmatic and productive for everybody way..
Quoted 5 lines
You can wait until the cows come home to deploy new technology, and then of course you'll still have to fix up all the bugs because you waited too long and nobody was testing it, or you can deploy new technology that works for most people and fix those bugs much earlier. Release early, release often. The tricky thing is how early.
Quoted 4 lines
It was new technology in F8 days.. It was included in F9 (released on 13th May 2008) and the current rawhide is still broken (no chance it will get fixed for F12).. Getting stereo sound to play skip-lessly on standard AC97 or HDA cards on a freshly installed system is impossible..
Really? I don't have any problems with HDA audio on any of my systems. Ok, well I used to see some strange storm of intel_hda errors come from one of my systems, but its very rare, and a newer kernel probably fixed it.
Quoted 11 lines
Other distributions are really not that much better (to be honest with Fedora it is the bleeding edge by definition) as their mode of operations sometimes consists of copying features (regardless of the quality and current state) from other distributions just for the sake of to not staying behind eventually..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signature · 2 lines
Thomas Fjellstrom [email protected]
Quoted 12 lines
Quoted 11 lines
1) the vendor driver never gets converted to cfg80211/mac80211, and stays in staging forever, or finally gets booted out of staging because nobody is working on converting it to mac80211. mac80211/cfg80211 is a hard requirement for being an accepted wireless driver. And drivers do have a shelf-life in staging.
2) the vendor driver starts getting converted to use mac80211. But I would argue that a better use of *anyone's* time is to make rt2x00 better, instead of porting the ralink vendor drivers to mac80211. It would probably take less time to fix up rt2x00 for new hardware than to port the ralink vendor drivers to mac80211.
Quoted 6 lines
Nobody is saying anything about porting the vendor drivers to mac80211.
3) After the vendor driver gets cleaned up to the point that people are able to make any sense out of it the missing bits will get added to rt2x00. Several months later (after all current users are happy with the improved drivers) the old drivers will be removed from staging..
Wishful thinking. the Ralink drivers for rt2460, rt2560, rt2570, rt61 and rt73 coexisted for years with their rt2x00 counterparts before they were finally abandoned after many arguments from people which wanted to preserve those drivers for even more years.
Ivo
Quoted 3 lines · Luis Correia
Since some days now, we have someone in the team which works for Ralink, I'm hopefull that he can find some time to help us make the driver better.
This (I hope) is the future. If we can get the vendors to cooperate with us at this level then we can eliminate the vendor/upstream driver distinction.
While I try to be ambivalent about drivers/staging, I _do_ think that it tends to enable vendors to get aways with _less_ support of the community by facilitating them in taking advantage of the "pragmatic" among us.
Quoted 2 lines
And now, i'm going back to my lovely hole, having added nothing to this conversation.
I disagree! :-)
John
Signature · 2 lines
John W. Linville Someday the world will need a hero, and you [email protected] might be all we have. Be ready.
Quoted 2 lines · Bartlomiej Zolnierkiewicz
Several months later (after all current users are happy with the improved drivers) the old drivers will be removed from staging..
I _really_ hope this isn't the standard. By that measure, nothing will ever leave staging as _someone_ will always have some use case that makes the other driver better for them.
John
Signature · 2 lines
John W. Linville Someday the world will need a hero, and you [email protected] might be all we have. Be ready.
Quoted 8 lines · Bartlomiej Zolnierkiewicz
Quoted 5 lines · On Wednesday 14 October 2009 00:24:58 Dan Williams wrote:
The point here is, often stuff works for some and not for others. That doesn't mean it's "broken". It's broken for you, and that should get fixed, but the whole system is by no means a loss and its pretty stupid to generalize things like "play skip-lessly on standard AC97/HDA cards is impossible" when it clearly isn't.
Quoted 6 lines
Interesting, do you mean that you are able to get skipless mp3 playback under i.e. audacious (using the default pulseaudio output plugin) under heavy load (i.e. kernel build) with internal speakers (or headphones)?
If so must by my luck then -- F11 on old Acer laptop (Intel 8x0 in ICH4M) and fedora-rawhide on new Asus K50AB one (Intel HDA in AMD/ATI SB710)..
Much as I enjoy a good Fedora audio discussion, perhaps it is time to end this one or move it elsewhere?
John
Signature · 2 lines
John W. Linville Someday the world will need a hero, and you [email protected] might be all we have. Be ready.
Quoted 8 lines · On Wednesday 14 October 2009 16:09:24 John W. Linville wrote:
Quoted 2 lines · Bartlomiej Zolnierkiewicz
Several months later (after all current users are happy with the improved drivers) the old drivers will be removed from staging..
I _really_ hope this isn't the standard. By that measure, nothing will ever leave staging as _someone_ will always have some use case that makes the other driver better for them.
Doesn't seem to be the case with all other drivers except wireless ones and the only real reason why wireless ones are so special is because of:
"But then there's the users, who bitch about everything and simply do not understand what it is at stake.
And all this is becoming way too messy for us to handle.
Personally all I see around me is people bitching and complaining, and no code being ported."
attitude which pretty much explains the problem..
Please adjust the process to fix the problem yourself or if you do not want to do it just make the room for people who do.
Quoted 18 lines · Bartlomiej Zolnierkiewicz
Quoted 8 lines · On Wednesday 14 October 2009 16:09:24 John W. Linville wrote:
Quoted 2 lines · Bartlomiej Zolnierkiewicz
Several months later (after all current users are happy with the improved drivers) the old drivers will be removed from staging..
I _really_ hope this isn't the standard. By that measure, nothing will ever leave staging as _someone_ will always have some use case that makes the other driver better for them.
Doesn't seem to be the case with all other drivers except wireless ones and the only real reason why wireless ones are so special is because of:
"But then there's the users, who bitch about everything and simply do not understand what it is at stake.
And all this is becoming way too messy for us to handle.
Quoted 7 lines
Personally all I see around me is people bitching and complaining, and no code being ported."
attitude which pretty much explains the problem..
Please adjust the process to fix the problem yourself or if you do not want to do it just make the room for people who do.
Alright Bartlomiej, you've had your say. Perhaps you should go about your business now.
John
P.S. For the record, the "But then there's the users..." quote is from someone else...
Signature · 2 lines
John W. Linville Someday the world will need a hero, and you [email protected] might be all we have. Be ready.
Quoted 27 lines · On Wednesday 14 October 2009 16:56:05 John W. Linville wrote:
Quoted 18 lines · Bartlomiej Zolnierkiewicz
Quoted 8 lines · On Wednesday 14 October 2009 16:09:24 John W. Linville wrote:
Quoted 2 lines · Bartlomiej Zolnierkiewicz
Several months later (after all current users are happy with the improved drivers) the old drivers will be removed from staging..
I _really_ hope this isn't the standard. By that measure, nothing will ever leave staging as _someone_ will always have some use case that makes the other driver better for them.
Doesn't seem to be the case with all other drivers except wireless ones and the only real reason why wireless ones are so special is because of:
"But then there's the users, who bitch about everything and simply do not understand what it is at stake.
And all this is becoming way too messy for us to handle.
Quoted 7 lines
Personally all I see around me is people bitching and complaining, and no code being ported."
attitude which pretty much explains the problem..
Please adjust the process to fix the problem yourself or if you do not want to do it just make the room for people who do.
Quoted 7 lines
Alright Bartlomiej, you've had your say. Perhaps you should go about your business now.
John
P.S. For the record, the "But then there's the users..." quote is from someone else...
..but you're still fine with its content, right?
I also wonder who is really taking advantage of who here (your other mail)..
You're holding users as hostages to pressure vendors to fund your projects and try to lure outside developers with the lovely perspective of doing the hardest parts of said projects.
I don't have a have a problem with it personally as long as people accept the competition.. but instead of working on _their_ projects they go around screaming at everybody who does not want to spin inside the great process designed by them..
Quoted 40 lines · Bartlomiej Zolnierkiewicz
Quoted 27 lines · On Wednesday 14 October 2009 16:56:05 John W. Linville wrote:
Quoted 18 lines · Bartlomiej Zolnierkiewicz
Quoted 8 lines · On Wednesday 14 October 2009 16:09:24 John W. Linville wrote:
Quoted 2 lines · Bartlomiej Zolnierkiewicz
Several months later (after all current users are happy with the improved drivers) the old drivers will be removed from staging..
I _really_ hope this isn't the standard. By that measure, nothing will ever leave staging as _someone_ will always have some use case that makes the other driver better for them.
Doesn't seem to be the case with all other drivers except wireless ones and the only real reason why wireless ones are so special is because of:
"But then there's the users, who bitch about everything and simply do not understand what it is at stake.
And all this is becoming way too messy for us to handle.
Quoted 7 lines
Personally all I see around me is people bitching and complaining, and no code being ported."
attitude which pretty much explains the problem..
Please adjust the process to fix the problem yourself or if you do not want to do it just make the room for people who do.
Quoted 7 lines
Alright Bartlomiej, you've had your say. Perhaps you should go about your business now.
John
P.S. For the record, the "But then there's the users..." quote is from someone else.....but you're still fine with its content, right?
I also wonder who is really taking advantage of who here (your other mail)..
Quoted 8 lines
You're holding users as hostages to pressure vendors to fund your projects and try to lure outside developers with the lovely perspective of doing the hardest parts of said projects.
I don't have a have a problem with it personally as long as people accept the competition.. but instead of working on _their_ projects they go around screaming at everybody who does not want to spin inside the great process designed by them..
I hear fishing in Poland is great this time of year.
Luis
Quoted 4 lines · Bartlomiej Zolnierkiewicz
I don't have a have a problem with it personally as long as people accept the competition.. but instead of working on _their_ projects they go around screaming at everybody who does not want to spin inside the great process designed by them..
Please whine somewhere else. You have the freedom to work in drivers/staging all you want. You do not have the power to force us to like it -- especially in a case where you are diverting attention from the community-maintained drivers instead of cooperating with them.
Your insults, jeers, and general bad attitude is unlikely to change our mind about it...
John
Signature · 2 lines
John W. Linville Someday the world will need a hero, and you [email protected] might be all we have. Be ready.
Quoted 11 lines · On Wednesday 14 October 2009 18:47:11 John W. Linville wrote:
Quoted 4 lines · Bartlomiej Zolnierkiewicz
I don't have a have a problem with it personally as long as people accept the competition.. but instead of working on _their_ projects they go around screaming at everybody who does not want to spin inside the great process designed by them..
Please whine somewhere else. You have the freedom to work in
drivers/stagingall you want. You do not have the power to force us to like it -- especially in a case where you are diverting attention from the community-maintained drivers instead of cooperating with them.
Cooperating you say.
rtl8187 -- before starting the work on rtl8187se I've pinged the maintainer to coordinate the effort and hear his opinion on how to progress..
I've never heard back.
rt2x00 -- I know that people have datasheets for some chipsets but I've never heard "How can we help you" etc. thing.
All I've ever heard was _lies_ about current state of affairs or that my work is in the way.
Quoted 2 lines
Your insults, jeers, and general bad attitude is unlikely to change our mind about it...
Well, when faced with real facts and technical arguments some people go into "you are a social problem" mode... nothing new here..
Quoted 15 lines · Bartlomiej Zolnierkiewicz
Quoted 11 lines · On Wednesday 14 October 2009 18:47:11 John W. Linville wrote:
Quoted 4 lines · Bartlomiej Zolnierkiewicz
I don't have a have a problem with it personally as long as people accept the competition.. but instead of working on _their_ projects they go around screaming at everybody who does not want to spin inside the great process designed by them..
Please whine somewhere else. You have the freedom to work in
drivers/stagingall you want. You do not have the power to force us to like it -- especially in a case where you are diverting attention from the community-maintained drivers instead of cooperating with them.Cooperating you say.
Quoted 7 lines
rtl8187 -- before starting the work on rtl8187se I've pinged the maintainer to coordinate the effort and hear his opinion on how to progress..
I've never heard back.
rt2x00 -- I know that people have datasheets for some chipsets but I've never heard "How can we help you" etc. thing.
I have all the datasheets that Ralink supplied to us.
All of them are PRELIMINARY and most have errors, and therefore useless.
All useful information is in the crap drivers.
Ralink never provide better ones, and even our 'inside guy' says the hardware documentation guys are always very late in providing more info.
So, for me, it isn't lack of documentation that will ever help, believe me.
Quoted 3 lines
All I've ever heard was _lies_ about current state of affairs or that my work is in the way.
AFAICS, your work was never questioned, at least by me.
You are welcome to work on rt2x00 , that was also never a problem. All you would need is join in.
Ralink also said they were commited to present drivers for new chipset to be mac80211 compliant, we're waiting on that.
So, you're really welcome to join the rt2x00 team Bartlomiej, the only thing we ask is that all work should be done using the existing rt2x00lib, rt2x00pci and rt2x00usb base 'libraries'.
Luis Correia,
rt2x00 project admin
Hi,
Quoted 14 lines
Quoted 11 lines · Bartlomiej Zolnierkiewicz
Quoted 5 lines
I don't have a have a problem with it personally as long as people accept the competition.. but instead of working on _their_ projects they go around screaming at everybody who does not want to spin inside the great process designed by them..
Please whine somewhere else. You have the freedom to work in
drivers/stagingall you want. You do not have the power to force us to like it -- especially in a case where you are diverting attention from the community-maintained drivers instead of cooperating with them.Cooperating you say.
Quoted 7 lines
rtl8187 -- before starting the work on rtl8187se I've pinged the maintainer to coordinate the effort and hear his opinion on how to progress..
I've never heard back.
rt2x00 -- I know that people have datasheets for some chipsets but I've never heard "How can we help you" etc. thing.
The rt2x00 members received the specsheets under the condition that we didn't distribute them further.
So everybody which requested the datasheets from the rt2x00 project were presented with a choice:
1) We provide the email address of the Ralink contact person which can device if you can get the specsheet or not (possibly under NDA, but this isn't always the case).
2) Specific questions about the registers can be asked and we give all the information we know from our work on the rt2x00 project plus additional information from the specsheet. Seeing that the specsheet doesn't always match reality, you get the better answers with this option, but some people just hate it when they need to ask other people for stuff.
Quoted 2 lines
All I've ever heard was _lies_ about current state of affairs or that my work is in the way.
I have encounterd your email address in only 2 rt2x00 related discussions (yes I have checked my entire email archive). Both cases were regarding staging vs rt2x00.
So far I never said rt2800usb or rt2800pci were high quality, I never said they were in a good shape. On the other hand, I often talked about the problems with the drivers, requesting help to improve the drivers, etc etc.
So are you basing this "I am hearing lies" about a random person talking on the street about rt2x00 which is telling the lie?
Ivo
Quoted 44 lines · On Wednesday 14 October 2009 20:26:49 Luis Correia wrote:
Quoted 15 lines · Bartlomiej Zolnierkiewicz
Quoted 11 lines · On Wednesday 14 October 2009 18:47:11 John W. Linville wrote:
Quoted 4 lines · Bartlomiej Zolnierkiewicz
I don't have a have a problem with it personally as long as people accept the competition.. but instead of working on _their_ projects they go around screaming at everybody who does not want to spin inside the great process designed by them..
Please whine somewhere else. You have the freedom to work in
drivers/stagingall you want. You do not have the power to force us to like it -- especially in a case where you are diverting attention from the community-maintained drivers instead of cooperating with them.Cooperating you say.
Quoted 7 lines
rtl8187 -- before starting the work on rtl8187se I've pinged the maintainer to coordinate the effort and hear his opinion on how to progress..
I've never heard back.
rt2x00 -- I know that people have datasheets for some chipsets but I've never heard "How can we help you" etc. thing.
I have all the datasheets that Ralink supplied to us.
All of them are PRELIMINARY and most have errors, and therefore useless.All useful information is in the crap drivers.
Ralink never provide better ones, and even our 'inside guy' says the hardware documentation guys are always very late in providing more info.
So, for me, it isn't lack of documentation that will ever help, believe me.
Quoted 3 lines
All I've ever heard was _lies_ about current state of affairs or that my work is in the way.
AFAICS, your work was never questioned, at least by me.
You are welcome to work on rt2x00 , that was also never a problem. All you would need is join in.
Quoted 6 lines
Ralink also said they were commited to present drivers for new chipset to be mac80211 compliant, we're waiting on that.
So, you're really welcome to join the rt2x00 team Bartlomiej, the only thing we ask is that all work should be done using the existing rt2x00lib, rt2x00pci and rt2x00usb base 'libraries'.
Well, I will still continue to work on staging drivers:
- I need to understand vendor drivers better before doing any larger rt2x00 modifications. Cleaning it up is just an added value while reading it..
- I feel quite comfortable working on de-convoluting crappy code and has years of experience of doing it.
- I'm still using Ralink hardware personally so I need something that provides the basic usability _now_.
but since I'm also going to start adding some missing bits to rt2x00 soon I would be happy to join rt2x00 project..
Quoted 43 lines · On Wednesday 14 October 2009 20:56:17 Ivo van Doorn wrote:
Hi,
Quoted 14 lines
Quoted 11 lines · Bartlomiej Zolnierkiewicz
Quoted 5 lines
I don't have a have a problem with it personally as long as people accept the competition.. but instead of working on _their_ projects they go around screaming at everybody who does not want to spin inside the great process designed by them..
Please whine somewhere else. You have the freedom to work in
drivers/stagingall you want. You do not have the power to force us to like it -- especially in a case where you are diverting attention from the community-maintained drivers instead of cooperating with them.Cooperating you say.
Quoted 7 lines
rtl8187 -- before starting the work on rtl8187se I've pinged the maintainer to coordinate the effort and hear his opinion on how to progress..
I've never heard back.
rt2x00 -- I know that people have datasheets for some chipsets but I've never heard "How can we help you" etc. thing.
The rt2x00 members received the specsheets under the condition that we didn't distribute them further.
So everybody which requested the datasheets from the rt2x00 project were presented with a choice:
1) We provide the email address of the Ralink contact person which can device if you can get the specsheet or not (possibly under NDA, but this isn't always the case).
2) Specific questions about the registers can be asked and we give all the information we know from our work on the rt2x00 project plus additional information from the specsheet. Seeing that the specsheet doesn't always match reality, you get the better answers with this option, but some people just hate it when they need to ask other people for stuff.Quoted 2 lines
All I've ever heard was _lies_ about current state of affairs or that my work is in the way.
I have encounterd your email address in only 2 rt2x00 related discussions (yes I have checked my entire email archive). Both cases were regarding staging vs rt2x00.
Quoted 6 lines
So far I never said rt2800usb or rt2800pci were high quality, I never said they were in a good shape. On the other hand, I often talked about the problems with the drivers, requesting help to improve the drivers, etc etc.
So are you basing this "I am hearing lies" about a random person talking on the street about rt2x00 which is telling the lie?
Maybe I've used a bit too strong wording but the fact is that vendor drivers are useful for providing users with *unsupported* and *temporary* solution until the proper drivers are in place have been questioned a lot in the past, and sorry but it is a fact (it may be hard to swallow but it shouldn't be discussed about).
The staging is a new game in town and provides real benefit for end-users to use their hardware early while proper solutions are being worked on (not like most of distributions weren't shipping crap drivers anyway -- now at least we have some control over it).
This is extremely important in segments where Linux is still not the leading OS. We cannot tell users to go hike -- they are our users! Moreover they are quite smart so they will use what works best for their needs anyway, not necessarily what is the easiest for us to maintain in the long-term or work on.
Staging also helps companies involved to transform their software offerings in a more smooth way. Often such transition requires long process and much work on the company side to adapt to our model of doing things so patience is recommended. (Lets not forget that staging provides also a stick part, drivers are removed from staging if nobody cares about them and even if there are volunteers caring about support for certain hardware the company will still get a bad publicity if it doesn't participate in the process)..
So staging is here to stay and it is up to particular maintainers how they are going to it use this "tool" and integrate it into their current mode of operation..
I'm sorry if my words were offending to you or other wireless developers. I kind of feel the frustration of people who had put years of effort into providing the proper wireless infrastructure + drivers and are ignored by vendors. However we have to keep the ball rolling and cannot dismiss valid user complaints or ignore other possibilities of doing things.
Bartlomiej
Quoted 80 lines · Bartlomiej Zolnierkiewicz
Quoted 43 lines · On Wednesday 14 October 2009 20:56:17 Ivo van Doorn wrote:
Hi,
Quoted 14 lines
Quoted 11 lines · Bartlomiej Zolnierkiewicz
Quoted 5 lines
I don't have a have a problem with it personally as long as people accept the competition.. but instead of working on _their_ projects they go around screaming at everybody who does not want to spin inside the great process designed by them..
Please whine somewhere else. You have the freedom to work in
drivers/stagingall you want. You do not have the power to force us to like it -- especially in a case where you are diverting attention from the community-maintained drivers instead of cooperating with them.Cooperating you say.
Quoted 7 lines
rtl8187 -- before starting the work on rtl8187se I've pinged the maintainer to coordinate the effort and hear his opinion on how to progress..
I've never heard back.
rt2x00 -- I know that people have datasheets for some chipsets but I've never heard "How can we help you" etc. thing.
The rt2x00 members received the specsheets under the condition that we didn't distribute them further.
So everybody which requested the datasheets from the rt2x00 project were presented with a choice:
1) We provide the email address of the Ralink contact person which can device if you can get the specsheet or not (possibly under NDA, but this isn't always the case).
2) Specific questions about the registers can be asked and we give all the information we know from our work on the rt2x00 project plus additional information from the specsheet. Seeing that the specsheet doesn't always match reality, you get the better answers with this option, but some people just hate it when they need to ask other people for stuff.Quoted 2 lines
All I've ever heard was _lies_ about current state of affairs or that my work is in the way.
I have encounterd your email address in only 2 rt2x00 related discussions (yes I have checked my entire email archive). Both cases were regarding staging vs rt2x00.
Quoted 6 lines
So far I never said rt2800usb or rt2800pci were high quality, I never said they were in a good shape. On the other hand, I often talked about the problems with the drivers, requesting help to improve the drivers, etc etc.
So are you basing this "I am hearing lies" about a random person talking on the street about rt2x00 which is telling the lie?
Maybe I've used a bit too strong wording but the fact is that vendor drivers are useful for providing users with *unsupported* and *temporary* solution until the proper drivers are in place have been questioned a lot in the past, and sorry but it is a fact (it may be hard to swallow but it shouldn't be discussed about).
The staging is a new game in town and provides real benefit for end-users to use their hardware early while proper solutions are being worked on (not like most of distributions weren't shipping crap drivers anyway -- now at least we have some control over it).
This is extremely important in segments where Linux is still not the leading OS. We cannot tell users to go hike -- they are our users! Moreover they are quite smart so they will use what works best for their needs anyway, not necessarily what is the easiest for us to maintain in the long-term or work on.
Staging also helps companies involved to transform their software offerings in a more smooth way. Often such transition requires long process and much work on the company side to adapt to our model of doing things so patience is recommended. (Lets not forget that staging provides also a stick part, drivers are removed from staging if nobody cares about them and even if there are volunteers caring about support for certain hardware the company will still get a bad publicity if it doesn't participate in the process)..
So staging is here to stay and it is up to particular maintainers how they are going to it use this "tool" and integrate it into their current mode of operation..
Quoted 6 lines
I'm sorry if my words were offending to you or other wireless developers. I kind of feel the frustration of people who had put years of effort into providing the proper wireless infrastructure + drivers and are ignored by vendors. However we have to keep the ball rolling and cannot dismiss valid user complaints or ignore other possibilities of doing things.
All,
I don't think this discussion is leading us anywhere.
I believe everybody agrees with the "staging"/Ralink provided drivers to be good to provide end-users a working solution until the rt2x00 driver has been completed.
However, the problem that we have seen (from the rt2x00 project point of view) is that
the Ralink drivers that are in staging are confusing / distraction developer attention. We
have had quite a few occasions where new developers started to work on the staging
drivers, as they thought these were "the way to go".
I think that can be easily solved by including in the Ralink staging drivers a README
file pointing to the rt2x00 drivers, and a note stating that the rt2x00 drivers are the ones
for long-term Linux support, and that the staging drivers are there just to help users making
their hardware work.
Just my $0.02 on this topic.
---
Gertjan
rt2x00 project developer
Quoted 104 lines · On Thursday 15 October 2009 08:28:07 Gertjan van Wingerde wrote:
Quoted 80 lines · Bartlomiej Zolnierkiewicz
Quoted 43 lines · On Wednesday 14 October 2009 20:56:17 Ivo van Doorn wrote:
Hi,
Quoted 14 lines
Quoted 11 lines · Bartlomiej Zolnierkiewicz
Quoted 5 lines
I don't have a have a problem with it personally as long as people accept the competition.. but instead of working on _their_ projects they go around screaming at everybody who does not want to spin inside the great process designed by them..
Please whine somewhere else. You have the freedom to work in
drivers/stagingall you want. You do not have the power to force us to like it -- especially in a case where you are diverting attention from the community-maintained drivers instead of cooperating with them.Cooperating you say.
Quoted 7 lines
rtl8187 -- before starting the work on rtl8187se I've pinged the maintainer to coordinate the effort and hear his opinion on how to progress..
I've never heard back.
rt2x00 -- I know that people have datasheets for some chipsets but I've never heard "How can we help you" etc. thing.
The rt2x00 members received the specsheets under the condition that we didn't distribute them further.
So everybody which requested the datasheets from the rt2x00 project were presented with a choice:
1) We provide the email address of the Ralink contact person which can device if you can get the specsheet or not (possibly under NDA, but this isn't always the case).
2) Specific questions about the registers can be asked and we give all the information we know from our work on the rt2x00 project plus additional information from the specsheet. Seeing that the specsheet doesn't always match reality, you get the better answers with this option, but some people just hate it when they need to ask other people for stuff.Quoted 2 lines
All I've ever heard was _lies_ about current state of affairs or that my work is in the way.
I have encounterd your email address in only 2 rt2x00 related discussions (yes I have checked my entire email archive). Both cases were regarding staging vs rt2x00.
Quoted 6 lines
So far I never said rt2800usb or rt2800pci were high quality, I never said they were in a good shape. On the other hand, I often talked about the problems with the drivers, requesting help to improve the drivers, etc etc.
So are you basing this "I am hearing lies" about a random person talking on the street about rt2x00 which is telling the lie?
Maybe I've used a bit too strong wording but the fact is that vendor drivers are useful for providing users with *unsupported* and *temporary* solution until the proper drivers are in place have been questioned a lot in the past, and sorry but it is a fact (it may be hard to swallow but it shouldn't be discussed about).
The staging is a new game in town and provides real benefit for end-users to use their hardware early while proper solutions are being worked on (not like most of distributions weren't shipping crap drivers anyway -- now at least we have some control over it).
This is extremely important in segments where Linux is still not the leading OS. We cannot tell users to go hike -- they are our users! Moreover they are quite smart so they will use what works best for their needs anyway, not necessarily what is the easiest for us to maintain in the long-term or work on.
Staging also helps companies involved to transform their software offerings in a more smooth way. Often such transition requires long process and much work on the company side to adapt to our model of doing things so patience is recommended. (Lets not forget that staging provides also a stick part, drivers are removed from staging if nobody cares about them and even if there are volunteers caring about support for certain hardware the company will still get a bad publicity if it doesn't participate in the process)..
So staging is here to stay and it is up to particular maintainers how they are going to it use this "tool" and integrate it into their current mode of operation..
Quoted 6 lines
I'm sorry if my words were offending to you or other wireless developers. I kind of feel the frustration of people who had put years of effort into providing the proper wireless infrastructure + drivers and are ignored by vendors. However we have to keep the ball rolling and cannot dismiss valid user complaints or ignore other possibilities of doing things.
All,
I don't think this discussion is leading us anywhere.
I believe everybody agrees with the "staging"/Ralink provided drivers to be good to provide end-users a working solution until the rt2x00 driver has been completed.However, the problem that we have seen (from the rt2x00 project point of view) is that
the Ralink drivers that are in staging are confusing / distraction developer attention. We
have had quite a few occasions where new developers started to work on the staging
drivers, as they thought these were "the way to go".
Quoted 7 lines
I think that can be easily solved by including in the Ralink staging drivers a README
file pointing to the rt2x00 drivers, and a note stating that the rt2x00 drivers are the ones
for long-term Linux support, and that the staging drivers are there just to help users making
their hardware work.
I think that there is already a note stating something like that.
However if you think that something needs to be added or changed then please just send Greg a patch
Quoted 46 lines · On Wednesday 14 October 2009 18:55:23 Luis R. Rodriguez wrote:
Quoted 44 lines · Bartlomiej Zolnierkiewicz
Quoted 27 lines · On Wednesday 14 October 2009 16:56:05 John W. Linville wrote:
Quoted 18 lines · Bartlomiej Zolnierkiewicz
Quoted 8 lines · On Wednesday 14 October 2009 16:09:24 John W. Linville wrote:
Quoted 2 lines · Bartlomiej Zolnierkiewicz
Several months later (after all current users are happy with the improved drivers) the old drivers will be removed from staging..
I _really_ hope this isn't the standard. By that measure, nothing will ever leave staging as _someone_ will always have some use case that makes the other driver better for them.
Doesn't seem to be the case with all other drivers except wireless ones and the only real reason why wireless ones are so special is because of:
"But then there's the users, who bitch about everything and simply do not understand what it is at stake.
And all this is becoming way too messy for us to handle.
Quoted 7 lines
Personally all I see around me is people bitching and complaining, and no code being ported."
attitude which pretty much explains the problem..
Please adjust the process to fix the problem yourself or if you do not want to do it just make the room for people who do.
Quoted 7 lines
Alright Bartlomiej, you've had your say. Perhaps you should go about your business now.
John
P.S. For the record, the "But then there's the users..." quote is from someone else.....but you're still fine with its content, right?
I also wonder who is really taking advantage of who here (your other mail)..
You're holding users as hostages to pressure vendors to fund your projects and try to lure outside developers with the lovely perspective of doing the hardest parts of said projects.
Quoted 6 lines
Quoted 4 lines
I don't have a have a problem with it personally as long as people accept the competition.. but instead of working on _their_ projects they go around screaming at everybody who does not want to spin inside the great process designed by them..
I hear fishing in Poland is great this time of year.
It got quite cold this week so I thought that I would try to fish the commit that broke Atheros AR9285 in Linus' tree (works in 2.6.31) and make recent kernels finally work on my laptop..
Seems like there are two regressions actually:
- later one making association/authentication impossible
- earlier one making transfers stall
There is also a ton of unrelated and related (mac80211) problems in between so the whole experience to trace regressions down is a real hell (I went through like 40 kernels already)..
Oh, there is also an ath9k slab corruption already in 2.6.31 (I got it debugged initially though)..
However today it got a bit warmer and the snow is almost gone so I think that I'm going to take your advice after using the shortcut solution for my wireless problems..
I'll just plug that cheap rt3070 stick laying around and modprobe that crappy rt2870sta..
Quoted 11 lines · Bartlomiej Zolnierkiewicz
Quoted 1 line · On Wednesday 14 October 2009 18:55:23 Luis R. Rodriguez wrote:
I hear fishing in Poland is great this time of year.
It got quite cold this week so I thought that I would try to fish the commit that broke Atheros AR9285 in Linus' tree (works in 2.6.31) and make recent kernels finally work on my laptop..
Seems like there are two regressions actually:
- later one making association/authentication impossible
And you reported this when and where?
Quoted 1 line
- earlier one making transfers stall
And you reported this when and where?
Curious how the issues you mention now spreading across sound and wireless do not get fixed or seriously addressed. Have you considered your tactics are perhaps not the best?
Have you tested newer kernels for ar9285? If there are regressions obviously they should be fixed but without proper attention to the issues they obviously cannot be fixed.
Quoted 3 lines
There is also a ton of unrelated and related (mac80211) problems in between so the whole experience to trace regressions down is a real hell (I went through like 40 kernels already)..
I do agree there has been a hell of a lot of changes on mac80211/cfg80211 over the last few kernels and you can argue whether or not this has been a good thing -- personally I think it has had its negative impact on users on older kernels but I do value the new changes and most major changes have gone in right after the merge window without opposition. When there are issues I at least do believe we are attentive enough to help users and solve them on wireless and contrary to staging you will at least have a larger group of members working on the same wireless subsystem rather than addressing pigeon hole solutions.
If you don't voice your own opinions and provide constructive criticism instead of pointless and side tracked rants you are not going to accomplish shit. So if you want to want to work on staging -- go at it -- but don't moan and bitch about how wireless proper is being treated if you are not willing to man up and do something about it.
Quoted 2 lines
Oh, there is also an ath9k slab corruption already in 2.6.31 (I got it debugged initially though)..
We track reported ath9k bugs here:
http://wireless.kernel.org/en/users/Drivers/ath9k/bugs
When there is a bug report we follow up on it.
Quoted 6 lines
However today it got a bit warmer and the snow is almost gone so I think that I'm going to take your advice after using the shortcut solution for my wireless problems..
I'll just plug that cheap rt3070 stick laying around and modprobe that crappy rt2870sta..
Good luck with that buddy.
Luis
Quoted 16 lines · On Thursday 15 October 2009 21:06:55 Luis R. Rodriguez wrote:
Quoted 11 lines · Bartlomiej Zolnierkiewicz
Quoted 1 line · On Wednesday 14 October 2009 18:55:23 Luis R. Rodriguez wrote:
I hear fishing in Poland is great this time of year.
It got quite cold this week so I thought that I would try to fish the commit that broke Atheros AR9285 in Linus' tree (works in 2.6.31) and make recent kernels finally work on my laptop..
Seems like there are two regressions actually:
- later one making association/authentication impossible
And you reported this when and where?
Quoted 7 lines
Quoted 1 line
- earlier one making transfers stall
And you reported this when and where?
Curious how the issues you mention now spreading across sound and wireless do not get fixed or seriously addressed. Have you considered your tactics are perhaps not the best?
Please look closely at chosen examples and you'll see a lot of insight telling you that users' experience is not granted by having clean code or by having features which are not consider crucial instead of reliable basic functionality.
I'm pretty sure that if you try F12 w/ AR9285 you will be able to reproduce and fix at least some of above mentioned problems. I just used the occasion to raise them and make people aware of bugs before they hit users in final 2.6.32.
I'm not as much interested in fixing existing problems as in seeing why they happened in the first place and how the process can be improved to prevent them / making tracking of them easy for non-developers (so more people can contribute to the project and developers have more time to add new features). I also don't have time to care about every single Linux bug that I encounter (I hit quite a lot of them), bug-reporting is a thankless and very time consuming work.
This is in no means trying to implicit that you're doing bad job. Quite the contrary -- I think that your work on Atheros support is much needed.
The point is that there is a lot of room for in release management process of wireless/networking (it has been more-or-less unchanged for a long time while other subsystems, i.e. x86, are constantly looking into improvements).
This is not something that you can change alone so please do not hesitate to give feedback about this to your upstream maintainers so they are aware of the need for improvements.