Re: USB mini-summit at LinuxCon Vancouver
From: Hans de Goede
Date: Tue Aug 09 2011 - 03:51:57 EST
Hi,
On 08/08/2011 07:58 PM, Sarah Sharp wrote:
On Fri, Aug 05, 2011 at 09:45:56AM +0200, Hans de Goede wrote:
Hi,
On 08/05/2011 12:56 AM, Greg KH wrote:
On Thu, Aug 04, 2011 at 07:21:47PM -0300, Mauro Carvalho Chehab wrote:
I think it is important to separate oranges from apples here, there are
at least 3 different problem classes which all seem to have gotten thrown
onto a pile here:
1) The reason Mauro suggested having some discussion on this at the
USB summit is because of a discussion about dual mode cameras on the
linux media list.
...
3) Re-direction of usb devices to virtual machines. This works by using
the userspace usbfs interface from qemu / vmware / virtualbox / whatever.
The basics of this work fine, but it lacks proper locking / safeguards
for when a vm takes over a usb device from the in kernel driver.
Hi Hans and Mauro,
We have do room in the schedule for the USB mini-summit for this
discussion, since the schedule is still pretty flexible. The
preliminary schedule is up here:
http://userweb.kernel.org/~sarah/linuxcon-usb-minisummit.html
I think it's best to discuss the VM redirection in the afternoon when
some of the KVM folks join us after Hans' talk on USB redirection over
the network.
That seems best to me too. I'm available at both proposed time slots,
and I would like to join both discussions.
It sounds like we need a separate topic for the dual mode cameras and TV
tuners. Mauro, do you want to lead that discussion in the early morning
(in a 9:30 to 10:30 slot) or in the late afternoon (in a 15:30 to 16:30
slot)? I want to be sure we have all the video/media developers who are
interested in this topic present, and I don't know if they will be going
to the KVM forum.
I would really like to see the dual mode camera and TV tuner discussion
separated. They are 2 different issues AFAIK.
1) Dual mode cameras:
In the case of the dual mode camera we have 1 single device (both at
the hardware level and at the logical block level), which can do 2 things,
but not at the same time. It can stream live video data from a sensor,
or it can retrieve earlier taken pictures from some picture memory.
Unfortunately even though these 2 functions live in a single logical block,
historically we've developed 2 drivers for them. This leads to fighting
over device ownership (surprise surprise), and to me the solution is
very clear, 1 logical block == 1 driver.
2) Tv tuners:
Here we have a bunch of logical blocks, each with their own driver
(and not 2 drivers for one block), which together form not 1 but 2
video pipelines, typically one pipeline for analog TV, and one
for DVB. The problem here is some blocks are shared between the
2 pipelines.
The solution here, at least to me, is clear too, we need some way
of claiming/locking the pipeline blocks. If pipe1 starts streaming
video data it locks all the blocks it uses. If some app then tries
to use pipe2 (and thus for example tune the tuner to a different
frequency), it will fail with -EBUSY when pipe2 tries to take the
tuner lock and gets told it is in use.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/