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
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
