EMU10K1X and MIDI

EMU10K1X and MIDI

[Francisco Moraes]

I added MIDI support for the EMU10K1X driver by slightly adapting the 
code in th emumpu401.c file. Given that I barely changed anything in 
that file, I was thinking about moving all the code into a .h file which 
can be parametrized with some #define's and #ifdef's. Then, both the 
current file, the emu10k1x.c and audigyls.c drivers can reuse the same 
code without having to duplicate it.

Is that ok with everyone?

Francisco


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: EMU10K1X and MIDI

[Clemens Ladisch]

Francisco Moraes wrote:
> I added MIDI support for the EMU10K1X driver by slightly adapting the
> code in th emumpu401.c file. Given that I barely changed anything in
> that file, I was thinking about moving all the code into a .h file which
> can be parametrized with some #define's and #ifdef's.

Like opti92x-ad1848/opti92x-cs4231/opti93x, or ens1370/ens1371.
<nitpick>
But these drivers use a .c extension for this file.
</nitpick>

> Then, both the current file, the emu10k1x.c and audigyls.c drivers
> can reuse the same code without having to duplicate it.

Putting the common code into a module and parameterizing it at runtime
would be more, uh, modular, but I guess this probably wouldn't be
worth the effort because it's unlikely that somebody uses several of
these cards at the same time.


Regards,
Clemens




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: EMU10K1X and MIDI

[Clemens Ladisch]

Francisco Moraes wrote:

> Clemens Ladisch wrote:
>
> >Like opti92x-ad1848/opti92x-cs4231/opti93x, or ens1370/ens1371.
> ><nitpick>
> >But these drivers use a .c extension for this file.
> ></nitpick>
> >
> I usually don't think .c is a good extension if the file is not
> compilable by itself.

In these cases, one of the hardware models is the default if no other
has been selected with a #define.  So we would have three .c files,
each compilable by itself.

The reasons for this are purely historical; the modifications to the
'master' file were not made before the other models became known.
(But it's the same situtation with emumpu401.c :-).


Regards,
Clemens


> If someone else has an opinion, please share it before I spend
> time making the patch.




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com