linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Zeuthen <david@fubar.dk>
To: linux-hotplug@vger.kernel.org
Subject: Re: hal, udev and video4linux probers
Date: Fri, 08 May 2009 20:25:54 +0000	[thread overview]
Message-ID: <1241814354.13206.207.camel@localhost.localdomain> (raw)
In-Reply-To: <8ceb98f20905081004l52ac4b95h1c23d9e8ed209e37@mail.gmail.com>

Hey,

On Fri, 2009-05-08 at 19:04 +0200, Filippo Argiolas wrote:
> Being honest I'm not so sure I will use libudev, I'm currently looking
> for a way to do the device probing directly from gstreamer, but it
> would be nice to preserve that v4l probing stuff somewhere with HAL
> going away (furthermore, I doubt we're the only users of that prober).

Ideally GStreamer, which is the codebase I believe that you are using to
actually access the device, would provide a mechanism for enumerating
devices and give you events when devices (specifically sinks and
sources) are coming and going. That way, if you care about more than
Linux, the Solaris, FreeBSD and Win32 guys can add support to GStreamer
without you having to change your application.

This is much like GIO in GLib works; we have abstract classes and
interfaces with concrete implementations that depends on what platform
we're running on or are compiled for. E.g. GIO's GVolumeMonitor class
will list all interesting storage devices (and notify you on insertion
and removal) - on Linux it is (indirectly) using libudev, on Solaris
something else, on Win32 it's using the native Win32 API and on OS X
some other native API.

I don't know much about GStreamer, but I suspect it could provide
something like a GstSinkNSourcesMonitor class that works in a similar
way as GVolumeMonitor. On Linux, it would probably use the ID_V4L_*
properties and libudev cf. the mail Kay just sent. 

It seems like the logical thing to do, I think - it would make writing
applications that much easier while still allowing us to change how udev
and Linux in general works. Feel free to include me (and I suppose, Kay
as well) in any discussion with the GStreamer guys about how libudev can
help in doing this.

    David



  parent reply	other threads:[~2009-05-08 20:25 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-08 17:04 hal, udev and video4linux probers Filippo Argiolas
2009-05-08 20:06 ` Kay Sievers
2009-05-08 20:25 ` David Zeuthen [this message]
2009-05-08 20:38 ` Filippo Argiolas
2009-05-09 11:49 ` Kay Sievers
2009-05-09 14:24 ` Filippo Argiolas
2009-05-09 14:54 ` Filippo Argiolas
2009-05-09 16:19 ` Kay Sievers
2009-05-10 13:58 ` Kay Sievers
2009-05-10 18:50 ` Filippo Argiolas
2009-05-10 23:59 ` Kay Sievers

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=1241814354.13206.207.camel@localhost.localdomain \
    --to=david@fubar.dk \
    --cc=linux-hotplug@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).