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,
> In 2.6.31, there are USB device IDs common between both drivers.
That is because they are drivers for the same hardware.
> 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,
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
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.
> 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
On Tuesday 13 October 2009, Bartlomiej Zolnierkiewicz wrote:
> 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.
>
> > 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
On Tuesday 13 October 2009 20:17:47 Ivo van Doorn wrote:
> On Tuesday 13 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > 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.
> >
> > > 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
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)..
> 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"..
> 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.. [*]
> 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!!
> > 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.
On Tue, 2009-10-13 at 21:21 +0200, Bartlomiej Zolnierkiewicz wrote:
> On Tuesday 13 October 2009 20:17:47 Ivo van Doorn wrote:
> > On Tuesday 13 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > > 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.
> > >
> > > > 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
>
> 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)..
>
> > 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.
> > 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.
> > 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)..
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
Bartlomiej Zolnierkiewicz wrote:
> Hi,
>
> 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.
By saying to make one driver the default one, you mean avoiding the
other from getting probed automatically by clearing the device id tables?
On Tuesday 13 October 2009 22:00:48 Ivo van Doorn wrote:
> > > 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.
I will be glad to take over the maintenance of those two drivers if this
is so burdensome for you..
On Tuesday 13 October 2009 22:41:50 Ozan Çağlayan wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > Hi,
> >
> > 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.
>
> 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..
On Tuesday 13 October 2009 22:15:40 Dan Williams wrote:
> On Tue, 2009-10-13 at 21:21 +0200, Bartlomiej Zolnierkiewicz wrote:
> > On Tuesday 13 October 2009 20:17:47 Ivo van Doorn wrote:
> > > On Tuesday 13 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > > > 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.
> > > >
> > > > > 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
> >
> > 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)..
> >
> > > 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.
> If it doesn't, then that driver needs to be updated to use mac80211.
> Period.
>
> > > 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.
No effort, right. Debugging things is the hardest part of any project..
> 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.
> 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.
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..
> > > 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)..
>
> Pulseaudio works for many, many people. The most productive use of your
Yeah, I trust you on both points..
> 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..
> 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..
On Tue, Oct 13, 2009 at 22:57, Bartlomiej Zolnierkiewicz
<[email protected]> wrote:
> On Tuesday 13 October 2009 22:15:40 Dan Williams wrote:
>> On Tue, 2009-10-13 at 21:21 +0200, Bartlomiej Zolnierkiewicz wrote:
>> > On Tuesday 13 October 2009 20:17:47 Ivo van Doorn wrote:
>> > > On Tuesday 13 October 2009, Bartlomiej Zolnierkiewicz wrote:
>> > > > 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.
>> > > >
>> > > > > 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
>> >
>> > 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)..
>> >
>> > > 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.
>
>> If it doesn't, then that driver needs to be updated to use mac80211.
>> Period.
>>
>> > > 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.
>
> No effort, right. ?Debugging things is the hardest part of any project..
>
>> 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.
>
>> 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.
>
> 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..
>
>> > > 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)..
>>
>> Pulseaudio works for many, many people. ?The most productive use of your
>
> Yeah, I trust you on both points..
>
>> 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..
>
>> 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..
> --
> 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.
>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
On Tue, 2009-10-13 at 23:57 +0200, Bartlomiej Zolnierkiewicz wrote:
> On Tuesday 13 October 2009 22:15:40 Dan Williams wrote:
> > On Tue, 2009-10-13 at 21:21 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > On Tuesday 13 October 2009 20:17:47 Ivo van Doorn wrote:
> > > > On Tuesday 13 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > > > > 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.
> > > > >
> > > > > > 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
> > >
> > > 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)..
> > >
> > > > 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.
>
> > If it doesn't, then that driver needs to be updated to use mac80211.
> > Period.
> >
> > > > 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.
>
> No effort, right. Debugging things is the hardest part of any project..
>
> > 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.
>
> > 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.
>
> 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..
>
> > > > 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)..
> >
> > Pulseaudio works for many, many people. The most productive use of your
>
> Yeah, I trust you on both points..
>
> > 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..
>
> > 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..
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
On Wednesday 14 October 2009 00:24:58 Dan Williams wrote:
> On Tue, 2009-10-13 at 23:57 +0200, Bartlomiej Zolnierkiewicz wrote:
> > On Tuesday 13 October 2009 22:15:40 Dan Williams wrote:
> > > On Tue, 2009-10-13 at 21:21 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > On Tuesday 13 October 2009 20:17:47 Ivo van Doorn wrote:
> > > > > On Tuesday 13 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > > > > > 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.
> > > > > >
> > > > > > > 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
> > > >
> > > > 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)..
> > > >
> > > > > 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.
> >
> > > If it doesn't, then that driver needs to be updated to use mac80211.
> > > Period.
> > >
> > > > > 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.
> >
> > No effort, right. Debugging things is the hardest part of any project..
> >
> > > 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.
> >
> > > 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.
> >
> > 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..
> >
> > > > > 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)..
> > >
> > > Pulseaudio works for many, many people. The most productive use of your
> >
> > Yeah, I trust you on both points..
> >
> > > 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..
> >
> > > 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..
>
> 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.
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)..
On Tue, 2009-10-13 at 21:21 +0200, Bartlomiej Zolnierkiewicz wrote:
> On Tuesday 13 October 2009 20:17:47 Ivo van Doorn wrote:
> > On Tuesday 13 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > > 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.
> > >
> > > > 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
>
> 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)..
(or RT2870 here)
On Tue October 13 2009, Bartlomiej Zolnierkiewicz wrote:
> On Tuesday 13 October 2009 22:15:40 Dan Williams wrote:
> > On Tue, 2009-10-13 at 21:21 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > On Tuesday 13 October 2009 20:17:47 Ivo van Doorn wrote:
> > > > On Tuesday 13 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > > > > 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.
> > > > >
> > > > > > 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
> > >
> > > 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)..
> > >
> > > > 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.
>
> > If it doesn't, then that driver needs to be updated to use mac80211.
> > Period.
> >
> > > > 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.
>
> No effort, right. Debugging things is the hardest part of any project..
>
> > 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.
>
> > 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.
>
> 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..
>
> > > > 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)..
> >
> > Pulseaudio works for many, many people. The most productive use of your
>
> Yeah, I trust you on both points..
>
> > 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..
>
> > 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..
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.
> 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/
>
--
Thomas Fjellstrom
[email protected]
> > 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.
>
> 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
On Tue, Oct 13, 2009 at 11:57:57PM +0200, Bartlomiej Zolnierkiewicz wrote:
> 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
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Tue, Oct 13, 2009 at 11:21:53PM +0100, Luis Correia wrote:
> 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.
> And now, i'm going back to my lovely hole, having added nothing to
> this conversation.
I disagree! :-)
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Wed, Oct 14, 2009 at 12:42:39AM +0200, Bartlomiej Zolnierkiewicz wrote:
> 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.
>
> 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
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Wednesday 14 October 2009 16:09:24 John W. Linville wrote:
> On Tue, Oct 13, 2009 at 11:57:57PM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> > 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.
On Wed, Oct 14, 2009 at 04:52:40PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 14 October 2009 16:09:24 John W. Linville wrote:
> > On Tue, Oct 13, 2009 at 11:57:57PM +0200, Bartlomiej Zolnierkiewicz wrote:
> >
> > > 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.
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...
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Wednesday 14 October 2009 16:56:05 John W. Linville wrote:
> On Wed, Oct 14, 2009 at 04:52:40PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > On Wednesday 14 October 2009 16:09:24 John W. Linville wrote:
> > > On Tue, Oct 13, 2009 at 11:57:57PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > >
> > > > 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.
>
> 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..
On Wed, Oct 14, 2009 at 05:28:21PM +0200, Bartlomiej Zolnierkiewicz wrote:
> 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
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Wed, Oct 14, 2009 at 8:28 AM, Bartlomiej Zolnierkiewicz
<[email protected]> wrote:
> On Wednesday 14 October 2009 16:56:05 John W. Linville wrote:
>> On Wed, Oct 14, 2009 at 04:52:40PM +0200, Bartlomiej Zolnierkiewicz wrote:
>> > On Wednesday 14 October 2009 16:09:24 John W. Linville wrote:
>> > > On Tue, Oct 13, 2009 at 11:57:57PM +0200, Bartlomiej Zolnierkiewicz wrote:
>> > >
>> > > > 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.
>>
>> 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..
I hear fishing in Poland is great this time of year.
Luis
On Wednesday 14 October 2009 18:47:11 John W. Linville wrote:
> On Wed, Oct 14, 2009 at 05:28:21PM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> > 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.
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.
> 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..
On Wed, Oct 14, 2009 at 18:33, Bartlomiej Zolnierkiewicz
<[email protected]> wrote:
> On Wednesday 14 October 2009 18:47:11 John W. Linville wrote:
>> On Wed, Oct 14, 2009 at 05:28:21PM +0200, Bartlomiej Zolnierkiewicz wrote:
>>
>> > 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.
>
> 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.
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.
>
> 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,
> > On Wed, Oct 14, 2009 at 05:28:21PM +0200, Bartlomiej Zolnierkiewicz wrote:
> >
> > > 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.
>
> 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.
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.
> 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
On Wednesday 14 October 2009 20:56:17 Ivo van Doorn wrote:
> Hi,
>
> > > On Wed, Oct 14, 2009 at 05:28:21PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > >
> > > > 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.
> >
> > 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.
>
> 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.
>
> > 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?
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
On Wednesday 14 October 2009 20:26:49 Luis Correia wrote:
> On Wed, Oct 14, 2009 at 18:33, Bartlomiej Zolnierkiewicz
> <[email protected]> wrote:
> > On Wednesday 14 October 2009 18:47:11 John W. Linville wrote:
> >> On Wed, Oct 14, 2009 at 05:28:21PM +0200, Bartlomiej Zolnierkiewicz wrote:
> >>
> >> > 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.
> >
> > 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.
>
> 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.
>
> >
> > 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'.
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..
On Wed, Oct 14, 2009 at 10:10 PM, Bartlomiej Zolnierkiewicz
<[email protected]> wrote:
> On Wednesday 14 October 2009 20:56:17 Ivo van Doorn wrote:
>> Hi,
>>
>> > > On Wed, Oct 14, 2009 at 05:28:21PM +0200, Bartlomiej Zolnierkiewicz wrote:
>> > >
>> > > > 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.
>> >
>> > 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.
>>
>> 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.
>>
>> > 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?
>
> 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.
>
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
On Thursday 15 October 2009 08:28:07 Gertjan van Wingerde wrote:
> On Wed, Oct 14, 2009 at 10:10 PM, Bartlomiej Zolnierkiewicz
> <[email protected]> wrote:
> > On Wednesday 14 October 2009 20:56:17 Ivo van Doorn wrote:
> >> Hi,
> >>
> >> > > On Wed, Oct 14, 2009 at 05:28:21PM +0200, Bartlomiej Zolnierkiewicz wrote:
> >> > >
> >> > > > 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.
> >> >
> >> > 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.
> >>
> >> 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.
> >>
> >> > 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?
> >
> > 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.
> >
>
> 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.
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
On Wednesday 14 October 2009 18:55:23 Luis R. Rodriguez wrote:
> On Wed, Oct 14, 2009 at 8:28 AM, Bartlomiej Zolnierkiewicz
> <[email protected]> wrote:
> > On Wednesday 14 October 2009 16:56:05 John W. Linville wrote:
> >> On Wed, Oct 14, 2009 at 04:52:40PM +0200, Bartlomiej Zolnierkiewicz wrote:
> >> > On Wednesday 14 October 2009 16:09:24 John W. Linville wrote:
> >> > > On Tue, Oct 13, 2009 at 11:57:57PM +0200, Bartlomiej Zolnierkiewicz wrote:
> >> > >
> >> > > > 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.
> >>
> >> 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..
>
> 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..
On Thu, Oct 15, 2009 at 7:47 AM, Bartlomiej Zolnierkiewicz
<[email protected]> wrote:
> 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?
> - 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.
> 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.
> 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.
> 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
On Thursday 15 October 2009 21:06:55 Luis R. Rodriguez wrote:
> On Thu, Oct 15, 2009 at 7:47 AM, Bartlomiej Zolnierkiewicz
> <[email protected]> wrote:
> > 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?
>
> > - 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.