login
Search
Hi list,
since the mentioned driver interfaces with the drivers/ieee1394
subsystem, I had a brief look at it today. There is a number of
stylistic issues and kernel API issues to work on, like
- use of a semaphore,
- struct types with bitfields for what appears to be on-the-wire data,
- camel case names,
- "#define BYTE unsigned char" and friends,
- stale duplicated code like "BUG_ON(in_interrupt())" or all
references to ohci1394 which seem unnecessary,
- homebrewed down_timeout,
- comment style not as in linux kernel.
So there is a number of small things that even people who don't have
respective hardware _could_ work on. But read on before you start
cleaning those up:
A bigger issue is the interfacing with drivers/ieee1394. As most of the
subscribers probably know, Linux now contains two IEEE 1394 stacks which
are entirely independent of each other. The newer one is
drivers/firewire and is meant to replace drivers/ieee1394 once it is
stable enough and has all the necessary features.
This means that firesat needs to be ported to the new stack eventually.
The question remains if that should be done before mainline submission
or after. I tend to the latter, even if merely because ieee1394 and
firewire subsystem maintenance and development is chronically
under-staffed, hence bandwidth for mentoring and review of new additions
like firesat is low. (It looks like an IEC 61883 implementation, one of
the FireWire areas I myself am less familiar with. Therefore I also
didn't pressure Ben to look into the firewire stack when he discussed
ieee1394 API issues on linux1394-devel.)
So, because of the need to port it to a different in-kernel API
eventually, current firesat's ieee1394 interfacing code does not have to
be brought to perfection anymore. Instead, work on it should either
have the goal of later gradual movement to the firewire stack (i.e. make
it possible to build firesat for ieee1394 or for firewire) _or_ should ...Was Linux Driver Project established only to work with companies? There is a considerable amount of working drivers with a free license out there which are not in the main kernel, for various reasons. Here's my short list: 1. linux-wlan project http://linux-wlan.org/ Still, they have drivers for some wireless devices not available in the main kernel. 2. driver for crypto engine cards For Linux 2.2 and 2.4 only: http://sourceforge.net/projects/hifn7951/ http://soekris.com/vpn1401.htm Yes, it would be best to talk to a given project's maintainer, but sometimes, there is no active maintainer anymore... -- Tomasz Chmielewski http://wpkg.org _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
--=-MN4WY5Tx/wo0q7d1X4L5 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable It would be nice to get the Zaptel drivers into the mainline kernel. Digium has talked about this from time to time but I don't think that they have actually assigned some engineers to the task. Jeff --=-MN4WY5Tx/wo0q7d1X4L5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBHFmC0rtk7xyyIQRERAgZYAJ9MjuSNueAxS+k7OKlGdK67ONYw9wCfVnSA hMw0YFBr63fjb0cAqYdi7J4= =L9yX -----END PGP SIGNATURE----- --=-MN4WY5Tx/wo0q7d1X4L5--
Oh, Zaptel, too. There are also GPL2 Linux 2.6 drivers called BRIstuff from junghanns.net for popular cards used with Asterisk: quadBRI/octoBRI, singleE1/doubleE1, hfc-pci (zaphfc). It's actively developed for years by Junghanns.NET GmbH, they made their last release a couple of weeks ago. -- Tomasz Chmielewski http://wpkg.org _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
Asterisk opens up a whole other can of worms that some of us are currently persuing (we need the zaptel core in the kernel before we can add the drivers...) But this is being looked into. thanks, greg k-h _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
Yes, I agree. However, I haven't really looked at them. What are the hurdles with getting them merged? John -- John W. Linville linville@tuxdriver.com _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
--=-EcTUSx+WBwhuIzIa6dfR Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I haven't really done any kernel development, but from what I've seen the technical issues are mostly eliminating #ifdef'd compatibility code and getting the rest of the code up to kernel standards (better use of sysfs etc.). Zaptel cards are capable of providing pretty precise timing. The current Zaptel drivers expose that through a non-standard interface at the moment - it'd be nice to switch that to using the high resolution timer support in the rest of the kernel. There are also a couple of drivers that use some code / firmware from Octasic. The Octasic code is GPLv2 (or later) as far as I can see. Don't know about licensing for the Octasic or the Digium firmware though. Politically, it would be nice if Digium would at least sign off on the idea if they don't/can't contribute any developer resources at this time. Digium actively develops the Zaptel drivers, at least fixing bugs and adding support for new hardware they have developed. I haven't seen any work from them (publically at least) on restructuring the code that would make it more acceptable for inclusion in the kernel. Jeff --=-EcTUSx+WBwhuIzIa6dfR Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBHFn+Frtk7xyyIQRERAqMgAJ4qLAwhB27QJeMI/cqoo5nByuoJegCfX18C dZxefCToczQZSy3CXa1OGcM= =HW+F -----END PGP SIGNATURE----- --=-EcTUSx+WBwhuIzIa6dfR--
I agree, and we have started to pick up some of these types of drivers, but we need to get some kind of approval from the original driver authors in order to make it work. Project 005 is currently one of these They are currently working directly with the Linux wireless developers, and know how to get code into the tree if they want to. I'm not too worried about them. But if they want our help, I'm sure we could do so. Nice, but I think we need further crypto core work in order to be able But we need to at least try :) thanks, greg k-h _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
Actually, no. I just happened to fight with a wireless USB thingy lately which used their prism2_usb driver (it supports over 40 wireless USB Adapters, not bad - different manufacturers, probably almost identical inside). I searched their list a bit (which is not very active), as I remember, there were some posts asking the developers about mainline inclusion, unfortunately, without any reply. Later, I've read some article about the Linux Driver Project and it made me wonder: why there are so many free drivers, often with specs and proper documentation, but outside of the mainline kernel. And hence my In their current state (2.2, 2.4 kernel patch), most probably, yes. I wonder how much does it remind (or at least, some selected functionality) hardware crypto devices in current kernel's drivers/crypto/. Note that currently Linux doesn't support any hardware crypto cards, what a loss ;) -- Tomasz Chmielewski http://blog.wpkg.org _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
There are typically varying reasons for this but the most common are: 1) Never even tried to submit for mainline inclusion 2) Can't deal with constructive, or possibly harsh criticism of the code. Different subsystems have their different standards for code quality and legibility, and some folks just won't abide by them in any way. 3) Thoughts of losing control and not being able to be nimble enough to get new modifications out to people. 4) "Only 2 people in the whole world use this device, so mainline doesn't care about having the driver" which is a bunch of crap. Even if only 2 people use it, the driver itself may be a useful example for a similar device, or might be able to be rolled into a more generic driver or something. Additionally, you get the tweaks to kernel interface changes and such largely for free and don't have to be in the distribution game. In my own experience, if you believe in writing high quality code and really doing things in the best way possible, you can get your code into mainline, really without that much effort. If your coding style is to just slap code at it and make it work "on your box" and damn legibility, you might have some issues getting your code in mainline. -- David Hollis <dhollis@davehollis.com> _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
So, here is the answer: http://lists.linux-wlan.com/pipermail/linux-wlan-devel/2007-October/003724.html In short: "I'd love to see prism2_usb support go into the mainline kernel, but it's not something I personally have the time to work on. If someone else wants to take up the torch, I'll provide what assistance I can." So, is there someone ready to take up the torch? -- Tomasz Chmielewski http://blog.wpkg.org _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
You forgot the other part of that message: The basic problem is that in order to make linux-wlan-ng (or even just prism2_usb) suitable for kernel inclusion, so much work is involved that it would actually be less work to write a new driver from scratch (or add prism2_usb support to the in-kernel hostap/prism2 driver) So, does anyone have this device, and thinks they might want to do this? thanks, greg k-h _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
I do not have one. If anyone knows where I can acquire one, please let me know. Thanks, John -- John W. Linville linville@tuxdriver.com _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
I have one (Acer Warplink USB Adapter). Maybe someone from linux-wlan list has some other devices, too. You want one? -- Tomasz Chmielewski http://wpkg.org _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
Yes, definitely. I'll be happy to buy one if you can identify one. Or if you want to send me yours, I'll be happy to accept it. :-) Thanks, John -- John W. Linville linville@tuxdriver.com _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
I forgot: There is also the more fundamental question whether all of this shouldn't rather be done in userspace, like with FireWire set top boxes that are commonly used in North America. But I am unable to assess this due to lack of knowledge of the DVB side. -- Stefan Richter -=====-==--- -==- -==== http://arcgraph.de/sr/ _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
The DVB API assumes that devices are handled by kernel modules, that's why I created one in the first place. Additionally, there are performance considerations that have to be taken into account (receiving the stream has to happen in realtime, otherwise the video and audio streams would stutter), so this might pose another need for a kernel module (I don't know enough about the raw1394 API to judge that, though). andy _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
The larger concept of DVB as regards to North America is the area of application, ie DVB though FTA is applicable, CA (Conditional Access) aka scrambled streams do not used in a standardized way, ie using a standard EN50221 protocol, but proprietary ways. With regards to the descrambling, it does make sense to have those parts in kernel, since, the the Userspace applications make use of a thin kernel interface, within the DVB API interface. Well at least for applications to make use of the hardware it makes sense to use the kernel interface rather than to redefine a completely new userspace CA interface. Regards, Manu _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
http://forum.digital-everywhere.com/viewforum.php?f=34 shows that people are eager to test the driver. One user even posted an own small fixup patch there. I.e. we should get it into mainline sooner rather than later. A conversion to the new firewire stack would be easier after mainline merge anyway, from the development POV. Mauro, did the status regarding the driver's interface with the DVB subsystem change since your comment in April? http://driverdev.linuxdriverproject.org/pipermail/devel/2008-April/000382.html -- Stefan Richter -=====-==--- -==- -==== http://arcgraph.de/sr/ _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
Currently as it stands, the driver is usable, AFAICS. Albeit the FWIW, He is not the DVB subsystem maintainer and has almost no practical knowledge about it, least his comments be taken seriously into some development stage. Regards, Manu _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
There is a patch on the way for the DVB-S2 devices (not recognized correctly). I can submit this patch now, but I would rather add some code so the DVB-S2 receivers can use the DVB-S functionality (DVB-S2 is only possible with the change to multiproto). I'll try to do this before the end of the month. I can have a look at the switch from ieee1394 to firewire, but I'm rather busy right now (final exams and some other urgent business afterwards). Regards, Ben _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
I've had some changes to add multi delivery system capability, but the demodulator used, needs explicit definition of FEC and other parameters. Currently, all existing DVB applications expect FEC to be AUTO, This brings in the larger problem that i have been trying to tackle. If you prefer to send a patch, would wait for that instead, as i can channelize the time for other stuff that i have been up with. Regards, Manu _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
The patch that fixes device recognition can be found at http://files.bbackx.com/index.php?dir=firedtv/&file=device-recognition.patch It only makes sure that a DVB-S2 device is really recognized as a S2, nothing else is added yet. It's using the string containing the model that is stored in the configuration rom, the older version was using some hardware-revision-dependent (is this English? ;-) ) part of the rom. Greetings, Ben _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
On Sun, 15 Jun 2008 18:28:07 +0200 Yes. The issues I've pointed there were fixed. Still, the remote controller handling seems to be using a bad approach. Instead of registering a key table, and allowing IR code redefinition, the firesat-rc has a hardcoded table that returns a keycode, instead of a scancode. This seems bad, since newer IR's may have a different scancode table. Also, I suspect that this approach doesn't allow the loading of other keys, if you want to use a different IR with more keys. IMO, it would be interesting to get Dmitry's review for the input code. Cheers, Mauro _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
Hmm, unless I am looking in the wrong place the driver still uses static input device allocation and so is unlikely to work on any recent (year or so) kernel. The keymap is a bit interesting too as I did not know remotes having alpha keys such as P, M, R, etc. input_sync() calls are also missing, sysfs links, but type setup, name, phys, etc. -- Dmitry _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
On Sat, 14 Jun 2008 23:55:19 +0200 I would add other things, like: - usage of HZ, instead of msecs_to_jiffies(); - its own implementation of wait_event_timeout(); - abuse of typedef's; - some structures are defined differently, depending on endiannes, at avc_api.h. Cheers, Mauro _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
HI Mauro, Nothing to do with this thread, but how about sending drx397xd driver to staging tree? -- Best Regards, Felipe Balbi felipebalbi@users.sourceforge.net _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
On Wed, 18 Jun 2008 15:13:46 +0300 It is fine to send it to -staging, or to keep at V4L/DVB development tree. I prefer to keep it at the development tree, since this is already reflected at linux-next. Cheers, Mauro _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
