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!! -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
