Hi,
While fixing some "deprecated" issues in the OSS drivers, I wondered whether
this makes sense, as entire OSS is marked deprecated. Will OSS make it until
2.7, or will it be dropped soon ? (In other words, should I take care of the
OSS drivers or not bother about them)
Best regards,
Jos Hulzink
On Mon, Mar 22, 2004 at 07:55:52PM +0100, Jos Hulzink wrote:
> Hi,
>
> While fixing some "deprecated" issues in the OSS drivers, I wondered whether
> this makes sense, as entire OSS is marked deprecated. Will OSS make it until
> 2.7, or will it be dropped soon ? (In other words, should I take care of the
> OSS drivers or not bother about them)
In my not so humble opinion, throwing OSS away will be a big mistake,
as long as there are people willing to maintain it. Keep it there and
let the users (or distributions) choose what to use. I've seen
multiple bug reports of cards that work with OSS and don't work with
ALSA (and vice versa), so keeping both seems the proper thing to
do. Personally, I maintain one OSS driver, and fix bugs in others
occasionally.
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
On Monday 22 March 2004 21:22, Muli Ben-Yehuda wrote:
> In my not so humble opinion, throwing OSS away will be a big mistake,
> as long as there are people willing to maintain it. Keep it there and
> let the users (or distributions) choose what to use. I've seen
> multiple bug reports of cards that work with OSS and don't work with
> ALSA (and vice versa), so keeping both seems the proper thing to
> do. Personally, I maintain one OSS driver, and fix bugs in others
> occasionally.
Looking at the amount of warnings in the OSS drivers (depricated
check_region), the OSS drivers seem -with all respect for your hard work- not
so well maintained anymore. I'm willing to fix them all, but not if entire
OSS is ditched away Real Soon Now (tm).
Best regards,
Jos Hulzink
On Mon, Mar 22, 2004 at 10:32:20PM +0100, Jos Hulzink wrote:
> On Monday 22 March 2004 21:22, Muli Ben-Yehuda wrote:
> > In my not so humble opinion, throwing OSS away will be a big mistake,
> > as long as there are people willing to maintain it. Keep it there and
> > let the users (or distributions) choose what to use. I've seen
> > multiple bug reports of cards that work with OSS and don't work with
> > ALSA (and vice versa), so keeping both seems the proper thing to
> > do. Personally, I maintain one OSS driver, and fix bugs in others
> > occasionally.
>
> Looking at the amount of warnings in the OSS drivers (depricated
> check_region), the OSS drivers seem -with all respect for your hard
> work- not so well maintained anymore. I'm willing to fix them all,
> but not if entire OSS is ditched away Real Soon Now (tm).
Here's a log of a 'make allyesconfig', followed by 'make
sound/oss/', with gcc-3.3.2. This is really not too bad, almost
everything is trivial check_region -> request_region conversions. The
great majority of drivers compile just fine, and at least some of them
(those I have the hardware for) definitely work, too ;-)
I intend to go through these warnings and fix them, now that I'm aware
of them. If you or anyone else want to collaborate on it,
great. Andrew Morton is taking OSS patches - I sent one on Saturday
night that's in 2.6.5-rc2-mm1 right now.
Cheers,
Muli
cd /home/muli/kernel/linux-2.5/
make sound/oss/
make[1]: `arch/i386/kernel/asm-offsets.s' is up to date.
CC sound/oss/gus_card.o
sound/oss/gus_card.c: In function `probe_gus':
sound/oss/gus_card.c:76: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
sound/oss/gus_card.c:78: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
sound/oss/gus_card.c:93: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
sound/oss/gus_card.c:94: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
CC sound/oss/gus_midi.o
CC sound/oss/gus_vol.o
CC sound/oss/gus_wave.o
CC sound/oss/ics2101.o
CC sound/oss/pas2_card.o
CC sound/oss/pas2_midi.o
CC sound/oss/pas2_mixer.o
CC sound/oss/pas2_pcm.o
CC sound/oss/sb_card.o
CC sound/oss/sb_common.o
sound/oss/sb_common.c: In function `sb_dsp_detect':
sound/oss/sb_common.c:523: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
sound/oss/sb_common.c: In function `probe_sbmpu':
sound/oss/sb_common.c:1224: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
CC sound/oss/sb_audio.o
CC sound/oss/sb_midi.o
CC sound/oss/sb_mixer.o
CC sound/oss/sb_ess.o
CC sound/oss/dev_table.o
CC sound/oss/soundcard.o
CC sound/oss/sound_syms.o
CC sound/oss/audio.o
CC sound/oss/audio_syms.o
CC sound/oss/dmabuf.o
CC sound/oss/midi_syms.o
CC sound/oss/midi_synth.o
CC sound/oss/midibuf.o
CC sound/oss/sequencer.o
CC sound/oss/sequencer_syms.o
CC sound/oss/sound_timer.o
CC sound/oss/sys_timer.o
LD sound/oss/sound.o
CC sound/oss/cs4232.o
sound/oss/cs4232.c: In function `probe_cs4232':
sound/oss/cs4232.c:141: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
sound/oss/cs4232.c:193: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
CC sound/oss/ad1848.o
sound/oss/ad1848.c: In function `ad1848_detect':
sound/oss/ad1848.c:1580: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
sound/oss/ad1848.c: In function `probe_ms_sound':
sound/oss/ad1848.c:2530: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
sound/oss/ad1848.c: At top level:
sound/oss/ad1848.c:2967: warning: `id_table' defined but not used
CC sound/oss/aedsp16.o
CC sound/oss/pss.o
sound/oss/pss.c: In function `probe_pss':
sound/oss/pss.c:191: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
sound/oss/pss.c: In function `configure_nonsound_components':
sound/oss/pss.c:640: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
sound/oss/pss.c: In function `probe_pss_mpu':
sound/oss/pss.c:710: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
sound/oss/pss.c: In function `probe_pss_mss':
sound/oss/pss.c:1004: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
CC sound/oss/mpu401.o
sound/oss/mpu401.c: In function `probe_mpu401':
sound/oss/mpu401.c:1217: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
CC sound/oss/trix.o
sound/oss/trix.c: In function `trix_set_wss_port':
sound/oss/trix.c:85: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
sound/oss/trix.c: In function `probe_trix_wss':
sound/oss/trix.c:147: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
sound/oss/trix.c: In function `probe_trix_sb':
sound/oss/trix.c:292: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
LD sound/oss/sb_lib.o
CC sound/oss/uart401.o
CC sound/oss/opl3sa.o
sound/oss/opl3sa.c: In function `probe_opl3sa_wss':
sound/oss/opl3sa.c:114: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
sound/oss/opl3sa.c:122: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
CC sound/oss/sscape.o
sound/oss/sscape.c: In function `detect_ga':
sound/oss/sscape.c:737: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
sound/oss/sscape.c: In function `sscape_pnp_init_hw':
sound/oss/sscape.c:1113: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
sound/oss/sscape.c: In function `detect_sscape_pnp':
sound/oss/sscape.c:1132: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
sound/oss/sscape.c:1137: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
CC sound/oss/mad16.o
sound/oss/mad16.c: In function `wss_init':
sound/oss/mad16.c:322: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
CC sound/oss/opl3sa2.o
LD sound/oss/pas2.o
LD sound/oss/sb.o
CC sound/oss/kahlua.o
( \
echo 'static unsigned char * maui_os = NULL;'; \
echo 'static int maui_osLen = 0;'; \
) > sound/oss/maui_boot.h
CC sound/oss/maui.o
sound/oss/maui.c: In function `probe_maui':
sound/oss/maui.c:307: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
CC sound/oss/uart6850.o
LD sound/oss/gus.o
CC sound/oss/adlib_card.o
CC sound/oss/opl3.o
CC sound/oss/v_midi.o
CC sound/oss/sgalaxy.o
sound/oss/sgalaxy.c: In function `probe_sgalaxy':
sound/oss/sgalaxy.c:89: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
sound/oss/sgalaxy.c:97: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
CC sound/oss/ad1816.o
CC sound/oss/ad1889.o
sound/oss/ad1889.c: In function `ad1889_ac97_init':
sound/oss/ad1889.c:853: warning: comparison is always false due to limited range of data type
CC sound/oss/ac97_codec.o
CC sound/oss/aci.o
CC sound/oss/awe_wave.o
CC sound/oss/via82cxxx_audio.o
CC sound/oss/ymfpci.o
CC sound/oss/nm256_audio.o
CC sound/oss/ac97.o
CC sound/oss/i810_audio.o
CC sound/oss/sonicvibes.o
CC sound/oss/cmpci.o
sound/oss/cmpci.c: In function `cm_release_mixdev':
sound/oss/cmpci.c:1465: warning: unused variable `s'
sound/oss/cmpci.c: At top level:
sound/oss/cmpci.c:2865: warning: `cmpci_pci_tbl' defined but not used
CC sound/oss/es1370.o
CC sound/oss/es1371.o
CC sound/oss/esssolo1.o
CC sound/oss/cs46xx.o
CC sound/oss/maestro.o
CC sound/oss/maestro3.o
CC sound/oss/trident.o
CC sound/oss/rme96xx.o
CC sound/oss/btaudio.o
CC sound/oss/ali5455.o
CC sound/oss/forte.o
CC sound/oss/ac97_plugin_ad1980.o
CC sound/oss/cs4281/cs4281m.o
LD sound/oss/cs4281/cs4281.o
LD sound/oss/cs4281/built-in.o
CC sound/oss/emu10k1/audio.o
CC sound/oss/emu10k1/cardmi.o
CC sound/oss/emu10k1/cardmo.o
CC sound/oss/emu10k1/cardwi.o
CC sound/oss/emu10k1/cardwo.o
CC sound/oss/emu10k1/ecard.o
CC sound/oss/emu10k1/efxmgr.o
CC sound/oss/emu10k1/emuadxmg.o
CC sound/oss/emu10k1/hwaccess.o
CC sound/oss/emu10k1/irqmgr.o
CC sound/oss/emu10k1/main.o
CC sound/oss/emu10k1/midi.o
CC sound/oss/emu10k1/mixer.o
CC sound/oss/emu10k1/passthrough.o
CC sound/oss/emu10k1/recmgr.o
CC sound/oss/emu10k1/timer.o
CC sound/oss/emu10k1/voicemgr.o
LD sound/oss/emu10k1/emu10k1.o
LD sound/oss/emu10k1/built-in.o
LD sound/oss/built-in.o
CC [M] sound/oss/wavfront.o
sound/oss/wavfront.c: In function `detect_wavefront':
sound/oss/wavfront.c:2427: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
sound/oss/wavfront.c: At top level:
sound/oss/wavfront.c:2498: warning: `errno' defined but not used
CC [M] sound/oss/wf_midi.o
sound/oss/wf_midi.c: In function `detect_wf_mpu':
sound/oss/wf_midi.c:788: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
CC [M] sound/oss/yss225.o
LD [M] sound/oss/wavefront.o
CC [M] sound/oss/msnd.o
sound/oss/msnd.c: In function `msnd_register':
sound/oss/msnd.c:63: warning: `MOD_INC_USE_COUNT' is deprecated (declared at include/linux/module.h:515)
sound/oss/msnd.c: In function `msnd_unregister':
sound/oss/msnd.c:84: warning: `MOD_DEC_USE_COUNT' is deprecated (declared at include/linux/module.h:527)
CC [M] sound/oss/msnd_classic.o
In file included from sound/oss/msnd_classic.c:3:
sound/oss/msnd_pinnacle.c: In function `probe_multisound':
sound/oss/msnd_pinnacle.c:1123: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
CC [M] sound/oss/msnd_pinnacle.o
sound/oss/msnd_pinnacle.c: In function `probe_multisound':
sound/oss/msnd_pinnacle.c:1123: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
sound/oss/msnd_pinnacle.c: In function `msnd_init':
sound/oss/msnd_pinnacle.c:1811: warning: `check_region' is deprecated (declared at include/linux/ioport.h:121)
Compilation finished at Mon Mar 22 23:48:37
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
On Mon, Mar 22, 2004 at 07:55:52PM +0100, Jos Hulzink wrote:
> Hi,
>
> While fixing some "deprecated" issues in the OSS drivers, I wondered whether
> this makes sense, as entire OSS is marked deprecated. Will OSS make it until
> 2.7, or will it be dropped soon ? (In other words, should I take care of the
> OSS drivers or not bother about them)
OSS will stay in 2.6 (2.6 is a stable kernel series) but it will most
likely be removed in 2.7.
I wouldn't spend time to fix deprecated warnings in OSS code, such
cleanups are wasted time for code that will most likely be removed in
2.7.
> Best regards,
>
> Jos Hulzink
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, Mar 22, 2004 at 10:22:21PM +0200, Muli Ben-Yehuda wrote:
>...
> I've seen
> multiple bug reports of cards that work with OSS and don't work with
> ALSA (and vice versa), so keeping both seems the proper thing to
>...
Wouldn't it be better to get the ALSA drivers working in such cases?
It's really not a good idea to have two codebases for the same purpose.
> Cheers,
> Muli
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, Mar 22, 2004 at 10:59:21PM +0100, Adrian Bunk wrote:
> On Mon, Mar 22, 2004 at 10:22:21PM +0200, Muli Ben-Yehuda wrote:
> >...
> > I've seen
> > multiple bug reports of cards that work with OSS and don't work with
> > ALSA (and vice versa), so keeping both seems the proper thing to
> >...
>
> Wouldn't it be better to get the ALSA drivers working in such cases?
It would; but until they do, ditching OSS is a regression.
> It's really not a good idea to have two codebases for the same
> purpose.
It is if neither one is witholding effort from the other, and neither
one does a perfect job for all cases.
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
On Tue, Mar 23, 2004 at 12:03:27AM +0200, Muli Ben-Yehuda wrote:
> On Mon, Mar 22, 2004 at 10:59:21PM +0100, Adrian Bunk wrote:
> > On Mon, Mar 22, 2004 at 10:22:21PM +0200, Muli Ben-Yehuda wrote:
> > >...
> > > I've seen
> > > multiple bug reports of cards that work with OSS and don't work with
> > > ALSA (and vice versa), so keeping both seems the proper thing to
> > >...
> >
> > Wouldn't it be better to get the ALSA drivers working in such cases?
>
> It would; but until they do, ditching OSS is a regression.
>...
Clearly.
Ditching OSS at the beginning of 2.7 will give several years to identify
and fix such regressions.
> Cheers,
> Muli
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
El Mon, 22 Mar 2004 22:57:09 +0100 Adrian Bunk <[email protected]> escribi?:
> OSS will stay in 2.6 (2.6 is a stable kernel series) but it will most
> likely be removed in 2.7.
Personally, as an user, I'd like to have the OSS drivers which don't have
a ALSA equivalent for my old hardware. There're several
sound cards with both ALSA and OSS drivers where ALSA works
much better 99% of the time. Those could be safely removed
(even in the 2.6 timeframe, I'd argue) but I'd like to keep the ones
without an alsa equivalent for my old hardware (specially now that we
have a -tiny tree ;) however I can understand that if they don't
have a maintainer they'll get removed...
Em Seg, 2004-03-22 ?s 19:27, Diego Calleja Garc?a escreveu:
> El Mon, 22 Mar 2004 22:57:09 +0100 Adrian Bunk <[email protected]> escribi?:
>
> > OSS will stay in 2.6 (2.6 is a stable kernel series) but it will most
> > likely be removed in 2.7.
>
> Personally, as an user, I'd like to have the OSS drivers which don't have
> a ALSA equivalent for my old hardware. There're several
> sound cards with both ALSA and OSS drivers where ALSA works
> much better 99% of the time. Those could be safely removed
> (even in the 2.6 timeframe, I'd argue) but I'd like to keep the ones
> without an alsa equivalent for my old hardware (specially now that we
> have a -tiny tree ;) however I can understand that if they don't
> have a maintainer they'll get removed...
Also, I think is not good for the kernel to have code that does not
compile and/or compile with several warnings.
So, if someone have time to work on it, is not bad.
--
Luiz Fernando N. Capitulino
<[email protected]>
<http://www.telecentros.sp.gov.br>
On Mon, Mar 22, 2004 at 11:23:29PM +0100, Adrian Bunk wrote:
> On Tue, Mar 23, 2004 at 12:03:27AM +0200, Muli Ben-Yehuda wrote:
> > On Mon, Mar 22, 2004 at 10:59:21PM +0100, Adrian Bunk wrote:
> > > Wouldn't it be better to get the ALSA drivers working in such cases?
> >
> > It would; but until they do, ditching OSS is a regression.
> >...
>
> Clearly.
>
> Ditching OSS at the beginning of 2.7 will give several years to identify
> and fix such regressions.
Seriously, ALSA has some issues at the moment which OSS doesn't have.
The main one is that OSS does not require mmap() access, whereas ALSA
native does at present - and there are architectures where the ALSA
method of mmap() both the ring buffer and the control data does not
work.
These issues aren't simple to resolve - as can be seen from the
recent lkml threads on the subject. I've been seriously considering
submitting the existing OSS drivers I have here for ARM hardware
instead of trying to convert them to ALSA drivers first, and
considering whether I should be writing new OSS drivers in
preference to ALSA drivers.
That's not to say I don't want to see ALSA progress though - which is
why I'm working to try to get these issues resolved.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Monday 22 March 2004 23:54, Luiz Fernando Capitulino wrote:
>
> Also, I think is not good for the kernel to have code that does not
> compile and/or compile with several warnings.
>
> So, if someone have time to work on it, is not bad.
Ok, it's clear OSS is here to stay for a while, and I will start working on
it, if only for nice compile statistics.
These tiny patches might be a good way for me to get used to the beautiful
world of kernel coding I think :)
Best regards,
Jos Hulzink
On Mon, Mar 22, 2004 at 10:22:21PM +0200, Muli Ben-Yehuda wrote:
> In my not so humble opinion, throwing OSS away will be a big mistake,
> as long as there are people willing to maintain it. Keep it there and
> let the users (or distributions) choose what to use. I've seen
Or better: since both of OSS and ALSA are sound systems, let OSS maintainers
start hacking ALSA, so missing parts in ALSA which presents in OSS can be
implemented. Having one sound system would be better, especially in the
official kernel tree. It's another story, if you have multiple one outside
the "official" kernel source. imho.
> multiple bug reports of cards that work with OSS and don't work with
> ALSA (and vice versa), so keeping both seems the proper thing to
> do. Personally, I maintain one OSS driver, and fix bugs in others
> occasionally.
- G?bor (larta'H)
On Tue, 23 Mar 2004, [iso-8859-2] G?bor L?n?rt wrote:
> Or better: since both of OSS and ALSA are sound systems, let OSS maintainers
> start hacking ALSA, so missing parts in ALSA which presents in OSS can be
> implemented. Having one sound system would be better, especially in the
> official kernel tree. It's another story, if you have multiple one outside
> the "official" kernel source. imho.
Maybe we should start ditching OSS drivers of cards that are known to work
"reasonably well" in ALSA. If someone starts screaming "I need OSS for the
ALSA driver contains a bug", that bug might even be located and dealt with
much sooner. The ALSA OSS emulation is good enough for user land
applications to survive I think, so it's just a matter of driver bugs.
This way we end with a list of OSS drivers that are not ported yet or that
never will be ported.
OTOH, I don't know how the big bosses here think about ditching OSS
from a stable kernel tree... Can imagine they think it is not done.
Jos
Diego Calleja Garc?a wrote:
> El Mon, 22 Mar 2004 22:57:09 +0100 Adrian Bunk <[email protected]> escribi?:
>
>
>>OSS will stay in 2.6 (2.6 is a stable kernel series) but it will most
>>likely be removed in 2.7.
>
>
> Personally, as an user, I'd like to have the OSS drivers which don't have
> a ALSA equivalent for my old hardware. There're several
> sound cards with both ALSA and OSS drivers where ALSA works
> much better 99% of the time. Those could be safely removed
> (even in the 2.6 timeframe, I'd argue) but I'd like to keep the ones
> without an alsa equivalent for my old hardware (specially now that we
> have a -tiny tree ;) however I can understand that if they don't
> have a maintainer they'll get removed...
The real issue with removing OSS from a stable kernel is that a kernel
update should not break existing system software (at least compliant
software). As of early 2.6 it seemed that you had to update to the ALSA
mixer and {something I don't remember} if you used the OSS emulation. I
just used OSS and it worked. Based on only two systems, so it may not apply.
Stable and install new sound software don't seem to mix well. I suggest
that the current course is a good one, keep both systems in the stable
kernel.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Tue, 23 Mar 2004, Jos Hulzink wrote:
> Maybe we should start ditching OSS drivers of cards that are known to work
> "reasonably well" in ALSA. If someone starts screaming "I need OSS for the
> ALSA driver contains a bug", that bug might even be located and dealt with
> much sooner. The ALSA OSS emulation is good enough for user land
> applications to survive I think, so it's just a matter of driver bugs.
>
Not true.
> This way we end with a list of OSS drivers that are not ported yet or that
> never will be ported.
>
> OTOH, I don't know how the big bosses here think about ditching OSS
> from a stable kernel tree... Can imagine they think it is not done.
>
Good idea, then maybe someone will fix the bug that makes ALSA unusable
for me. (Or maybe it's a feature? O_o)
I don't describe it here, I've sent a few mails about it, no response, so
I don't wait for any response this time either, so why bother.
Markus
On Tue, 23 Mar 2004, Markus H?stbacka wrote:
> I don't describe it here, I've sent a few mails about it, no response, so
> I don't wait for any response this time either, so why bother.
It would be better to report bugs into our bug-tracking system or ask in
the alsa-user mailing list, if you have installation trouble.
Jaroslav
-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
Jaroslav Kysela <[email protected]> writes:
> On Tue, 23 Mar 2004, Markus H.stbacka wrote:
>
>> I don't describe it here, I've sent a few mails about it, no response, so
>> I don't wait for any response this time either, so why bother.
>
> It would be better to report bugs into our bug-tracking system or ask in
> the alsa-user mailing list, if you have installation trouble.
Did you ever look into bugzilla.kernel.org? There are about 45 bugs
open, might be nice to work on them (or tell people to report the bugs
elsewhere). And yes, if I use vanilla 2.6, I report bugs here or in
bugzilla, not somewhere else.
Jochen
--
#include <~/.signature>: permission denied
On Tue, 23 Mar 2004, Jaroslav Kysela wrote:
> It would be better to report bugs into our bug-tracking system or ask in
> the alsa-user mailing list, if you have installation trouble.
>
Ok, I'll try to report about it later today, and no, it's not installation
problem. It's usage problem, using same two apps that work with OSS.
I discussed this with someone from the team already, don't remember who,
he gave me a few hints that helped me a bit, but not enough.
Thanks.
Markus
On Monday 22 March 2004 22:57, Adrian Bunk wrote:
>
> OSS will stay in 2.6 (2.6 is a stable kernel series) but it will most
> likely be removed in 2.7.
>
> I wouldn't spend time to fix deprecated warnings in OSS code, such
> cleanups are wasted time for code that will most likely be removed in
> 2.7.
Fair, but as I am not yet ready for the big work, this might be a nice
exercise to find my way trough the kernel, to commit patches, etc. So I might
spend a few weekends to it, albeit mostly to get nicer compile statistics :)
Jos
On Tuesday 23 March 2004 18:18, Markus H?stbacka wrote:
> > This way we end with a list of OSS drivers that are not ported yet or
> > that never will be ported.
> >
> > OTOH, I don't know how the big bosses here think about ditching OSS
> > from a stable kernel tree... Can imagine they think it is not done.
>
> Good idea, then maybe someone will fix the bug that makes ALSA unusable
> for me. (Or maybe it's a feature? O_o)
>
> I don't describe it here, I've sent a few mails about it, no response, so
> I don't wait for any response this time either, so why bother.
Please do, or give me a link, so I can collect the issues. Maybe the ALSA core
team doesn't feel like looking at them now, but 2.6 will be here for a long
time, no need to hurry.
Jos