GNOME Bugzilla – Bug 759780
v4l2: deviceprovider: Add the device and sysfs paths to the GstDevice properties
Last modified: 2015-12-29 11:36:50 UTC
Created attachment 317790 [details] [review] v4l2: Add the device and sysfs paths to the GstDevice properties In the same spirit as the pulseaudio device provider, add a way to map the GstDevice to the device path. This allows us to match/filter available devices if we already know the device file paths.
Comment on attachment 317790 [details] [review] v4l2: Add the device and sysfs paths to the GstDevice properties Looks useful to me. The only thing I'm not entirely sure about is the "udev-probed", G_TYPE_BOOLEAN, TRUE, I don't entirely see the point of that. Doesn't hurt either of course :) The pulseaudio one has "module-udev-detect.discovered = 1" which looks like it just exposed some PA properties without applying any filtering.
Didn't Wim exposed something equivalent recently ?
Abridged update from IRC: <ndufresne> wtay_: nirbheek proposed a patch to add the sysfs path of each device in the v4l2 provider, I can't remember, but I was surprised since I believe you needed that on your side too, https://bugzilla.gnome.org/show_bug.cgi?id=759780 <wtay_> nirbheek, ndufresne http://cgit.freedesktop.org/~wtay/gst-plugins-good/commit/?h=v4l2-props&id=d46b253d2112cba43fc11c9e40b637293e306883 <ocrete> wtay_: how about the non-udev codepath ?
Created attachment 317880 [details] [review] v4l2deviceprovider: add properties to the device The attached patch merges Wim's patch with mine. It's fully compatible with Wim's work. Since most of the code is the same, I retained Wim's authorship.
Comment on attachment 317880 [details] [review] v4l2deviceprovider: add properties to the device >+ str = g_strdup_printf ("%u", v4l2obj->vcap.version); >+ gst_structure_set (props, "v4l2.device.version", G_TYPE_STRING, str, NULL); >+ g_free (str); >+ str = g_strdup_printf ("0x%08x", v4l2obj->vcap.capabilities); >+ gst_structure_set (props, "v4l2.device.capabilities", G_TYPE_STRING, str, >+ NULL); >+ g_free (str); >+ str = g_strdup_printf ("0x%08x", v4l2obj->vcap.device_caps); >+ gst_structure_set (props, "v4l2.device.device_caps", G_TYPE_STRING, str, >+ NULL); >+ g_free (str); Hrm, wonder whether these should really be exposed as a hex-string, rather than G_TYPE_UINT, or even a registered flags/enum type?
Some integer type at least, strings seem wrong here. Registered flags would be a problem if additional ones can be defined by v4l modules.
They are defines and often new flag are added. I'm not sure wrapping this is really worth the extra effort. I'd use an integer type there. More precisely, G_TYPE_UINT32 (unsigned, but could be just an int as long as it's at least 32bit). (Note, if you are going to use it, that we have a bug in GStreamer, capabilities is the drivers flags, for driver with multiple device, this is the union, I'll try and fix that next week, it breaks with vivid mostly, where the device provider give away radio, vbi and output devices as being webcams.)
commit 5fe9a59842b21ddf191b6815d99c214c3cc06ddb Author: Wim Taymans <wtaymans@redhat.com> Date: Mon Jul 27 15:53:26 2015 +0200 v4l2deviceprovider: add properties to the device Add properties to the device with exactly the same keys and sematics as what pulseaudio uses as property keys. Also handle the case when a device is probed manually and not through gudev. https://bugzilla.gnome.org//show_bug.cgi?id=759780 commit f2ecf85103444563aed640402f08975de6e7f1f7 Author: Tim-Philipp Müller <tim@centricular.com> Date: Tue Dec 29 11:29:31 2015 +0000 tools: gst-device-monitor: print uint properties in both decimal and hex Some values are easier to read and make sense of in hex. https://bugzilla.gnome.org//show_bug.cgi?id=759780