On Tuesday 06 April 2010 00:58:54 Hans Verkuil wrote:
On Tuesday 06 April 2010 00:46:11 Laurent Pinchart wrote:
On Sunday 04 April 2010 05:14:17 David Ellingsworth wrote:
After looking at the proposed solution, I personally find the
suggestion for a serialization flag to be quite
Hans Verkuil wrote:
On Tuesday 06 April 2010 00:58:54 Hans Verkuil wrote:
On Tuesday 06 April 2010 00:46:11 Laurent Pinchart wrote:
On Sunday 04 April 2010 05:14:17 David Ellingsworth wrote:
After looking at the proposed solution, I personally find the
suggestion for a serialization flag to
Hans Verkuil wrote:
On Tuesday 06 April 2010 00:58:54 Hans Verkuil wrote:
On Tuesday 06 April 2010 00:46:11 Laurent Pinchart wrote:
On Sunday 04 April 2010 05:14:17 David Ellingsworth wrote:
After looking at the proposed solution, I personally find the
suggestion for a serialization flag to
Hans Verkuil wrote:
Hans Verkuil wrote:
- performance is important only for the ioctl's that directly handles
the streaming (dbuf/dqbuf friends);
What performance? These calls just block waiting for a frame. How the hell
am I suppose to test performance anyway on something like that?
On Sunday 04 April 2010 05:14:17 David Ellingsworth wrote:
After looking at the proposed solution, I personally find the
suggestion for a serialization flag to be quite ridiculous. As others
have mentioned, the mere presence of the flag means that driver
writers will gloss over any concurrency
On Tuesday 06 April 2010 00:46:11 Laurent Pinchart wrote:
On Sunday 04 April 2010 05:14:17 David Ellingsworth wrote:
After looking at the proposed solution, I personally find the
suggestion for a serialization flag to be quite ridiculous. As others
have mentioned, the mere presence of the
- Original Nachricht
Von: Andy Walls awa...@md.metrocast.net
An: Mauro Carvalho Chehab mche...@redhat.com
Datum: 03.04.2010 02:47
Betreff: Re: [RFC] Serialization flag example
On Fri, 2010-04-02 at 18:15 -0300, Mauro Carvalho Chehab wrote:
Devin Heitmueller wrote
On Thursday 01 April 2010 23:32:33 Mauro Carvalho Chehab wrote:
Hans Verkuil wrote:
Maybe a better alternative would be to pass to the V4L2 core, optionally,
some lock,
used internally on the driver. This approach will still be pedantic, as
all ioctls will
keep being serialized, but
Hans Verkuil wrote:
On Thursday 01 April 2010 23:32:33 Mauro Carvalho Chehab wrote:
Hans Verkuil wrote:
Maybe a better alternative would be to pass to the V4L2 core, optionally,
some lock,
used internally on the driver. This approach will still be pedantic, as
all ioctls will
keep being
On Thu, Apr 1, 2010 at 10:24 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
You'll have issues also with -alsa and -dvb parts that are present on the
drivers.
Also, drivers like cx88 have another PCI device for mpeg-encoded streams. It
behaves
like two separate drivers (each with its
On Fri, Apr 2, 2010 at 1:43 PM, Manu Abraham abraham.m...@gmail.com wrote:
On Thu, Apr 1, 2010 at 10:24 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
You'll have issues also with -alsa and -dvb parts that are present on the
drivers.
Also, drivers like cx88 have another PCI device for
Hi Devin,
Hello Manu,
The argument I am trying to make is that there are numerous cases
where you should not be able to use both a particular DVB and V4L
device at the same time. The implementation of such locking should be
handled by the v4l-dvb core, but the definition of the
On Fri, Apr 2, 2010 at 2:24 PM, Manu Abraham abraham.m...@gmail.com wrote:
Hi Devin,
Hello Manu,
The argument I am trying to make is that there are numerous cases
where you should not be able to use both a particular DVB and V4L
device at the same time. The implementation of such locking
Devin Heitmueller wrote:
On Fri, Apr 2, 2010 at 1:43 PM, Manu Abraham abraham.m...@gmail.com wrote:
IMO, A framework shouldn't lock.
Current DVB framework is locked with BKL. I agree that an unconditional
lock like this is very bad. We need to get rid of it as soon as possible.
Hello Manu,
On Fri, 2010-04-02 at 10:57 +0200, Hans Verkuil wrote:
If needed one could allow drivers to override this function. But again, start
simple and only make it more complex if we really need to. Overengineering is
one of the worst mistakes one can make. I have seen too many projects fail
because
On Fri, 2010-04-02 at 18:15 -0300, Mauro Carvalho Chehab wrote:
Devin Heitmueller wrote:
In the case of a V4L x DVB type of lock, this is not to protect some memory,
but,
instead, to limit the usage of a hardware that is not capable of
simultaneously
provide V4L and DVB streams. This is a
Hans,
Hans Verkuil wrote:
I made a quick implementation which is available here:
http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-serialize
It's pretty easy to use and it also gives you a very simple way to block
access to the video device nodes until all have been allocated by simply
taking
On Thursday 01 April 2010 20:24:12 Mauro Carvalho Chehab wrote:
Hans,
Hans Verkuil wrote:
I made a quick implementation which is available here:
http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-serialize
It's pretty easy to use and it also gives you a very simple way to block
access
Hans Verkuil wrote:
Maybe a better alternative would be to pass to the V4L2 core, optionally,
some lock,
used internally on the driver. This approach will still be pedantic, as all
ioctls will
keep being serialized, but at least the driver will need to explicitly
handle the lock,
and the
19 matches
Mail list logo
