On FC4 this is what I get from modinfo for snd-sb16 : snits@newton:/home/snits/src/linux-2.6.15.4/sound=>modinfo snd-sb16 filename: /lib/modules/2.6.15-1.1831_FC4/kernel/sound/isa/sb/snd-sb16.ko author: Jaroslav Kysela license: GPL description: Sound Blaster 16 vermagic: 2.6.15-1.1831_FC4 686 REGPARM 4KSTACKS gcc-4.0 depends: snd-sb-common,snd-opl3-lib,snd,snd-mpu401-uart,snd-sb16-dsp,snd-sb16-csp alias: pnp:cCTL0024dCTL0031* alias: pnp:cCTL0025dCTL0031* alias: pnp:cCTL0026dCTL0031* alias: pnp:cCTL0027dCTL0031* alias: pnp:cCTL0028dCTL0031* alias: pnp:cCTL0029dCTL0031* alias: pnp:cCTL002adCTL0031* alias: pnp:cCTL002bdCTL0031* alias: pnp:cCTL002cdCTL0031* alias: pnp:cCTL0051dCTL0001* alias: pnp:cCTL0070dCTL0001* alias: pnp:cCTL0080dCTL0041* alias: pnp:cCTL0086dCTL0041* alias: pnp:cCTL00f0dCTL0043* alias: pnp:ctBA03b0dPNPb003* srcversion: 6E0689729B47273884520A3 parm: csp:ASP/CSP chip support. (array of int) parm: mic_agc:Mic Auto-Gain-Control switch. (array of int) parm: dma16:16-bit DMA # for SB16 driver. (array of int) parm: dma8:8-bit DMA # for SB16 driver. (array of int) parm: irq:IRQ # for SB16 driver. (array of int) parm: fm_port:FM port # for SB16 PnP driver. (array of long) parm: mpu_port:MPU-401 port # for SB16 driver. (array of long) parm: port:Port # for SB16 driver. (array of long) parm: isapnp:PnP detection for specified soundcard. (array of bool) parm: enable:Enable SoundBlaster 16 soundcard. (array of bool) parm: id:ID string for SoundBlaster 16 soundcard. (array of charp) parm: index:Index value for SoundBlaster 16 soundcard. (array of int) On Mon, 2006-02-27 at 20:06 -0700, Victor Odhner wrote: > Joshua Zeidner wrote: > > First off, Microsoft is making that claim. > > That doesn't make it false. I made an off-handed comment to the > Slashdot post that was contradicting Microsoft's claims. That > post pointed to a very brief article that just said, "I found some > distros that work OK on old stuff." But my complaint was based > on my own experience, having gone through a number of modern > distros that would not talk to this sound card, and said annoying > things such as "No soundcards detected". Gimme a break! Go > to a little trouble, you can see that *something* is there, even if > you can't make a noise with it. > > Oh and by the way, XP can run this old 16-bit sound blaster. > So there you go. (Never mind that I can't resurrect his XP setup > because I don't have the original disk or the key. Reminded me > why Stallman rebelled in the first place! But I digress.... ) > > Siri Amrit Kaur wrote: > > Have you tried Vector or one of the distros that's optimized for > > older hardware? I think Vector and Slackware still use an older > > 2.4.* kernel by default. Maybe it would have drivers . . . > > Similarly, Dennis Kibbe wrote: > > I know PLUGers that have installed Slackware on old 486 > > ThinkPads. ... Many distros (like Slackware, for instance) > > have versions going back to release 1.0 still on the servers. > > I don't want a different kernel, I want to add a driver. > Like I said, I am not interested in distro shopping. This distro > does most of what I want done. The current kernel is set up to > have drivers added, and the driver is the only change I want to > make. Why regress to an older kernel, with bugs that have been > fixed? Why can't I just plug in a binary driver, as with Windows? > > Suppose I tried an older distro that worked fine with the sound > card, but complained that it would not read my USB thumb drive. > I'm afraid I would have heard the same thing: Try another distro, > or upgrade the kernel to get that support. My complaint is that > upgrading a kernel *loses* the support for the sound card. > Ya can't win fer losing. > > ... Which takes us to Kevin Brown, who wrote: > > at some point the devs do have to stop trying to keep lesser used > > drivers up to date with a newer way of doing things. > > Are you saying the older drivers don't plug in the same way that the > newer ones do? Why would they invalidate an API that was working? > Note, Windows XP did a lot of that, for security reasons; but those > were old drivers that required dangerous privileges. I would have > thought Linux drivers would be safer from the start. > > My lack of this knowledge is probably the reason for my annoyance. > I'm a developer myself, and I understand that it's hard to make an > omelet without breaking some eggs. But when we use "insmod", that > takes the specified driver and links it into the kernel, presumably > using a somewhat generalized API. Right? Does each driver that > the kernel's willing to accept require some additional ugliness in the > kernel, creating a cost that has to be limited by banning some old > drivers? > > I'm also assuming that the drivers consist of rather primitive and > self-contained code, so that they do not need to interface with the > system's standard libraries. Even if they did, hopefully those APIs > would remain valid. > > I'm willing to learn . . . > > --------------------------------------------------- > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us > To subscribe, unsubscribe, or to change you mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > --------------------------------------------------- PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us To subscribe, unsubscribe, or to change you mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss