All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Gerd Knorr <kraxel@suse.de>
Cc: Jaroslav Kysela <perex@suse.cz>,
	Holger Waechtler <holger@qanu.de>,
	dvb list <linux-dvb@linuxtv.org>,
	alsa-devel@lists.sourceforge.net
Subject: Re: Problem with Avermedia 771
Date: Mon, 18 Oct 2004 16:50:11 +0200	[thread overview]
Message-ID: <s5h3c0cjd24.wl@alsa2.suse.de> (raw)
In-Reply-To: <20041018130114.GA5476@bytesex>

At Mon, 18 Oct 2004 15:01:14 +0200,
Gerd Knorr wrote:
> 
> On Fri, Oct 15, 2004 at 01:03:07PM +0200, Jaroslav Kysela wrote:
> > On Fri, 15 Oct 2004, Gerd Knorr wrote:
> > 
> > I think that the database should be on one central place.
> > I suggest to create a simple function in a standalone module:
> > 
> > #define BTTV_CAP_AUDIOISVIDEO	(1<<0)
> > 
> > unsigned int bttv_caps(struct pci_dev *bttv, char **name);
> 
> Hmm, I was thinking about that as well, I'm not sure it is really a good
> idea through.  We have three different different bt878 cards:
> 
>   (1) The ones where you can get audio data out of PCI function .1
>   (2) The ones which use PCI function .1 for DVB.
>   (3) The ones which use PCI function .1 for other data transfers,
>       the first WinTV PVR card for example (which isn't supported by
>       Linux at the moment, at least not the mpeg stuff).
>   (4) Cards where PCI function .1 is simply unused, i.e. you get either
>       nothing or just noise if you try to record audio from there.
> 
> I think the alsa driver should only try to use cards which fall into
> group (1), not everything but (2).  Problem with that is that it simply
> isn't known for most cards whenever they are in group (1) or (4).
> 
> There are no overlaps between the different card groups, so if every
> driver whitelists the IDs for "known-good" hardware there should be no
> overlaps between the lists (and thus no point in having a central list).
> 
> The whitelist approach would also have the advantage that you can stick
> the IDs into a struct pci_device_id list, so they will show up in
> /lib/modules/$(uname -r)/modules.pcimap, which will make the hardware
> probing easier for the distributions.

I agree with Gerd.  The whitelisting would be the easiest and the most
trustful way.  Even a new PCI entry can be added dynamically on 2.6
kernels through sysfs.

I see the device list in drivers/media/video/bttv-cards.c as mentioned
in Gerd's original post.  Which ones can be as the white list entries
for ALSA?


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

  reply	other threads:[~2004-10-18 14:50 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <416ED29A.7060200@qanu.de>
2004-10-15 10:11 ` Problem with Avermedia 771 Gerd Knorr
2004-10-15 11:03   ` Jaroslav Kysela
2004-10-15 11:58     ` [Alsa-devel] " Holger Waechtler
2004-10-18 13:01     ` Gerd Knorr
2004-10-18 14:50       ` Takashi Iwai [this message]
2004-10-19 16:13         ` Gerd Knorr
2004-10-20 13:06           ` Takashi Iwai
2004-10-20 13:17             ` Takashi Iwai
2004-10-20 15:02               ` Clemens Ladisch
2004-10-20 15:20                 ` Takashi Iwai
2004-10-21  7:22                   ` Clemens Ladisch
2004-10-21  8:59                     ` [Alsa-devel] " Gerd Knorr
2004-10-21 10:05                     ` Takashi Iwai
2004-10-21 10:18                       ` Gerd Knorr
2004-10-21 10:38                         ` Takashi Iwai
2004-10-21 11:43                           ` Gerd Knorr
2004-10-21 12:11                             ` Takashi Iwai
2004-10-21 16:36                               ` Takashi Iwai
2004-10-25  9:36                               ` Clemens Ladisch
2004-10-20 15:27               ` Gerd Knorr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s5h3c0cjd24.wl@alsa2.suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@lists.sourceforge.net \
    --cc=holger@qanu.de \
    --cc=kraxel@suse.de \
    --cc=linux-dvb@linuxtv.org \
    --cc=perex@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.