| 1 |
Hi Jakub, |
| 2 |
|
| 3 |
Thanks for your input. Please remember that alsa-driver isn't going away |
| 4 |
any time soon. |
| 5 |
|
| 6 |
Jakub Moc wrote: |
| 7 |
> - The in-kernel drivers seriously are not an equivalent alternative, let |
| 8 |
> alone the preferred one, for stuff like hda-intel or any similar drivers |
| 9 |
> that are under permanent heavy development, at least for now. |
| 10 |
|
| 11 |
If hda-intel (or any other driver) from the kernel sources does not work |
| 12 |
on your system then you should file a bug. Yes, there are drivers under |
| 13 |
heavily development, this also applies to many other kernel subsystems |
| 14 |
too. We live with it. It's not as bad as it sounds. |
| 15 |
|
| 16 |
If you have a system which does not work with the in-kernel drivers, |
| 17 |
please file a bug. Provided you cooperate, we will get it fixed in the |
| 18 |
kernel. |
| 19 |
|
| 20 |
> - This is not a duplicated maintenance effort, it's simply needed to |
| 21 |
> have external alsa-drivers ebuilds, and it's needed to have them |
| 22 |
> supported as ALSA upstream won't accept bugs about in-kernel drivers. |
| 23 |
|
| 24 |
That's not true. I have supported in-kernel ALSA drivers for a long time |
| 25 |
and have never seen this be the case. |
| 26 |
|
| 27 |
> - The two are basically different branches, and it's *not* about whether |
| 28 |
> the code is newer or older in one or the other at all. |
| 29 |
|
| 30 |
That depends on your definition of branch. From my definition of the |
| 31 |
word, I disagree. |
| 32 |
|
| 33 |
Using a more generic term: they are the same CODEBASE. |
| 34 |
|
| 35 |
Changes from the alsa-driver upstream repository *are* |
| 36 |
synced into the kernel very regularly - the large majority of the source |
| 37 |
base is identical. |
| 38 |
|
| 39 |
Taking the first 10 .c files under sound/pci, here are the diffs of the |
| 40 |
latest alsa development release vs the latest kernel development release: |
| 41 |
|
| 42 |
ad1889.c: no differences |
| 43 |
als300.c: no differences |
| 44 |
als4000.c: no differences |
| 45 |
atiixp.c: no differences |
| 46 |
atiixp_modem.c: no differences |
| 47 |
azt3328.c: no differences |
| 48 |
bt87x.c: 2 insertions(+), 1 deletion(-) |
| 49 |
cmipci.c: no differences |
| 50 |
cs4281.c: no differences |
| 51 |
ens1370.c: 2 insertions(+), 6 deletions(-) |
| 52 |
|
| 53 |
The bt87x differences are in both directions: the kernel adds support |
| 54 |
for one hardware device over alsa-driver, alsa-driver adds support for |
| 55 |
one device over the kernel. |
| 56 |
|
| 57 |
The ens1370 difference is just a simple cleanup, no functional differences. |
| 58 |
|
| 59 |
Now some drivers I know to be more popular: |
| 60 |
|
| 61 |
via82cxx.c: no differences |
| 62 |
intel8x0.c: 3 insertions(+), 7 deletions(-) |
| 63 |
(just a tweak to the way the device is suspended) |
| 64 |
emu10k1/*: 1 insertion(+), 3 deletions(-) |
| 65 |
(just a cleanup, no functional changes) |
| 66 |
|
| 67 |
The heavily developed monster one: |
| 68 |
|
| 69 |
hda/*: 15 insertions(+), 88 deletions(-) |
| 70 |
|
| 71 |
Interestingly in this case, the in-kernel driver is a touch newer than |
| 72 |
the hda-intel one. It includes support for a few more hardware devices. |
| 73 |
Again these are only very small differences though. |
| 74 |
|
| 75 |
Both of these sources ARE the same codebase. |
| 76 |
|
| 77 |
Daniel |
| 78 |
-- |
| 79 |
gentoo-dev@g.o mailing list |
Archives