dear linux kernel people,
i was staggered to find that swansmart (smlink.com) have a GPL
driver for their smart usb 56k modem.
they also do a pci version: their download supports both (usb+pci)
they also provide an AC97 ALSA driver (patch is against 2.6.0)
this PCI ALSA driver is based on the i8x0 / MX 440 modem driver,
by Jaroslav Kysela <[email protected]>.
all their code is GPL. this is very cool.
it is available here:
http://www.smlink.com/main/down/slmodem-2.9.9.tar.gz
i trust that someone will download, check it, and if
appropriate, incorporate it into the mainstream linux kernel.
the swansmart usb 56k modem is dirt cheap (it was available in
the uk six months ago for about ?9), and is extremely popular
in australia and the far east.
l.
--
--
Truth, honesty and respect are rare commodities that all spring from
the same well: Love. If you love yourself and everyone and everything
around you, funnily and coincidentally enough, life gets a lot better.
--
<a href="http://lkcl.net"> lkcl.net </a> <br />
<a href="mailto:[email protected]"> [email protected] </a> <br />
On Thu, 2004-09-09 at 12:47, Luke Kenneth Casson Leighton wrote:
> i trust that someone will download, check it, and if
> appropriate, incorporate it into the mainstream linux kernel.
The ALSA bit is already in the kernel at sound/pci/intel8x0m.c, I don't
know when it was added though. Not sure of the status of the USB bit,
but I think it is normally up to the author to submit something rather
than some 3rd party...
Unfortunately the ALSA driver doesn't work for me, I just get NO
DIALTONE and the following in the kernel logs:
codec_semaphore: semaphore is not ready [0x1][0x300300]
codec_write 1: semaphore is not ready for register 0x54
I only tried it out last night, and I don't really need the modem in my
laptop much (it never really travels much further than the sofa :) so I
haven't really investigated much.
The laptop is a VAIO from several years ago. lspci shows the modem as:
0000:00:1f.6 Modem: Intel Corp. Intel 537 [82801BA/BAM AC'97 Modem] (rev 03)
Ian.
--
Ian Campbell
Current Noise: Dream Theater - About to Crash
Q: Why did the lone ranger kill Tonto?
A: He found out what "kimosabe" really means.
On Thu, Sep 09, 2004 at 12:47:47PM +0100, Luke Kenneth Casson Leighton wrote:
> i was staggered to find that swansmart (smlink.com) have a GPL
> driver for their smart usb 56k modem.
>
> they also do a pci version: their download supports both (usb+pci)
>
> they also provide an AC97 ALSA driver (patch is against 2.6.0)
>
> this PCI ALSA driver is based on the i8x0 / MX 440 modem driver,
> by Jaroslav Kysela <[email protected]>.
>
> all their code is GPL. this is very cool.
Most of their code is not GPL'ed. It does have a COPYING file, but that
looks like a BSD license to me. The only (implicitly) GPL'ed part is
the ALSA patch.
> it is available here:
>
> http://www.smlink.com/main/down/slmodem-2.9.9.tar.gz
>
> i trust that someone will download, check it, and if
> appropriate, incorporate it into the mainstream linux kernel.
It's not a GPL driver, the kernel part contains a binary object file
(drivers/amrlibs.o) so I don't see how it can be included in the main
kernel tree. OTOH, at first glance only the PCI driver needs that
binary blob, the USB driver doesn't.
Erik
--
+-- Erik Mouw -- http://www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
>It's not a GPL driver, the kernel part contains a binary object file
>(drivers/amrlibs.o) so I don't see how it can be included in the main
>kernel tree. OTOH, at first glance only the PCI driver needs that
>binary blob, the USB driver doesn't.
Droping in. :)
Kernel part is not required, slmodemd works with the snd-intel8x0m Alsa
driver. For me at least, and for the PCI version.
--
Tvrtko August Ursulin
Software Engineer, Sophos
Tel: 01235 559933
Web: http://www.sophos.com
Sophos - protecting businesses against viruses and spam
On Thu, Sep 09, 2004 at 03:46:14PM +0200, Erik Mouw wrote:
> > all their code is GPL. this is very cool.
>
> Most of their code is not GPL'ed. It does have a COPYING file, but that
> looks like a BSD license to me. The only (implicitly) GPL'ed part is
> the ALSA patch.
well, better than nothing.
> > it is available here:
> >
> > http://www.smlink.com/main/down/slmodem-2.9.9.tar.gz
> >
> > i trust that someone will download, check it, and if
> > appropriate, incorporate it into the mainstream linux kernel.
>
> It's not a GPL driver, the kernel part contains a binary object file
> (drivers/amrlibs.o) so I don't see how it can be included in the main
> kernel tree.
DRAT.
> OTOH, at first glance only the PCI driver needs that
> binary blob, the USB driver doesn't.
ah ha!
i sent them a message, see if they react well to licensing the
rest as GPL.
l.
On Thu, Sep 09, 2004 at 03:04:58PM +0100, [email protected] wrote:
> >It's not a GPL driver, the kernel part contains a binary object file
> >(drivers/amrlibs.o) so I don't see how it can be included in the main
> >kernel tree. OTOH, at first glance only the PCI driver needs that
> >binary blob, the USB driver doesn't.
>
> Droping in. :)
>
> Kernel part is not required, slmodemd works with the snd-intel8x0m Alsa
> driver. For me at least, and for the PCI version.
ah! yes! apt-cache show sl-modem-daemon.
On Thu, Sep 09, 2004 at 12:47:47PM +0100, Luke Kenneth Casson Leighton wrote:
> dear linux kernel people,
>
> i was staggered to find that swansmart (smlink.com) have a GPL
> driver for their smart usb 56k modem.
>
> i trust that someone will download, check it, and if
> appropriate, incorporate it into the mainstream linux kernel.
It's mostly GPL'ed, but there are binary-only objects both in the
user-mode daemon (modem/dsplibs.o) and in the kernel driver
(drivers/amrlibs.o).
The good news is that there a completely GPL'ed, source-complete
driver already in the 2.6 kernel, sound/pci/intel8x0m.c, which will
work with the user-mode daemon found in the smlink.com distribution.
This driver doesn't have all of the functionality of slamr driver
(which requires the propietary, binary-only object file) --- most
notably, ATM1 doesn't work when using the completely open-source
intl8x0m driver. However, it does work just fine, and so as long as
you don't mind using the propietary object file in user-space, it's a
great solution. I've been using the smlink daemon with both the
open-source and partial-propietary driver, and both work just fine on
my T40 laptop.
- Ted
On Thu, 09 Sep 2004 18:50:06 +0200
Theodore Ts'o <[email protected]> wrote:
> The good news is that there a completely GPL'ed, source-complete
> driver already in the 2.6 kernel, sound/pci/intel8x0m.c, which will
> work with the user-mode daemon found in the smlink.com distribution.
> This driver doesn't have all of the functionality of slamr driver
> (which requires the propietary, binary-only object file) --- most
> notably, ATM1 doesn't work when using the completely open-source
> intl8x0m driver.
Those functionality limitations in open source modem drivers are just
"unimplemented yet" stuff. The final goal is to replace proprietary
slamr driver completely.
Best Regards,
Sasha.
SashaK <[email protected]> writes:
> On Sat, 11 Sep 2004 12:26:00 +0200 (MEST)
> Mikael Pettersson <[email protected]> wrote:
>
>> I hope you succeed with open-sourcing all of slmodem's driver
>> code. My Targa Athlon64 laptop has the AMR thingy and the
>> 32-bit x86 binary only slmodem driver prevents me from using
>> the modem while running a 64-bit kernel.
>
> You mean to GPL user-space program slmodemd?
> I think it is good idea, but unfortunately this code is not just my, and
> final decision was 'no'.
One way that would work is to make the binary parts of your driver run
in user space and let the kernel part just provide a kind of simple
sound card. The later should be much easier to free.
Modern CPUs are usually fast enough that the additional latency
caused by this doesn't matter.
The 64bit kernel can run 32bit programs without problems.
-Andi
On Sat, 11 Sep 2004 16:09:41 +0200
Andi Kleen <[email protected]> wrote:
> SashaK <[email protected]> writes:
>
> > You mean to GPL user-space program slmodemd?
> > I think it is good idea, but unfortunately this code is not just my,
> > and final decision was 'no'.
>
> One way that would work is to make the binary parts of your driver run
> in user space and let the kernel part just provide a kind of simple
> sound card.
It is done so - user space daemon (with binary part) interacts with ALSA
drivers.
> The later should be much easier to free.
There was such approach, but seems it was wrong.
> The 64bit kernel can run 32bit programs without problems.
This should be possible (don't check yet). But the problem here was
that AMD64 machines are usually based on non-Intel chipsets
(VIA, NVidia), supports for those chipsets were added to ALSA just in
last days. Now it may be tested with recent version of ALSA.
Sasha.
On Sat, Sep 11, 2004 at 11:07:53PM +0300, SashaK wrote:
> On Sat, 11 Sep 2004 16:09:41 +0200
> Andi Kleen <[email protected]> wrote:
>
> > SashaK <[email protected]> writes:
> >
> > > You mean to GPL user-space program slmodemd?
> > > I think it is good idea, but unfortunately this code is not just my,
> > > and final decision was 'no'.
> >
> > One way that would work is to make the binary parts of your driver run
> > in user space and let the kernel part just provide a kind of simple
> > sound card.
>
> It is done so - user space daemon (with binary part) interacts with ALSA
> drivers.
Ok, thanks for the correction.
>
> > The later should be much easier to free.
>
> There was such approach, but seems it was wrong.
What's the problem exactly - your kernel part is still binary only?
>
> > The 64bit kernel can run 32bit programs without problems.
>
> This should be possible (don't check yet). But the problem here was
> that AMD64 machines are usually based on non-Intel chipsets
> (VIA, NVidia), supports for those chipsets were added to ALSA just in
> last days. Now it may be tested with recent version of ALSA.
One small issue is that when you have custom ioctls there may
be some need to add them to the compat layer, otherwise the user
space part cannot issue them. This could be even done in a separate
module from your driver though.
-Andi
On 12 Sep 2004 10:30:39 +0200
Andi Kleen <[email protected]> wrote:
> > > The later should be much easier to free.
> >
> > There was such approach, but seems it was wrong.
>
> What's the problem exactly - your kernel part is still binary only?
Current binary kernel part (slamr) is not a problem - it may be removed,
then ALSA drivers will be finished. But user-space program still have
binary code and there is no replacement.
> >
> > > The 64bit kernel can run 32bit programs without problems.
> >
> > This should be possible (don't check yet). But the problem here was
> > that AMD64 machines are usually based on non-Intel chipsets
> > (VIA, NVidia), supports for those chipsets were added to ALSA just
> > in last days. Now it may be tested with recent version of ALSA.
>
> One small issue is that when you have custom ioctls there may
> be some need to add them to the compat layer, otherwise the user
> space part cannot issue them. This could be even done in a separate
> module from your driver though.
Thanks for explanations.
Sasha.