Jakub Moc wrote:
It not only doesn't work for me,
Bug please! :)
it doesn't work for majority of people
that have responded on this thread. So, something's wrong there I guess? :)
I don't regard this thread as quantifiable measure. Nevertheless, lets
count the number of successes and failures on this thread so far:
jakub: failure
aslandis: failure
cardoe: failure
wltjr: success
nightmorph: success
seemant: success
kloeri: success
uberlord: success
gentoodoo: 1 each way
I'm not asking for more people to add experiences, and I'm not saying
that in-kernel is any more reliable than alsa-driver. I'm just pointing
out how easy it is to misinterpret the information on a thread, and how
you cannot make the above statement.
Maybe this wasn't a serious comment, in which case I apologise for
taking it seriously. Email sucks for communication.
Hmmm, I'm not entirely sure what are you responding to here? What I said
was that "ALSA upstream won't accept bugs about in-kernel drivers" - now
how's that related to whether you (or kernel upstream) support them or not?
Sorry, I can see how my response wasn't clear.
When I say "I support" I mean that I accept the bugs on Gentoo bugzilla
and work them through til resolution. So, you're correct that me
supporting something is not related to any decisions made upstream.
However, many bugs which pass through my "support" follow a common
pattern: I request lots of useful info, am not able to immediately solve
the problem myself, so I instruct the user how to file the bug upstream.
In most cases they do so, and I track the upstream bug. And it's these
cases I'm referring to - I've never seen any upstream bugs rejected due
to them using in-kernel drivers.
Please understand that it wouldn't make much sense for them to reject it
either. There is no difference personnel-wise between the people who
release alsa-driver and the people who send patches into the kernel. If
they were to refuse bugs from people who use kernel drivers then why do
they spend a considerable amount of time regularly synchronising patches?
Additionally - forcing people to upgrade kernel for their sound issues
is not a solution for many of them. Kernel upgrades tend to break lots
of stuff on every minor version bump (and it's not only external modules
that upstream seems to plain hate and ignore mostly). Not exactly what
users would like to see when all they are trying to get is working
sound.
Beyond the usual statements that we aren't forcing anything:
I will not deny that there is some user convenience gained by having the
drivers separated from the kernel. Conversely, such packages are
maintenance nightmares and are susceptible to entire classes of bugs
that they would not be otherwise, and these are often passed onto the
user. Sometimes we are even forced to take drastic measures such as
marking heavily experimental code stable.
The problem I'm solving here, I am solving from a development
perspective. We have duplicated code and duplicated effort, and one of
the copies currently doesn't have any real manpower taking care of it.
> Plus it's lot easier (and faster) to get patches into external
drivers than get them accepted into kernel.
I'm not sure that it is any easier, because the process of patch
submission (file a bug) is the same.
It may be faster, but I don't think thats a big factor. We generally do
a good job keeping on top of the kernel bug list and regularly doing
bugfix kernel releases. Although it may be faster for maintainers to
supply new packages like alsa-driver, it's not *that* much different.
All of the complaints so far seem to be regarding that *handling bugs*
is more convenient for certain use cases when supported ALSA drivers are
provided by an out-of-kernel package. (for clarity: a kernel driver not
working IS a kernel bug, even if you have alternative ways of getting
that hardware working)
There is some truth here. However, more importantly in my eyes, our
development resources are thin and there are currently 0 people standing
behind alsa-driver. Additionally our processes across the entire Gentoo
tree are based on the assumptions that things work, and bugs are treated
as exceptions. Sure, we accept that bugs exist, and there are plenty of
them, and we look to improve our methods of handling them (I have
certainly done this a lot for the kernel) but we don't revolve our
entire system around the assumption that the packages in the stable tree
have bugs.
What I'm trying to say is that even though there are some downsides
here, the overall process is improved given the resources we have.
Even though I'm sure my personal opinion is clear, I don't have a strong
stake in the ALSA herd. The real reason why alsa-driver is not getting
any support behind it right now is that nobody is standing behind it.
If someone wants to step up and take over maintenance of alsa-driver,
and put the required amount of time/effort into maintaining such a large
kernel code base outside of the kernel, then I can accept that. I can
accept that not everyone shares my views, and although I unintentionally
managed to frustrate the previous maintainer a few times, I did accept
that he was willing to stick by ideas just as I was prepared to stick by
mine.
That said, the newly formed ALSA herd seems to share my opinion and
don't seem prepared to properly maintain alsa-driver, so I can see it
slowly becoming lesser supported. If anyone wants to change this,
approach the 3 developers listed in my original mail, share your ideas,
and see if you can help out with ALSA maintenance and apply your ideas.
> Interestingly in this case, the in-kernel driver is a touch newer than
the hda-intel one. It includes support for a few more hardware devices.
Again these are only very small differences though.
As said, it's not about code being newer or older, it's about having two
different branches of the code.
Agreed. As stated, the point I was making is that they are the same
codebase. The above was just an interesting but unrelated observation,
sorry if I threw you off track.
One works for someone, the other works
for someone else. What's exactly the benefit from trying to kill support
for upstream ALSA code and forcing people to use in-kernel drivers
(beyond what you see as 'duplicated' maintenance effort)? Users honestly
don't care much about 'duplicated' effort, they want a working sound on
their boxes.
This is a very valid concern. My view is certainly affected by 2 years
of kernel bug handling and not really seeing the issues that people
describe (where alsa-driver works and in-kernel does not for something
other than user error) with any regularity.
There are reasons that I am still working on kernel bugs after 2 years
though. Firstly, the kernel code base is of personal interest to me, and
I enjoy being part of the upstream community and finding more ways to
contribute. Secondly, I enjoy a challenge and I enjoy the problem
solving aspect of handling bugs. Kernel bugs are great brain food and I
like seeing them through.
So, I will put forward a claim, which you are free to regard as
completely ridiculous:
Everyone who is claiming that alsa-driver works and in-kernel does not:
a) has not actually tried both
or
b) has tried both but has only attempted to reproduce the issue on 1,
or is otherwise mistaken about their issue which does infact exist
in both "codebases" (I quote that word as I interpret them as the
same)
or
c) is attempting to use the wrong module, or is mixing alsa-driver and
in-kernel modules, or is otherwise making a user-level error
or
d) is referring to a large difference in driver versions (e.g. 2.6.3
does not work but alsa-driver does! or maybe not quite that extreme!)
or
e) is not comparing the same environments (my card works fine in
alsa-driver on System A, but does not work with in-kernel drivers on
System B, therefore alsa-driver works and in-kernel does not!)
or
f) is LYING
I'm fully 100% serious on the above. I challenge you to PROVE ME WRONG.
I secretly hope you do, since that means I'll get a couple of
interesting bugs to handle and I may even be able to solve them myself.
Thanks,
Daniel
--
gentoo-dev@gentoo.org mailing list
