Re: [ANNOUNCE] git tree repositories

2010-01-19 Thread Laurent Pinchart
Hi Mauro,

I would like to personally thank you for spending time on git support at 
linuxtv.org. Git support was a long-awaited feature for many developers (and I 
certainly was one of them).

All the work done behind the scene on linuxtv.org isn't seen by end-users and 
can thus be less rewarding than working on the code. However, it's of critical 
importance to make the development process as smooth as possible. For that 
reason, thank you again.

Thanks to Douglas too for agreeing to manage backports. Getting the latest 
version of our drivers working on older kernels make the test base much 
larger, leading to better quality code (or at least to more bug reports :-)).

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [ANNOUNCE] git tree repositories

2010-01-19 Thread Patrick Boettcher
On Tuesday 19 January 2010 08:53:10 Hans Verkuil wrote:
 On Tuesday 19 January 2010 06:34:18 Mauro Carvalho Chehab wrote:
 
  He already started doing that, fixing some incompatibility troubles
  between some drivers and older kernels.
 
 Mauro, I just wanted to thank you for doing all the hard work in moving to
  git!
 
 And a big 'thank you' to Douglas as well for taking over hg maintenance!

A big thank you also from me. 

This is really outstanding work you're doing there and it's highly 
appreciated.


 I do have one proposal: parts of our hg tree are independent of git:
  v4l2-apps, possibly some firmware build code (not 100% sure of that),
  v4l_experimental, perhaps some documentation stuff. My proposal is that we
  make a separate hg or git tree for those. It will make it easier to
  package by distros and it makes it easier to maintain v4l2-apps et al as
  well. It might even simplify Douglas's work by moving non-essential code
  out of the compat hg tree.
 
  In terms of the out-of-tree building system evolution (e. g. the building
  system concept behind the -hg tree), If people think it is worthy enough,
  maybe later this could also be converted also to -git, but preserving the
  building system and the backport patches. Another alternative would be to
  split the building systems and the backport patches, and apply them into
  the drivers/media files.

I'm strongly in need of a build-only-v4l-dvb build system. Because I'm most of 
the time using distro-kernels in my productive environments and I'm replacing 
v4l/dvb drivers with the one from v4l-dvb.

One step into the direction of a solution might be:
Why not including the v4l-dvb/v4l/Makefile and the related files into that 
separate repository Hans is describing here and then telling 'make' to make 
links to ../../v4l-dvb/ instead of ../linux as of today.

But I don't know how to solve the ifdef KERNEL_VERSION for having backward 
compatibility in the source files. Maybe with a patch for each kernel version?

BTW: I just made a clone of the git-tree - 365MB *ouff*. Maybe it's worth to 
mention right now, that one big difference to HG in the way we have used it, is 
that one developer now can do all the work only with one clone of v4l-dvb and 
using branches for each development.

best regards,
-- 
Patrick Boettcher - KernelLabs
http://www.kernellabs.com/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC v2 5/7] V4L: Events: Limit event queue length

2010-01-19 Thread Laurent Pinchart
Hi Hans,

On Monday 18 January 2010 13:58:09 Hans Verkuil wrote:
 On Tue, 22 Dec 2009, Sakari Ailus wrote:
  Limit event queue length to V4L2_MAX_EVENTS. If the queue is full any
  further events will be dropped.
 
  This patch also updates the count field properly, setting it to exactly
  to number of further available events.
 
  Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
  ---
  drivers/media/video/v4l2-event.c |   10 +-
  include/media/v4l2-event.h   |5 +
  2 files changed, 14 insertions(+), 1 deletions(-)

[snip]

  diff --git a/include/media/v4l2-event.h b/include/media/v4l2-event.h
  index b11de92..69305c6 100644
  --- a/include/media/v4l2-event.h
  +++ b/include/media/v4l2-event.h
  @@ -28,6 +28,10 @@
  #include linux/types.h
  #include linux/videodev2.h
 
  +#include asm/atomic.h
  +
  +#define V4L2_MAX_EVENTS1024 /* Ought to be enough for 
  everyone. */
 
 I think this should be programmable by the driver. Most drivers do not use
 events at all, so by default it should be 0 or perhaps it can check whether
 the ioctl callback structure contains the event ioctls and set it to 0 or
 some initial default value.
 
 And you want this to be controlled on a per-filehandle basis even. If I
  look at ivtv, then most of the device nodes will not have events, only a
  few will support events. And for one device node type I know that there
  will only be a single event when stopping the streaming, while another
  device node type will get an event each frame.

Don't you mean per video node instead of per file handle ? In that case we 
could add a new field to video_device structure that must be initialized by 
drivers before registering the device.

 So being able to adjust the event queue dynamically will give more control
 and prevent unnecessary waste of memory resources.

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC v2 0/7] V4L2 file handles and event interface

2010-01-19 Thread Laurent Pinchart
Hi Hans,

On Monday 18 January 2010 14:07:33 Hans Verkuil wrote:
 On Tue, 22 Dec 2009, Sakari Ailus wrote:
  Hi,
 
  Here's the second version of the V4L2 file handle and event interface
  patchset. Still RFC since I'd like to get more feedback on it.
 
  The first patch adds the V4L2 file handle support and the rest are for
  V4L2 events.
 
  The patchset works with the OMAP 3 ISP driver. Patches for OMAP 3 ISP are
  not part of this patchset but are available in Gitorious (branch is
  called events):
 
  git://gitorious.org/omap3camera/mainline.git event
 
  The major change since the last one v4l2_fh structure is now part of
  driver's own file handle. It's used as file-private_data as well. I did
  this based on Hans Verkuil's suggestion. Sequence numbers and event queue
  length limitation is there as well. There are countless of smaller
  changes, too.
 
  A few notes on the patches:
 
  - I don't like the locking too much. Perhaps the file handle specific
  lock (events-lock) could be dropped in favour of the lock for
  v4l2_file_handle in video_device?
 
  - Poll. The V4L2 specifiction says:
 
  When the application did not call VIDIOC_QBUF or
  VIDIOC_STREAMON yet the poll() function succeeds, but sets the
  POLLERR flag in the revents field.
 
   The current events for OMAP 3 ISP are related to streaming but not all
  might be in future. For example there might be some radio or DVB related
  events.
 
 I know for sure that we will have to be able to handle events when not
 streaming. E.g. events that tell when a HDMI connector was plugged in
 or when the EDID was read will need to arrive whether streaming is on
 or off.

I agree with you. The V4L2 specification will then need to be changed, 
otherwise we won't be able to poll() for events. poll() wouldn't return 
immediately anymore if no buffer is queued or if the device isn't streaming. 
That might break existing applications (although we could argue that some of 
those applications are somehow broken already if they rely on such a weird 
feature).

If we want to avoid disturbing existing applications we could still return 
POLLERR immediately when not streaming if no event has been subscribed to.

  - Sequence numbers are local to file handles.
 
 That is how it should be.
 
  - Subscribing V4L2_EVENT_ALL causes any other events to be unsubscribed.
 
  - If V4L2_EVENT_ALL has been subscribed, unsubscribing any one of the
  events leads to V4L2_EVENT_ALL to be unsubscribed. This problem would be
  difficult to work around since this would require the event system to be
  aware of the driver private events as well.
 
 Good point. Perhaps attempting to unsubscribe a single event when EVENT_ALL
 has been subscribed should result in an error? I.e., you can only
 unsubscribe ALL when you subscribed to ALL in the first place.

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


CI Plus support for TT S2 3200

2010-01-19 Thread Peter
Does anyone know if the current Technotrend DVB-S2 S2-3200 with the CI 
daughter board supports the latest generation of CI+ CAMS and specified 
in http://www.ci-plus.com/ in non-legacy mode? I guess what I am asking 
is, can the hardware support full CI+, what would be involved software 
wise and has anyone looked at this?


Pete
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: DM1105: could not attach frontend 195d:1105

2010-01-19 Thread paul10
 Well, as I understood, GPIO15 drives reset for demod.
 dm1105 driver needs little patching.
 
 

Igor,

Not to hassle you, I'm sure you're very busy.  Is this something I could
undertake myself?  If so, which driver would you recommend I copy from - I
saw on the list that some drivers do their own GPIO management, and others
use a generic GPIO layer.  I presume we'd need to use the generic layer?

Also, from your explanation it sounds like we need to set GPIO 15 to true
before we attempt to attach.  Is that correct?  From my reading there are
two GPIO registers (8 bits each), so we'd be bit masking bit 7 in the
second GPIO register to 1, then sending that GPIO to the card?

Thanks for any tips,

Paul


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC v2 5/7] V4L: Events: Limit event queue length

2010-01-19 Thread Hans Verkuil

 Hi Hans,

 On Monday 18 January 2010 13:58:09 Hans Verkuil wrote:
 On Tue, 22 Dec 2009, Sakari Ailus wrote:
  Limit event queue length to V4L2_MAX_EVENTS. If the queue is full any
  further events will be dropped.
 
  This patch also updates the count field properly, setting it to
 exactly
  to number of further available events.
 
  Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
  ---
  drivers/media/video/v4l2-event.c |   10 +-
  include/media/v4l2-event.h   |5 +
  2 files changed, 14 insertions(+), 1 deletions(-)

 [snip]

  diff --git a/include/media/v4l2-event.h b/include/media/v4l2-event.h
  index b11de92..69305c6 100644
  --- a/include/media/v4l2-event.h
  +++ b/include/media/v4l2-event.h
  @@ -28,6 +28,10 @@
  #include linux/types.h
  #include linux/videodev2.h
 
  +#include asm/atomic.h
  +
  +#define V4L2_MAX_EVENTS   1024 /* Ought to be enough for 
  everyone. */

 I think this should be programmable by the driver. Most drivers do not
 use
 events at all, so by default it should be 0 or perhaps it can check
 whether
 the ioctl callback structure contains the event ioctls and set it to 0
 or
 some initial default value.

 And you want this to be controlled on a per-filehandle basis even. If I
  look at ivtv, then most of the device nodes will not have events, only
 a
  few will support events. And for one device node type I know that there
  will only be a single event when stopping the streaming, while another
  device node type will get an event each frame.

 Don't you mean per video node instead of per file handle ? In that case we
 could add a new field to video_device structure that must be initialized
 by
 drivers before registering the device.

Yes, that's what I meant (although you state it much more clearly :-) ).

Regards,

  Hans

 So being able to adjust the event queue dynamically will give more
 control
 and prevent unnecessary waste of memory resources.

 --
 Regards,

 Laurent Pinchart



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC v2 0/7] V4L2 file handles and event interface

2010-01-19 Thread Hans Verkuil

 Hi Hans,

 On Monday 18 January 2010 14:07:33 Hans Verkuil wrote:
 On Tue, 22 Dec 2009, Sakari Ailus wrote:
  Hi,
 
  Here's the second version of the V4L2 file handle and event interface
  patchset. Still RFC since I'd like to get more feedback on it.
 
  The first patch adds the V4L2 file handle support and the rest are for
  V4L2 events.
 
  The patchset works with the OMAP 3 ISP driver. Patches for OMAP 3 ISP
 are
  not part of this patchset but are available in Gitorious (branch is
  called events):
 
 git://gitorious.org/omap3camera/mainline.git event
 
  The major change since the last one v4l2_fh structure is now part of
  driver's own file handle. It's used as file-private_data as well. I
 did
  this based on Hans Verkuil's suggestion. Sequence numbers and event
 queue
  length limitation is there as well. There are countless of smaller
  changes, too.
 
  A few notes on the patches:
 
  - I don't like the locking too much. Perhaps the file handle specific
  lock (events-lock) could be dropped in favour of the lock for
  v4l2_file_handle in video_device?
 
  - Poll. The V4L2 specifiction says:
 
 When the application did not call VIDIOC_QBUF or
 VIDIOC_STREAMON yet the poll() function succeeds, but sets the
 POLLERR flag in the revents field.
 
   The current events for OMAP 3 ISP are related to streaming but not
 all
  might be in future. For example there might be some radio or DVB
 related
  events.

 I know for sure that we will have to be able to handle events when not
 streaming. E.g. events that tell when a HDMI connector was plugged in
 or when the EDID was read will need to arrive whether streaming is on
 or off.

 I agree with you. The V4L2 specification will then need to be changed,
 otherwise we won't be able to poll() for events. poll() wouldn't return
 immediately anymore if no buffer is queued or if the device isn't
 streaming.
 That might break existing applications (although we could argue that some
 of
 those applications are somehow broken already if they rely on such a weird
 feature).

 If we want to avoid disturbing existing applications we could still return
 POLLERR immediately when not streaming if no event has been subscribed to.

I think this is a very reasonable approach.

Regards,

 Hans


  - Sequence numbers are local to file handles.

 That is how it should be.

  - Subscribing V4L2_EVENT_ALL causes any other events to be
 unsubscribed.
 
  - If V4L2_EVENT_ALL has been subscribed, unsubscribing any one of the
  events leads to V4L2_EVENT_ALL to be unsubscribed. This problem would
 be
  difficult to work around since this would require the event system to
 be
  aware of the driver private events as well.

 Good point. Perhaps attempting to unsubscribe a single event when
 EVENT_ALL
 has been subscribed should result in an error? I.e., you can only
 unsubscribe ALL when you subscribed to ALL in the first place.

 --
 Regards,

 Laurent Pinchart



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


newbie using TechniSat SkyStar HD2

2010-01-19 Thread Nicolae Mihalache
Hello,

I just started with satellite TV and purchased a TechniSat SkyStar HD2
(not a brilliant start, I agree). I installed the mantis driver from
http://linuxtv.org/hg/v4l-dvb as explained on the wiki. It somehow
seems to work, dmesg shows:

[ 3116.783103] Mantis :05:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16
[ 3116.784165] DVB: registering new adapter (Mantis DVB adapter)
[ 3117.652286] stb0899_attach: Attaching STB0899
[ 3117.652298] stb6100_attach: Attaching STB6100
[ 3117.652515] LNBx2x attached on addr=8
[ 3117.652522] DVB: registering adapter 0 frontend 0 (STB0899
Multistandard)...

However, when I run femon in order to get the signal level (so I can
tune the antenna), I get:

Problem retrieving frontend information: Operation not supported
status S | signal 7f98 | snr  | ber d3b53000 | unc  |

If I use the -H flag it shows signal level 49% which is not right
because the card is not even connected to the antenna.


Also dvbscan gives an error that it cannot tune to the required
frequency (or something like that). As I said, the card is not yet
connected to the antenna but I tried connecting it to a standalone LNB
(which I imagine is the same as connecting to a not tuned antenna).


Any hints?


Thanks,
nicolae
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: em28xx driver - xc3028 tuner - readreg error

2010-01-19 Thread Valerio Bontempi
2010/1/18 Devin Heitmueller dheitmuel...@kernellabs.com:
 On Mon, Jan 18, 2010 at 10:01 AM, Valerio Bontempi
 valerio.bonte...@gmail.com wrote:
 Hi all,

 I am still having problem using v4l-dvb drivers with Terratec Cinergy T USB 
 XS.
 As reported in first mail, I am using the last version of v4l-dvb
 drivers with few lines adjustment in order to make this driver to
 enable dvb for my dvb only device (this because official v4l-dvb
 driver actually doesn't support my device at all)
 I have cleaned my distro (openSuse 11.2 x86-64) about all the v4l
 modules provided by distro's repositories, and I compiled modified
 v4l-dvb source.
 So acutally I am using a cleaned version of v4l-dvb.

 But the
 [ 1483.314420] zl10353_read_register: readreg error (reg=127, ret==-19)
 [ 1483.315166] mt352_read_register: readreg error (reg=127, ret==-19)
 error isn't solved yet.
 Could it be related to the firmware I am using?

 No, this has nothing to do with firmware.  It is probably an issue
 where the gpio configuration is wrong and the demod is being held in
 reset (hence it won't respond to i2c commands).

 The 0ccd:0043 is on my todo list of devices to work on (they sent me a
 sample board), although it's not the highest priority on my list given
 how old it is.

 Cheers,

 Devin

 --
 Devin J. Heitmueller - Kernel Labs
 http://www.kernellabs.com


Hi Devin,

maybe it could be useful: today, without any change from yesterday,
the device has been fully initialized at boot time.
From dmesg

  10.252753] xc2028 2-0061: Loading 80 firmware images from
xc3028-v27.fw, type: xc2028 firmware, ver 2.7
[   10.286264] xc2028 2-0061: Loading firmware for type=BASE (1), id
.
[   11.674270] xc2028 2-0061: Loading firmware for type=(0), id
b700.
[   11.701412] SCODE (2000), id b700:
[   11.701419] xc2028 2-0061: Loading SCODE for type=MONO SCODE
HAS_IF_4320 (60008000), id 8000.
[   11.824268] em28xx #0: v4l2 driver version 0.1.2
[   11.829157] em28xx #0: V4L2 video device registered as video1
[   11.830312] usbcore: registered new interface driver em28xx
[   11.830316] em28xx driver loaded
[   11.997659] xc2028 2-0061: attaching existing instance
[   11.997665] xc2028 2-0061: type set to XCeive xc2028/xc3028 tuner
[   11.997667] em28xx #0: em28xx #0/2: xc3028 attached
[   11.997671] DVB: registering new adapter (em28xx #0)
[   11.997675] DVB: registering adapter 0 frontend 0 (Zarlink ZL10353 DVB-T)...
[   11.998086] em28xx #0: Successfully loaded em28xx-dvb
[   11.998090] Em28xx: Initialized (Em28xx dvb Extension) extension

instead of (from /var/log/messages)

Jan 18 16:53:04 gandalf kernel: [ 4894.539028] xc2028 2-0061: Loading
80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7
Jan 18 16:53:04 gandalf kernel: [ 4894.575016] xc2028 2-0061: Loading
firmware for type=BASE (1), id .
Jan 18 16:53:05 gandalf kernel: [ 4895.972018] xc2028 2-0061: Loading
firmware for type=(0), id b700.
Jan 18 16:53:05 gandalf kernel: [ 4895.998010] SCODE (2000), id
b700:
Jan 18 16:53:05 gandalf kernel: [ 4895.998022] xc2028 2-0061: Loading
SCODE for type=MONO SCODE HAS_IF_4320 (60008000), id 8000.
Jan 18 16:53:05 gandalf kernel: [ 4896.122024] em28xx #0: v4l2 driver
version 0.1.2
Jan 18 16:53:05 gandalf kernel: [ 4896.127126] em28xx #0: V4L2 video
device registered as video1
Jan 18 16:53:05 gandalf kernel: [ 4896.129142] usbcore: registered new
interface driver em28xx
Jan 18 16:53:05 gandalf kernel: [ 4896.129157] em28xx driver loaded
Jan 18 16:53:05 gandalf kernel: [ 4896.155171] zl10353_read_register:
readreg error (reg=127, ret==-19)
Jan 18 16:53:05 gandalf kernel: [ 4896.155914] mt352_read_register:
readreg error (reg=127, ret==-19)
Jan 18 16:53:05 gandalf kernel: [ 4896.156419] em28xx #0: /2: dvb
frontend not attached. Can't attach xc3028
Jan 18 16:53:05 gandalf kernel: [ 4896.156434] Em28xx: Initialized
(Em28xx dvb Extension) extension

Is there a reason of this behaviour?

Valerio
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [ANNOUNCE] git tree repositories

2010-01-19 Thread Devin Heitmueller
Hello Mauro,

I find it somewhat unfortunate that this is labeled ANNOUNCE instead
of RFC.  It shows how little you care about soliciting the opinions
of the other developers.  Rather than making a proposal for how the
process can be improved and soliciting feedback, you have chosen to
decide for all of us what the best approach is and how all of us will
develop in the future.

I know you'll continue to receive alot of thank you and great job
comments from some of the developers who have been pushing for this,
so I'll be the bad guy and point out the downsides to what you are
proposing.

First off, I would like to note that I have absolutely no problem with
git.  I think it's a great tool and I use it for other projects.  If
the question today was which source control software to use, I have
no doubt I would choose git over mercurial.  I've used a variety of
different source control systems both open source and commercial, and
git is a really good tool.

That said, my real problem is with the change requiring all the active
developers to be developing on the latest Linux kernel.

Before I renew my arguments, I will openly acknowledge that your
approach does make numerous things easier.  I have little doubt that
it will make merging easier for you personally, as well as addresses
issues with patches that have architecture specific changes (or other
changes that are outside of the current v4l-dvb tree).

So let's talk about why this is bad

I want to focus my development on v4l-dvb.  That said, I want a stable
codebase on which I can write v4l-dvb drivers, without having to worry
about whether or not my wireless driver is screwed up this week, or
whether the ALSA guys broke my audio support for the fifth time in two
years.  I don't want to wonder whether the crash I just experienced is
because they've replaced the scheduler yet again and they're still
shaking the bugs out.  I don't want to be at the mercy of whatever ABI
changes they're doing this week which break my Nvidia card (and while
I recognize as open source developers we care very little about
closed source drivers, we shouldn't really find it surprising that
many developers who are rendering HD video might be using Nvidia
cards).

Like most smart developers, I want to have a *controlled* environment
where I can be confident that if a problem arises that it's *my*
changes at fault.  Any time that I spend trying to figure out why my
PC doesn't work is time that I'm not debugging v4l-dvb drivers.

And *THAT* is why it's critical that the mainline not be treated as
alpha quality like you suggested last week.  For example, when you
check in alpha code that causes an OOPS whenever any tuner with IR
support is plugged in, I waste several hours debugging the regression
you introduced instead of doing my own work.

Further, we're also changing from a system where we build a relatively
small tree of modules to one where we're going to be
building/installing entire kernels.  Even on my relatively recent
hardware, this is process that takes upwards to an hour (and yes, I do
have ccache).  Even a make modules_install can several minutes.  So
now I'm going from being able to make  make install  make unload
twenty times an hour to a *MUCH* slower process.

We're giving up the ability to have a fast debug-compile-test
cycle for developers in exchange for easier merging of the final
result.  This seems like a poor optimization choice for those of us
who spend all day compiling, debugging, and testing.

Personally, I spend about 98% of my time actively debugging code, and
about 2% of my time dealing with merge issues.  So I *really* care
about things like how long it takes to compile and install the tree.

I hope other developers will offer their opinions on this approach,
since it's all of us who will pay the price in time as a result of
this change.  If all the developers who are writing the code think
it's a good idea to be half as efficient in order to make the merging
easier for one person, then so be it.

The point I'm trying to make is that we need to be having a discussion
about what we are optimizing for, and what are the costs to other
developers.  This is why I'm perhaps a bit pissed to see an
announcement declaring how development will be done in the future as
opposed to a discussion of what we could be doing and what are the
trade-offs.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Hauppauge Win TV HVR-1300: streaming and grabbing fail after a while, changing resolution renders card inoperable

2010-01-19 Thread Friedrich Delgado Friedrichs
I'm sorry, two of the problems described in my mail have nothing to do
with the driver. There's a daemon running that accesses the tuner and
vbi (nxtvepg), which causes problems 1 and 2.

I've failed to notice this because nxtvepg can (normally) detect
tvtime and xawtv and doesn't interfere with them, so I assumed it
might have a general mechanism for detecting if the tv driver is in
use by a different app.

The third problem remains:

Friedel wrote:
 3) changing resolutions causes mpeg encoder stream to become
 completely inoperable

 When I switch resolutions in mythtv recording profile, but also via
 e.g.
 
 v4l2-ctl -d /dev/video1 --set-fmt-video=width=720,height=568
 
 I seem to totally break the encoder. There's no stream any more,
 
 ~ cat /dev/video1
 cat: /dev/video1: Input/output error
 
 And switching the resolution back doesn't help. Unloading the modules
 doesn't help either, I have to reboot the box.
 
 dmesg output pastebinned at http://pastebin.com/f4e27757a
 
 Tests were done with a 2.6.32 kernel from ubuntu.

Which I assume is a vanilla kernel. I might be wrong about this, too.

I could test with newer drivers or a newer kernel of course, if you
suspect that the problem might not be fixed yet.

 Please ask if there's any information you can't easily infer from this
 mail or the attached logs.


-- 
Friedrich Delgado Friedrichs frie...@nomaden.org
 TauPan on Ircnet and Freenode ;)


pgpp5FqgTNyRX.pgp
Description: PGP signature


Re: [ANNOUNCE] git tree repositories

2010-01-19 Thread Mauro Carvalho Chehab
Hans Verkuil wrote:
 On Tuesday 19 January 2010 06:34:18 Mauro Carvalho Chehab wrote:
 Hi,

 Due to that, I'm delegating the task of keeping -hg in sync with upstream 
 and backporting
 patches to run on older kernels to another person: Douglas has offered his 
 help to keep 
 the tree synchronized with the -git tree, and to add backport support. 

 He already started doing that, fixing some incompatibility troubles between 
 some drivers
 and older kernels.
 
 Mauro, I just wanted to thank you for doing all the hard work in moving to 
 git!

Anytime!

 I do have one proposal: parts of our hg tree are independent of git: 
 v4l2-apps,
 possibly some firmware build code (not 100% sure of that), v4l_experimental,
 perhaps some documentation stuff. My proposal is that we make a separate hg
 or git tree for those. It will make it easier to package by distros and it 
 makes it
 easier to maintain v4l2-apps et al as well. It might even simplify Douglas's 
 work
 by moving non-essential code out of the compat hg tree.

It may make sense, but I have some comments about it:
1) v4l_experimental - I think we may just drop it. It was meant to be a 
staging
area in the old days, but never worked. The 3 drivers there never suffered any 
maintanership.
Even the firewire driver that used to be there were developed independently. 
So, IMO, we can
just remove it and, if anyone needs those drivers, they can just look inside 
the -hg history.

2) firmware - the code there is just what we have in kernel. While this 
can be broken,
I can't see much sense, as I don't foresee any changes there: new firmwares are 
going to
linux-firmware tree and have an upstream maintainership in separate;

3) media docs - the docs are part of upstream tree. So, it doesn't make 
sense to have
a separate tree for it. IMO, the proper direction is to merge upstream the 
capability of 
automatic generation of some xml scripts (like videobuf2.h.xml). Yet, there are 
a few files
present on v4l2-apps that are also converted to xml, as they are usage examples 
at the API.
I'm not sure what to do with them.

4) v4l2-apps - I agree that splitting it could be a good idea, provided 
that we find
a way to handle the few cases where we have example applications at the media 
docs.
 
 I'll be updating my daily build scripts to start using git soon (I'll keep 
 using
 hg for the older kernels of course).

That's good! I always check if the -git compiles with x86_64, but I generally 
don't check
all architectures on my checks.

Cheers,
Mauro.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [ANNOUNCE] git tree repositories

2010-01-19 Thread Mauro Carvalho Chehab
Laurent Pinchart wrote:
 Hi Mauro,
 
 I would like to personally thank you for spending time on git support at 
 linuxtv.org. Git support was a long-awaited feature for many developers (and 
 I 
 certainly was one of them).
 
 All the work done behind the scene on linuxtv.org isn't seen by end-users and 
 can thus be less rewarding than working on the code. However, it's of 
 critical 
 importance to make the development process as smooth as possible. For that 
 reason, thank you again.

You're welcome!

Working at the infrastructure spends lots of time and, as you said, people
generally only note when there's something broken.

I'm quite confident that supporting -git is the proper path to make life easier
for contributors and developers and opening a new road to the future of the
subsystem.

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [ANNOUNCE] git tree repositories

2010-01-19 Thread Johannes Stezenbach
On Tue, Jan 19, 2010 at 09:10:39AM +0100, Patrick Boettcher wrote:
 
 BTW: I just made a clone of the git-tree - 365MB *ouff*. Maybe it's worth to 
 mention right now, that one big difference to HG in the way we have used it, 
 is 
 that one developer now can do all the work only with one clone of v4l-dvb and 
 using branches for each development.

Please note that you SHOULD NOT clone from linuxtv.org.
Please follow the description on the top of
http://linuxtv.org/git/

Most linux developers will have a clone of Linus' tree already,
and you can add as many remotes to that tree as you like.
It's much faster and more flexible that way.  If you once pulled
a clone of Linus' tree there is simply no need to ever clone
any other Linux tree ever again.

Oh, and if you manage to get your git tree in a state where
you don't know how to fix the mess, don't throw it away.
Go to the git mailing list and ask for advice. They love
customer feeedback. Helps them to improve their product
and make it more user friendly ;-)


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [ANNOUNCE] git tree repositories

2010-01-19 Thread Patrick Boettcher

On Tue, 19 Jan 2010, Johannes Stezenbach wrote:


On Tue, Jan 19, 2010 at 09:10:39AM +0100, Patrick Boettcher wrote:


BTW: I just made a clone of the git-tree - 365MB *ouff*. Maybe it's worth to
mention right now, that one big difference to HG in the way we have used it, is
that one developer now can do all the work only with one clone of v4l-dvb and
using branches for each development.


Please note that you SHOULD NOT clone from linuxtv.org.
Please follow the description on the top of
http://linuxtv.org/git/


Of course I cloned from git.kernel.org and not from linuxtv.org. Still it 
was my first clone of linux ever.


--

Patrick Boettcher - Kernel Labs
http://www.kernellabs.com/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [ANNOUNCE] git tree repositories

2010-01-19 Thread Patrick Boettcher

Hi Devin,

On Tue, 19 Jan 2010, Devin Heitmueller wrote:

[..]

I want to focus my development on v4l-dvb.  That said, I want a stable
codebase on which I can write v4l-dvb drivers, without having to worry
about whether or not my wireless driver is screwed up this week, or
whether the ALSA guys broke my audio support for the fifth time in two
years.  I don't want to wonder whether the crash I just experienced is
because they've replaced the scheduler yet again and they're still
shaking the bugs out.  I don't want to be at the mercy of whatever ABI
changes they're doing this week which break my Nvidia card (and while
I recognize as open source developers we care very little about
closed source drivers, we shouldn't really find it surprising that
many developers who are rendering HD video might be using Nvidia
cards).


I agree with Devin. We can't lose and off-tree build system like we have 
it today in v4l-dvb.


What I suggested in my first Email was to put the build system outside the 
v4l-dvb into another repo (e.g. 'v4l-dvb-build') and then telling it to 
make links from the linux-v4l-dvb/ clone.


I'm not sure what needs to be done for the backward-compat with #if
KERNEL_VERSION ... But I'm sure we can find a solution for that.

--

Patrick Boettcher - Kernel Labs
http://www.kernellabs.com/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [ANNOUNCE] git tree repositories

2010-01-19 Thread Mauro Carvalho Chehab
Patrick Boettcher wrote:
 On Tuesday 19 January 2010 08:53:10 Hans Verkuil wrote:
 On Tuesday 19 January 2010 06:34:18 Mauro Carvalho Chehab wrote:
 He already started doing that, fixing some incompatibility troubles
 between some drivers and older kernels.
 Mauro, I just wanted to thank you for doing all the hard work in moving to
  git!

 And a big 'thank you' to Douglas as well for taking over hg maintenance!
 
 A big thank you also from me. 

Wou're welcome.

 I'm strongly in need of a build-only-v4l-dvb build system. Because I'm most 
 of 
 the time using distro-kernels in my productive environments and I'm replacing 
 v4l/dvb drivers with the one from v4l-dvb.

We all need to have some ways to run the new drivers on distro kernels. If not
as a developer, at least as an user. So, I keep believing that the out-of-tree
compilation is fundamental to the success of the subsystem.
 
 One step into the direction of a solution might be:
 Why not including the v4l-dvb/v4l/Makefile and the related files into that 
 separate repository Hans is describing here and then telling 'make' to make 
 links to ../../v4l-dvb/ instead of ../linux as of today.

This is about what make kernel-links do, but in the opposite direction.
It shouldn't be hard do do that, but we need to fix the backports.
In the case of -alsa, they opted to use this strategy for their backported
tree, patching the kernel when building it.

 But I don't know how to solve the ifdef KERNEL_VERSION for having backward 
 compatibility in the source files. Maybe with a patch for each kernel version?

It can be a patch for each kernel version, but this will remove support for some
distro-kernels where the KABI has changed. Another solution is to have a pile
of patches that will be applied as the compilation breaks. This can work, but we
need to find a way to produce those patches.

Maybe the simplest solution is to keep maintaining the -hg and having an 
auto-generated
tree that will have just the building system and a diff between -git and -hg. If
both are synchronized, the only difference will be the backports.

 BTW: I just made a clone of the git-tree - 365MB *ouff*.

Yes, this is one problem with -git: as it contains the entire kernel struct, 
and an
history since 2.6.11, it is about 9 times bigger than the -hg tree, where only
the media files are stored.

Yet, git clone has a way to allow removing the history of the kernel, producing 
a 
small result --depth:

$ git clone --depth 1 --bare v4l-dvb tmp

This gives about 128M (about 3x -hg). Yet, trees generated with --depth have 
some
disadvantages.


 Maybe it's worth to 
 mention right now, that one big difference to HG in the way we have used it, 
 is 
 that one developer now can do all the work only with one clone of v4l-dvb and 
 using branches for each development.

Yes. The cost for a new branch is zero. Also, the cost of a new clone is less 
than
1M, if you use the --shared.

On my daily usage, I use a lot to clone with --shared, and doing my work on 
independent
directories. The advantage is that you avoid messing your temporary work. You 
may
even pull or push just one branch into another tree. So, working with git offers
lots of new possibilities to the developers.

Cheers,
Mauro.

 
 best regards,

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [ANNOUNCE] git tree repositories

2010-01-19 Thread Mauro Carvalho Chehab
Devin Heitmueller wrote:
 Hello Mauro,
 
 I find it somewhat unfortunate that this is labeled ANNOUNCE instead
 of RFC.  It shows how little you care about soliciting the opinions
 of the other developers.  Rather than making a proposal for how the
 process can be improved and soliciting feedback, you have chosen to
 decide for all of us what the best approach is and how all of us will
 develop in the future.

The announcement by purpose doesn't contain any changes on the process,
since it requires some discussions before we go there. It is just the
first step, where -git tree support were created. It also announces
that I personally won't keep maintaining -hg, delegating its task
to Douglas.

 The point I'm trying to make is that we need to be having a discussion
 about what we are optimizing for, and what are the costs to other
 developers.  This is why I'm perhaps a bit pissed to see an
 announcement declaring how development will be done in the future as
 opposed to a discussion of what we could be doing and what are the
 trade-offs.

I fully understand that supporting the development and tests with an
out of tree building is important to everybody. So, the plans are
to keep the out-of-tree building system maintained, and even
improving it. I'd like to thank to Douglas for his help on making 
this happen.

Cheers,
Mauro.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [ANNOUNCE] git tree repositories

2010-01-19 Thread Mauro Carvalho Chehab
 So am I. I hope the future will prove us right :-)

:)

 How do your new git scripts process commits ? In particular, does the 
 Priority: line still applies ?

For patches imported from -hg, the script will handle Priority. For patches
generated against -git, maybe the better is to have separate branches or 
trees: one for fixes and another for new stuff, and an indication, at the
pull request, to what tree the patch will be applied.

We still need some discussions about the process. One of the issues is how
do we'll handle SOB's. My SOB should be added on all patches. Also, sometimes,
patches may need to receive other SOB-like tags, like acked-by. I'm not
sure yet how should we handle it, since a change at the patch description
will change the hash code. -git merge is generally smart enough to not
generate a conflict between two patches with identical diffs, but we need
to do some tests in order to check what would be the better procedure.

Cheers,
Mauro.


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [ANNOUNCE] git tree repositories

2010-01-19 Thread Mauro Carvalho Chehab
Patrick Boettcher wrote:
 Hi Devin,
 
 On Tue, 19 Jan 2010, Devin Heitmueller wrote:
 [..]

 I want to focus my development on v4l-dvb.  That said, I want a stable
 codebase on which I can write v4l-dvb drivers, without having to worry
 about whether or not my wireless driver is screwed up this week, or
 whether the ALSA guys broke my audio support for the fifth time in two
 years.  I don't want to wonder whether the crash I just experienced is
 because they've replaced the scheduler yet again and they're still
 shaking the bugs out.  I don't want to be at the mercy of whatever ABI
 changes they're doing this week which break my Nvidia card (and while
 I recognize as open source developers we care very little about
 closed source drivers, we shouldn't really find it surprising that
 many developers who are rendering HD video might be using Nvidia
 cards).
 
 I agree with Devin. We can't lose and off-tree build system like we have
 it today in v4l-dvb.
 
 What I suggested in my first Email was to put the build system outside
 the v4l-dvb into another repo (e.g. 'v4l-dvb-build') and then telling it
 to make links from the linux-v4l-dvb/ clone.
 
 I'm not sure what needs to be done for the backward-compat with #if
 KERNEL_VERSION ... But I'm sure we can find a solution for that.

I started a branch with an alternative for if KERNEL_VERSION. Please see:
http://linuxtv.org/hg/~mchehab/backport/

Basically, it has some perl rules that identifies the points on the source
code where an KABI function has changed and dynamically patches the code.
On my tests, this strategy works fine, but I haven't finished removing
all KERNEL_VERSION checks from the code.

If someone is interested, please be my guest fixing the code and improving it.

Cheers,
Mauro.

 
 -- 
 
 Patrick Boettcher - Kernel Labs
 http://www.kernellabs.com/

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [ANNOUNCE] git tree repositories

2010-01-19 Thread Mauro Carvalho Chehab
Johannes Stezenbach wrote:
 On Tue, Jan 19, 2010 at 09:10:39AM +0100, Patrick Boettcher wrote:
 BTW: I just made a clone of the git-tree - 365MB *ouff*. Maybe it's worth to 
 mention right now, that one big difference to HG in the way we have used it, 
 is 
 that one developer now can do all the work only with one clone of v4l-dvb 
 and 
 using branches for each development.
 
 Please note that you SHOULD NOT clone from linuxtv.org.
 Please follow the description on the top of
 http://linuxtv.org/git/
 
 Most linux developers will have a clone of Linus' tree already,
 and you can add as many remotes to that tree as you like.

Yes. I have here one stable tree that have one remote for every stable
tree since 2.6.16.

 It's much faster and more flexible that way.  If you once pulled
 a clone of Linus' tree there is simply no need to ever clone
 any other Linux tree ever again.

Yes. I personally prefer to have a bare clone (bare trees have just
the -git objects, and not a workig tree), and several working copies.
I do the work at the working copies, and, after they are fine, I push
into the bare and send the branches from bare to upstream.

 Oh, and if you manage to get your git tree in a state where
 you don't know how to fix the mess, don't throw it away.
 Go to the git mailing list and ask for advice. They love
 customer feeedback. Helps them to improve their product
 and make it more user friendly ;-)

Yes. One good thing to do is to take a look at git reflog. It tracks
all the changes you do, and you can always ask git to move to a different
object at the tree, undoing the bad thing you did ;)
 
 
 Johannes

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [ANNOUNCE] git tree repositories

2010-01-19 Thread Laurent Pinchart
Hi Mauro,

I've started playing with the linuxtv git repositories. I've cloned v4l-
dvb.git into git://linuxtv.org/pinchartl/uvcvideo.git using git-menu and now 
have trouble pushing changes:

$ git push -v uvcvideo
Pushing to git://linuxtv.org/pinchartl/uvcvideo.git
fatal: The remote end hung up unexpectedly

What URL should I use to push changes ? 

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [ANNOUNCE] git tree repositories

2010-01-19 Thread Mauro Carvalho Chehab
Laurent Pinchart wrote:
 Hi Mauro,
 
 I've started playing with the linuxtv git repositories. I've cloned v4l-
 dvb.git into git://linuxtv.org/pinchartl/uvcvideo.git using git-menu and now 
 have trouble pushing changes:
 
 $ git push -v uvcvideo
 Pushing to git://linuxtv.org/pinchartl/uvcvideo.git
 fatal: The remote end hung up unexpectedly
 
 What URL should I use to push changes ? 
 
Push will only work if you use the ssh url. the url is basically the same
of http, but replacing to ssh:
ssh://linuxtv.org/git/tree

On your case
ssh://linuxtv.org/git/pinchartl/uvcvideo.git

Cheers,
Mauro.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [ANNOUNCE] git tree repositories

2010-01-19 Thread Laurent Pinchart
Hi Mauro,

On Tuesday 19 January 2010 14:07:39 Mauro Carvalho Chehab wrote:
 Laurent Pinchart wrote:
  Hi Mauro,
 
  I've started playing with the linuxtv git repositories. I've cloned v4l-
  dvb.git into git://linuxtv.org/pinchartl/uvcvideo.git using git-menu and
  now have trouble pushing changes:
 
  $ git push -v uvcvideo
  Pushing to git://linuxtv.org/pinchartl/uvcvideo.git
  fatal: The remote end hung up unexpectedly
 
  What URL should I use to push changes ?
 
 Push will only work if you use the ssh url. the url is basically the same
 of http, but replacing to ssh:
   ssh://linuxtv.org/git/tree
 
 On your case
   ssh://linuxtv.org/git/pinchartl/uvcvideo.git

One step further:

$ git push -v uvcvideo
Pushing to ssh://linuxtv.org/git/pinchartl/uvcvideo.git
Permission denied (publickey).
fatal: The remote end hung up unexpectedly

Do I need to upload my public key somewhere ? I already use it with hg push 
(and ssh git-menu) without any issue.

-- 
Cheers,

Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: DM1105: could not attach frontend 195d:1105

2010-01-19 Thread Igor M. liplianin
2010/1/19  pau...@planar.id.au:
 Well, as I understood, GPIO15 drives reset for demod.
 dm1105 driver needs little patching.



 Igor,

 Not to hassle you, I'm sure you're very busy.  Is this something I could
 undertake myself?  If so, which driver would you recommend I copy from - I
 saw on the list that some drivers do their own GPIO management, and others
 use a generic GPIO layer.  I presume we'd need to use the generic layer?

 Also, from your explanation it sounds like we need to set GPIO 15 to true
 before we attempt to attach.  Is that correct?  From my reading there are
 two GPIO registers (8 bits each), so we'd be bit masking bit 7 in the
 second GPIO register to 1, then sending that GPIO to the card?

 Thanks for any tips,

 Paul



As you can see there is two 32-bit registers. First for values, second
for controls. Control means 0 for output and 1 for input.
If I remember it is 17 GPIO lines only.

/* GPIO Interface */
#define DM1105_GPIOVAL  0x08
#define DM1105_GPIOCTR  0x0c


BR

Igor
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


TDA18272

2010-01-19 Thread Simon Kenyon

just wondering if there are any cards which use this?
or are there any planned cards?

not in the UK so don't yet need DVB-T2, but nevertheless curious
--
simon
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH/RFC v1 0/1] Buffer sync for non cache-coherent architectures

2010-01-19 Thread Pawel Osciak

Hello,

this is the initial patch for buffer data synchronization for architectures
with non-coherent cache.


=
Rationale
=

Architectures with non-coherent CPU cache (e.g. ARM) require a sync both before
and after a hardware operation. Until now, videobuf could work properly for
cache-coherent memory areas only, which for ARM actually means no cache at all.
This is not only reduces functionality, but hinders performance.

We would like to add support for video buffers present in CPU-cached areas as
well, which is especially important for OUTPUT buffers, but valid for CAPTURE
buffers as well (see DMA_FROM_DEVICE below).


We have isolated 4 different types of sync operations. Three of them are the
ones defined in pci.h and dma-mapping.h (enum dma_data_direction):

- DMA_FROM_DEVICE - the buffer is to be used as a destination buffer, the
  data contained within before the operation is unimportant.

  Although the data in memory is not important, we have to prevent a possible
  future writeback to it resulting in an accidental overwrite of contents
  produced by hardware after an operation. This requires cache invalidation
  before the operation.

- DMA_TO_DEVICE - the data in buffer has been touched by (prepared using)
   the CPU and will be used as valid source for an operation. This data
   may still be in cache but not yet in memory. This requires a writeback.

- DMA_BIDIRECTIONAL - the buffer will be used as both source and destination.
  This requires both writeback and cache invalidation.

There is one more operation we are considering, although not really
cache-related:

- FINISH - the operation is finished and the data in buffer (put there by
  hardware) will be used further.

  Operations required here may include:
  * Making the memory pages involved in the operation dirty.
  * Copying data back from a bounce buffer.
  They are not strictly cache-related, but valid from the point of view
  of our proposed approach.



From the point of view of the videobuf framework, the following scenarios can 
be
isolated, depending on when the sync has been called and current buffer type:

- before hardware operation
   - OUTPUT: DMA_TO_DEVICE
   - CAPTURE: DMA_FROM_DEVICE

- after hardware operation
   - OUTPUT: nothing
   - CAPTURE: FINISH

DMA_BIDIRECTIONAL would take place for OUTPUT+CAPTURE buffers, which are not
(yet?) used in videobuf.


=
sync() in videobuf
=

videobuf includes a sync operation, declared in struct videobuf_qtype_ops,
which can be implemented by each memory type-specific module. It is used for
different purposes than cache management though, namely for operations like
copying data back from bounce buffers after an operation.
Only videobuf-dma-sg does anything in its sync currently.

Operations required to be done before hardware operation is started are
currently performed in iolock(), but it is not usable for cache coherency
management. The reason for this is that iolock() is intended to be run once
per buffer, not once per each hardware operation. Cache coherency operations
have to be performed before every operation though, also on previously
iolock()ed buffers.

We believe that the existing videobuf sync() operation can be extended for cache
management. This requires adding sync() calls before each hardware operation
as well. It is left to the callee to determine the kind of sync requested,
taking into account the guidelines below.

No new flags/states/etc. have to be added to videobuf for it to support all
kinds of syncs mentioned above. Current sync type can be determined in
memory-specific code in two steps:

1. CAPTURE or OUTPUT - based on buffer type in struct videobuf_queue.
2. before or after operation - based on buffer state in struct videobuf_buffer:
VIDEOBUF_DONE or VIDEOBUF_ERROR - after, otherwise - before.


Example (pseudo)code for a sync() operation:

#define is_sync_after(vb) \
(vb-state == VIDEOBUF_DONE || vb-state == VIDEOBUF_ERROR)

int videobuf_foo_sync(struct videobuf_queue *q, struct videobuf_buffer *vb)
{
/* ... */

if (is_sync_after(vb) {
/* Sync after operation */
if (q-type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
do_sync_finish();
} else if (q-type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
/* nothing, unless we are missing something */
}
} else {
/* Sync before operation */
if (q-type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
do_sync_from_device();
} else if (q-type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
do_sync_to_device();
}
}

/* ... */
}



=
About this patch
=

This is a very small patch, just a starting point for future, memory-specific
development. No existing functionality is changed. These are the only changes
that - in our opinion - are required in the core framework. Each memory-specific
videobuf submodule will 

[PATCH v1 1/1] V4L: Add sync before a hardware operation to videobuf.

2010-01-19 Thread Pawel Osciak
Architectures with non-coherent CPU cache (e.g. ARM) may require a cache
flush or invalidation before starting a hardware operation if the data in
a video buffer being queued has been touched by the CPU.

This patch adds calls to sync before a hardware operation that are expected
to be interpreted and handled by each memory type-specific module.

Whether it is a sync before or after the operation can be determined from
the current buffer state: VIDEOBUF_DONE and VIDEOBUF_ERROR indicate a sync
called after an operation.

Signed-off-by: Pawel Osciak p.osc...@samsung.com
Reviewed-by: Marek Szyprowski m.szyprow...@samsung.com
Reviewed-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/video/videobuf-core.c   |9 +
 drivers/media/video/videobuf-dma-sg.c |6 ++
 2 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/videobuf-core.c 
b/drivers/media/video/videobuf-core.c
index bb0a1c8..e56c67a 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -561,6 +561,8 @@ int videobuf_qbuf(struct videobuf_queue *q,
goto done;
}
 
+   CALL(q, sync, q, buf);
+
list_add_tail(buf-stream, q-stream);
if (q-streaming) {
spin_lock_irqsave(q-irqlock, flags);
@@ -761,6 +763,8 @@ static ssize_t videobuf_read_zerocopy(struct videobuf_queue 
*q,
if (0 != retval)
goto done;
 
+   CALL(q, sync, q, q-read_buf);
+
/* start capture  wait */
spin_lock_irqsave(q-irqlock, flags);
q-ops-buf_queue(q, q-read_buf);
@@ -826,6 +830,8 @@ ssize_t videobuf_read_one(struct videobuf_queue *q,
goto done;
}
 
+   CALL(q, sync, q, q-read_buf);
+
spin_lock_irqsave(q-irqlock, flags);
q-ops-buf_queue(q, q-read_buf);
spin_unlock_irqrestore(q-irqlock, flags);
@@ -893,6 +899,9 @@ static int __videobuf_read_start(struct videobuf_queue *q)
err = q-ops-buf_prepare(q, q-bufs[i], field);
if (err)
return err;
+
+   CALL(q, sync, q, q-read_buf);
+
list_add_tail(q-bufs[i]-stream, q-stream);
}
spin_lock_irqsave(q-irqlock, flags);
diff --git a/drivers/media/video/videobuf-dma-sg.c 
b/drivers/media/video/videobuf-dma-sg.c
index fa78555..2b153f8 100644
--- a/drivers/media/video/videobuf-dma-sg.c
+++ b/drivers/media/video/videobuf-dma-sg.c
@@ -50,6 +50,9 @@ MODULE_LICENSE(GPL);
 #define dprintk(level, fmt, arg...)if (debug = level) \
printk(KERN_DEBUG vbuf-sg:  fmt , ## arg)
 
+#define is_sync_after(vb) \
+   (vb-state == VIDEOBUF_DONE || vb-state == VIDEOBUF_ERROR)
+
 /* - */
 
 struct scatterlist*
@@ -516,6 +519,9 @@ static int __videobuf_sync(struct videobuf_queue *q,
BUG_ON(!mem);
MAGIC_CHECK(mem-magic,MAGIC_SG_MEM);
 
+   if (!is_sync_after(buf))
+   return 0;
+
return  videobuf_dma_sync(q,mem-dma);
 }
 
-- 
1.6.4.2.253.g0b1fac

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: RE: How to use saa7134 gpio via gpio-sysfs?

2010-01-19 Thread Gordon Smith
On Mon, Jan 18, 2010 at 5:01 PM, hermann pitton hermann-pit...@arcor.de wrote:
 Hello,

 Am Montag, den 18.01.2010, 18:11 -0500 schrieb Will Tate:
 I'm not sure why access in userspace would be required.  I checked the
 schematic today and all the GPIO pins are used to communicate with the
 SAA6752HS on board for compression.  We do not bring the GPIO off the
 board anywhere.

 thank you very much. I was still expecting that and did not get Gordon's
 point, but must admit to have been totally unaware about the DI/O
 features. RTD did all the hardware implementations themselves.

 Very nice job that time.

 Gordon and I have spoken previously about the RTD software for digital
 I/O breaking with the migration of pcf8574 driver to the pcf857x.  So,
 perhaps he intended to use GPIO until I can fix the digital I/O
 software.

 Ah, good to know. BTW, we had the mpeg encoder broken unnoticed for some
 kernels, but due to fixes by Dmitri Belimov and extensions by Hans
 Verkuil, we are much better on it these days. Enjoy.

 Always let us know, if we can do anything or at least make it public for
 those interested to work on it.

 Thanks,
 Hermann


Hello Hermann, good to hear from you again.

It looks like I was off track regarding GPIO. In 2.6.30 the pcf8574
module that was used for digital I/O earlier was no longer available
and something I read lead me to believe I should use gpio-sysfs
instead. I'm sorry for the noise.

- Gordon
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: omap34xxcam question?

2010-01-19 Thread Michael Trimarchi

Michael Trimarchi wrote:

Aguirre, Sergio wrote:



-Original Message-
From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org]
Sent: Thursday, January 14, 2010 11:39 AM
To: Aguirre, Sergio
Cc: linux-media@vger.kernel.org
Subject: Re: omap34xxcam question?

Aguirre, Sergio wrote:

-Original Message-
From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org]
Sent: Thursday, January 14, 2010 11:25 AM
To: Aguirre, Sergio
Cc: linux-media@vger.kernel.org
Subject: Re: omap34xxcam question?

Hi,

Aguirre, Sergio wrote:

-Original Message-
From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org]
Sent: Thursday, January 14, 2010 6:01 AM
To: linux-media@vger.kernel.org
Cc: Aguirre, Sergio
Subject: omap34xxcam question?

Hi

Is ok that it try only the first format and size? why does it not

continue

and find a matching?

Actually, that was the intention, but I guess it was badly

implemented.

Thanks for the catch, and the contribution!

Regards,
Sergio

@@ -470,7 +471,7 @@ static int try_pix_parm(struct

omap34xxcam_videodev

*vdev,
pix_tmp_out = *wanted_pix_out;
rval = isp_try_fmt_cap(isp, pix_tmp_in,
pix_tmp_out);
if (rval)
-   return rval;
+   continue;


Is the patch good? or you are going to provide a better fix

Yes. Sorry if I wasn't clear enough.

Looks good to me, and I don't have a better fix on top of my head for

the moment...

I'm assuming you tested it in your environment, right?

Ok, my enviroment is not pretty stable but for sure this is required.
There is one problem:

Suppose that the camera support this format:

YUV and RAW10

The video4linux enumeration is done in this order.
We know that if you want to use resizer and previewer we can't use 
the YUV

(go straight to memory)
but it is selected because is the first. So maybe the best thing is to
find the one that is suggest in the csi
configuration first. Hope that is clear.


Hmm.. I see.

So, if I got you right, you're saying that, there should be priorities 
for sensor baseformats, depending on the preference specified 
somewhere in the boardfile?


Yes, that is the idea. Try to provide a better patch later, I'm working 
hard on the sensor part :)




diff --git a/drivers/media/video/omap34xxcam.c b/drivers/media/video/omap34xxcam
index 53b587e..75bd858 100644
--- a/drivers/media/video/omap34xxcam.c
+++ b/drivers/media/video/omap34xxcam.c
@@ -448,6 +448,10 @@ static int try_pix_parm(struct omap34xxcam_videodev *vdev,
   break;
   dev_dbg(vdev-vfd-dev, trying fmt %8.8x (%d)\n,
   fmtd.pixelformat, fmtd_index);
+
+   if (fmtd.pixelformat != best_pix_in-pixelformat)
+   continue;
+
   /*
* Get supported resolutions.
*/
@@ -470,7 +474,7 @@ static int try_pix_parm(struct omap34xxcam_videodev *vdev,
   pix_tmp_out = *wanted_pix_out;
   rval = isp_try_fmt_cap(isp, pix_tmp_in, pix_tmp_out);
   if (rval)
-   return rval;
+   continue;

   dev_dbg(vdev-vfd-dev, this w %d\th %d\tfmt %8.8x\t

Somenthing like that.

michael

Michael



Regards,
Sergio

Michael


If yes, then I'll take the patch in my queue for submission to Sakari's

tree.

Thanks for your time.

Regards,
Sergio


Michael


Michael

--
To unsubscribe from this list: send the line unsubscribe 
linux-media

in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line unsubscribe linux-media

in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] Support for LT168G sensor on t613 webcam driver

2010-01-19 Thread Nicolau Werneck
Patch to support this sensor, with id code 0x0802, on the t613
driver. I just sniffed the values from the driver that came with mine,
and made the proper extensions to the original code.

Signed-off-by: Nicolau Werneck nwern...@gmail.com
diff -Nru gspca-54a57b75f98c/linux/drivers/media/video/gspca/t613.c 
gspca-54a57b75f98c-dev/linux/drivers/media/video/gspca/t613.c
--- gspca-54a57b75f98c/linux/drivers/media/video/gspca/t613.c   2009-12-30 
02:53:07.0 -0500
+++ gspca-54a57b75f98c-dev/linux/drivers/media/video/gspca/t613.c   
2009-12-30 10:52:47.0 -0500
@@ -52,6 +52,7 @@
 #define SENSOR_OM6802 0
 #define SENSOR_OTHER 1
 #define SENSOR_TAS5130A 2
+#define SENSOR_LT168G 3 /* must verify if this is the actual model */
 };
 
 /* V4L2 controls supported by the driver */
@@ -306,6 +307,17 @@
0xbe, 0x36, 0xbf, 0xff, 0xc2, 0x88, 0xc5, 0xc8,
0xc6, 0xda
 };
+static const u8 n4_lt168g[] = {
+   0x66, 0x01, 0x7f, 0x00, 0x80, 0x7c, 0x81, 0x28,
+   0x83, 0x44, 0x84, 0x20, 0x86, 0x20, 0x8a, 0x70,
+   0x8b, 0x58, 0x8c, 0x88, 0x8d, 0xa0, 0x8e, 0xb3,
+   0x8f, 0x24, 0xa1, 0xb0, 0xa2, 0x38, 0xa5, 0x20,
+   0xa6, 0x4a, 0xa8, 0xe8, 0xaf, 0x38, 0xb0, 0x68,
+   0xb1, 0x44, 0xb2, 0x88, 0xbb, 0x86, 0xbd, 0x40,
+   0xbe, 0x26, 0xc1, 0x05, 0xc2, 0x88, 0xc5, 0xc0,
+   0xda, 0x8e, 0xdb, 0xca, 0xdc, 0xa8, 0xdd, 0x8c,
+   0xde, 0x44, 0xdf, 0x0c, 0xe9, 0x80
+};
 
 static const struct additional_sensor_data sensor_data[] = {
 {  /* 0: OM6802 */
@@ -422,6 +434,23 @@
.stream =
{0x0b, 0x04, 0x0a, 0x40},
 },
+{  /* 3: LT168G */
+   .n3 = {0x61, 0xc2, 0x65, 0x68, 0x60, 0x00},
+   .n4 = n4_lt168g,
+   .n4sz = sizeof n4_lt168g,
+   .reg80 = 0x7c,
+   .reg8e = 0xb3,
+   .nset8 = {0xa8, 0xf0, 0xc6, 0xba, 0xc0, 0x00},
+   .data1 = {0xc0, 0x38, 0x08, 0x10, 0xc0, 0x30, 0x10, 0x40,
+0xb0, 0xf4},
+   .data2 = {0x40, 0x80, 0xc0, 0x50, 0xa0, 0xf0, 0x53, 0xa6,
+0xff},
+   .data3 = {0x40, 0x80, 0xc0, 0x50, 0xa0, 0xf0, 0x53, 0xa6,
+0xff},
+   .data4 = {0x66, 0x41, 0xa8, 0xf0},
+   .data5 = {0x0c, 0x03, 0xab, 0x4b, 0x81, 0x2b},
+   .stream = {0x0b, 0x04, 0x0a, 0x28},
+},
 };
 
 #define MAX_EFFECTS 7
@@ -758,6 +787,10 @@
PDEBUG(D_PROBE, sensor tas5130a);
sd-sensor = SENSOR_TAS5130A;
break;
+   case 0x0802:
+   PDEBUG(D_PROBE, sensor lt168g);
+   sd-sensor = SENSOR_LT168G;
+   break;
case 0x0803:
PDEBUG(D_PROBE, sensor 'other');
sd-sensor = SENSOR_OTHER;
@@ -800,6 +833,13 @@
reg_w_buf(gspca_dev, sensor-n3, sizeof sensor-n3);
reg_w_buf(gspca_dev, sensor-n4, sensor-n4sz);
 
+   if (sd-sensor == SENSOR_LT168G) {
+   test_byte = reg_r(gspca_dev, 0x80);
+   PDEBUG(D_STREAM, Reg 0x%02x = 0x%02x, 0x80,
+  test_byte);
+   reg_w(gspca_dev, 0x6c80);
+   }
+
reg_w_ixbuf(gspca_dev, 0xd0, sensor-data1, sizeof sensor-data1);
reg_w_ixbuf(gspca_dev, 0xc7, sensor-data2, sizeof sensor-data2);
reg_w_ixbuf(gspca_dev, 0xe0, sensor-data3, sizeof sensor-data3);
@@ -824,6 +864,13 @@
reg_w_buf(gspca_dev, sensor-nset8, sizeof sensor-nset8);
reg_w_buf(gspca_dev, sensor-stream, sizeof sensor-stream);
 
+   if (sd-sensor == SENSOR_LT168G) {
+   test_byte = reg_r(gspca_dev, 0x80);
+   PDEBUG(D_STREAM, Reg 0x%02x = 0x%02x, 0x80,
+  test_byte);
+   reg_w(gspca_dev, 0x6c80);
+   }
+
reg_w_ixbuf(gspca_dev, 0xd0, sensor-data1, sizeof sensor-data1);
reg_w_ixbuf(gspca_dev, 0xc7, sensor-data2, sizeof sensor-data2);
reg_w_ixbuf(gspca_dev, 0xe0, sensor-data3, sizeof sensor-data3);
@@ -930,6 +977,8 @@
case SENSOR_OM6802:
om6802_sensor_init(gspca_dev);
break;
+   case SENSOR_LT168G:
+   break;
case SENSOR_OTHER:
break;
default:

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 2.6.16-2.6.21: ERRORS

2010-01-19 Thread Hans Verkuil
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Tue Jan 19 19:00:04 CET 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   14011:c3cc688bde82
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

linux-2.6.30-armv5: OK
linux-2.6.31-armv5: OK
linux-2.6.32-armv5: OK
linux-2.6.33-rc2-armv5: OK
linux-2.6.32-armv5-davinci: WARNINGS
linux-2.6.33-rc2-armv5-davinci: WARNINGS
linux-2.6.30-armv5-ixp: WARNINGS
linux-2.6.31-armv5-ixp: WARNINGS
linux-2.6.32-armv5-ixp: WARNINGS
linux-2.6.33-rc2-armv5-ixp: WARNINGS
linux-2.6.30-armv5-omap2: WARNINGS
linux-2.6.31-armv5-omap2: WARNINGS
linux-2.6.32-armv5-omap2: WARNINGS
linux-2.6.33-rc2-armv5-omap2: WARNINGS
linux-2.6.22.19-i686: WARNINGS
linux-2.6.23.12-i686: WARNINGS
linux-2.6.24.7-i686: WARNINGS
linux-2.6.25.11-i686: WARNINGS
linux-2.6.26-i686: WARNINGS
linux-2.6.27-i686: WARNINGS
linux-2.6.28-i686: WARNINGS
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30-i686: WARNINGS
linux-2.6.31-i686: WARNINGS
linux-2.6.32-i686: WARNINGS
linux-2.6.33-rc2-i686: WARNINGS
linux-2.6.30-m32r: OK
linux-2.6.31-m32r: OK
linux-2.6.32-m32r: OK
linux-2.6.33-rc2-m32r: OK
linux-2.6.30-mips: WARNINGS
linux-2.6.31-mips: WARNINGS
linux-2.6.32-mips: WARNINGS
linux-2.6.33-rc2-mips: WARNINGS
linux-2.6.30-powerpc64: WARNINGS
linux-2.6.31-powerpc64: WARNINGS
linux-2.6.32-powerpc64: WARNINGS
linux-2.6.33-rc2-powerpc64: WARNINGS
linux-2.6.22.19-x86_64: WARNINGS
linux-2.6.23.12-x86_64: WARNINGS
linux-2.6.24.7-x86_64: WARNINGS
linux-2.6.25.11-x86_64: WARNINGS
linux-2.6.26-x86_64: WARNINGS
linux-2.6.27-x86_64: WARNINGS
linux-2.6.28-x86_64: WARNINGS
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30-x86_64: WARNINGS
linux-2.6.31-x86_64: WARNINGS
linux-2.6.32-x86_64: WARNINGS
linux-2.6.33-rc2-x86_64: WARNINGS
spec: OK
sparse (linux-2.6.32): ERRORS
sparse (linux-2.6.33-rc2): ERRORS
linux-2.6.16.61-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: ERRORS
linux-2.6.19.5-i686: OK
linux-2.6.20.21-i686: WARNINGS
linux-2.6.21.7-i686: WARNINGS
linux-2.6.16.61-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: ERRORS
linux-2.6.19.5-x86_64: OK
linux-2.6.20.21-x86_64: WARNINGS
linux-2.6.21.7-x86_64: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2

The V4L-DVB specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: RE: How to use saa7134 gpio via gpio-sysfs?

2010-01-19 Thread hermann pitton
Hello Gordon,

Am Dienstag, den 19.01.2010, 10:24 -0700 schrieb Gordon Smith:
 On Mon, Jan 18, 2010 at 5:01 PM, hermann pitton hermann-pit...@arcor.de 
 wrote:
  Hello,
 
  Am Montag, den 18.01.2010, 18:11 -0500 schrieb Will Tate:
  I'm not sure why access in userspace would be required.  I checked the
  schematic today and all the GPIO pins are used to communicate with the
  SAA6752HS on board for compression.  We do not bring the GPIO off the
  board anywhere.
 
  thank you very much. I was still expecting that and did not get Gordon's
  point, but must admit to have been totally unaware about the DI/O
  features. RTD did all the hardware implementations themselves.
 
  Very nice job that time.
 
  Gordon and I have spoken previously about the RTD software for digital
  I/O breaking with the migration of pcf8574 driver to the pcf857x.  So,
  perhaps he intended to use GPIO until I can fix the digital I/O
  software.
 
  Ah, good to know. BTW, we had the mpeg encoder broken unnoticed for some
  kernels, but due to fixes by Dmitri Belimov and extensions by Hans
  Verkuil, we are much better on it these days. Enjoy.
 
  Always let us know, if we can do anything or at least make it public for
  those interested to work on it.
 
  Thanks,
  Hermann
 
 
 Hello Hermann, good to hear from you again.
 
 It looks like I was off track regarding GPIO. In 2.6.30 the pcf8574
 module that was used for digital I/O earlier was no longer available
 and something I read lead me to believe I should use gpio-sysfs
 instead. I'm sorry for the noise.
 
 - Gordon

no problem at all.

It was quite interesting to think about such gpio use.

If such a card appears in the future, we can point to the thread you
started here and have already, thanks to Trent, a collection of good
ideas and comments.

Cheers,
Hermann


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [ANNOUNCE] git tree repositories

2010-01-19 Thread Bob Cunningham

On 01/19/2010 04:16 AM, Mauro Carvalho Chehab wrote:

Devin Heitmueller wrote:

Hello Mauro,

I find it somewhat unfortunate that this is labeled ANNOUNCE instead
of RFC.  It shows how little you care about soliciting the opinions
of the other developers.  Rather than making a proposal for how the
process can be improved and soliciting feedback, you have chosen to
decide for all of us what the best approach is and how all of us will
develop in the future.


The announcement by purpose doesn't contain any changes on the process,
since it requires some discussions before we go there. It is just the
first step, where -git tree support were created. It also announces
that I personally won't keep maintaining -hg, delegating its task
to Douglas.


The point I'm trying to make is that we need to be having a discussion
about what we are optimizing for, and what are the costs to other
developers.  This is why I'm perhaps a bit pissed to see an
announcement declaring how development will be done in the future as
opposed to a discussion of what we could be doing and what are the
trade-offs.


I fully understand that supporting the development and tests with an
out of tree building is important to everybody. So, the plans are
to keep the out-of-tree building system maintained, and even
improving it. I'd like to thank to Douglas for his help on making
this happen.

Cheers,
Mauro.


I'm primarily a lurker on this list, generally content to wait for v4l driver 
updates until they appear in the Fedora 12 and Ubuntu 9.10 updates.

However, I also keep a v4l source tree around that I update and build whenever 
any significant changes occur that affect my HVR-950Q, so I can provide rapid 
feedback to the developers.  My process is to update my local tree, build the 
drivers. build the package, install the package, test it, then either revert 
immediately if there are problems (after posting to the list), or update again 
when the changes appear in the Fedora repositories.

Am I correct to believe my process will not be affected by the shift to git?  
That is, will existing kernels will still have access to the current v4l code 
via hg?

I also hope to one day start working on an unsupported USB tuner I have laying 
around (should be simple, but after nearly a year I still haven't gotten to 
it).  Will I be permitted to do my development, and contribute changes, using 
hg and the current Fedora kernel?

Lurker testers and wannabe developers need to know!

-BobC
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [ANNOUNCE] git tree repositories

2010-01-19 Thread Johannes Stezenbach
Hi,

may I humbly request to make it mandatory to enter a description
when a user creates a new tree on linuxtv.org?
IMHO foobar development repository isn't useful at all.

If I look at http://linuxtv.org/hg/ many times I have no
clue what a repo is about or why it exists at all.
Let's not repeat the same mistake with git.

OTOH, since with git it is common to have multiple branches
within one repository, I'm not sure how it works. It would
be cool if git would support per-branch descriptions,
and git web could display them.


Johannes
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [ANNOUNCE] git tree repositories

2010-01-19 Thread hermann pitton
Hi Bob,

Am Dienstag, den 19.01.2010, 13:21 -0800 schrieb Bob Cunningham:
 On 01/19/2010 04:16 AM, Mauro Carvalho Chehab wrote:
  Devin Heitmueller wrote:
  Hello Mauro,
 
  I find it somewhat unfortunate that this is labeled ANNOUNCE instead
  of RFC.  It shows how little you care about soliciting the opinions
  of the other developers.  Rather than making a proposal for how the
  process can be improved and soliciting feedback, you have chosen to
  decide for all of us what the best approach is and how all of us will
  develop in the future.
 
  The announcement by purpose doesn't contain any changes on the process,
  since it requires some discussions before we go there. It is just the
  first step, where -git tree support were created. It also announces
  that I personally won't keep maintaining -hg, delegating its task
  to Douglas.
 
  The point I'm trying to make is that we need to be having a discussion
  about what we are optimizing for, and what are the costs to other
  developers.  This is why I'm perhaps a bit pissed to see an
  announcement declaring how development will be done in the future as
  opposed to a discussion of what we could be doing and what are the
  trade-offs.
 
  I fully understand that supporting the development and tests with an
  out of tree building is important to everybody. So, the plans are
  to keep the out-of-tree building system maintained, and even
  improving it. I'd like to thank to Douglas for his help on making
  this happen.
 
  Cheers,
  Mauro.
 
 I'm primarily a lurker on this list, generally content to wait for v4l driver 
 updates until they appear in the Fedora 12 and Ubuntu 9.10 updates.
 
 However, I also keep a v4l source tree around that I update and build 
 whenever any significant changes occur that affect my HVR-950Q, so I can 
 provide rapid feedback to the developers.  My process is to update my local 
 tree, build the drivers. build the package, install the package, test it, 
 then either revert immediately if there are problems (after posting to the 
 list), or update again when the changes appear in the Fedora repositories.
 
 Am I correct to believe my process will not be affected by the shift to git?  
 That is, will existing kernels will still have access to the current v4l code 
 via hg?
 
 I also hope to one day start working on an unsupported USB tuner I have 
 laying around (should be simple, but after nearly a year I still haven't 
 gotten to it).  Will I be permitted to do my development, and contribute 
 changes, using hg and the current Fedora kernel?
 
 Lurker testers and wannabe developers need to know!
 
 -BobC

if you look at the history of v4l, you can be sure that we always tried
to have as much testers as possible.

During the 2.5.x development cycle, in fact all testing and development
was done on 2.4.x. We did not even have any SCM that time, but on 2.5.x
problems Devin is pointing to were enormous.

Mike Krufky and Mauro were always strong in defending backward compat,
also after taking over Gerd's cvs he later had.

Mauro, in the beginning, even always tried to keep usability back to
2.4.x kernels with v4l2 revision 1 and I did warn him, that this task is
quite impossible to satisfy, but we had developers on totally outdated
semi proprietary stuff, years in delay, asking exactly for that.

On latest discussions, how far we should keep backward compat after i2c
improvements, you saw Mauro again voting for as far as ever possible.

Be sure, we don't want to lose you guys!

Cheers,
Hermann




--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] V4L/DVB: [Mantis] remove duplicated #include

2010-01-19 Thread Huang Weiyi
Remove duplicated #include('s) in
  drivers/media/dvb/mantis/mantis_hif.c
  drivers/media/dvb/mantis/mantis_pci.c

Signed-off-by: Huang Weiyi weiyi.hu...@gmail.com
---
 drivers/media/dvb/mantis/mantis_hif.c |2 --
 drivers/media/dvb/mantis/mantis_pci.c |5 -
 2 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/drivers/media/dvb/mantis/mantis_hif.c 
b/drivers/media/dvb/mantis/mantis_hif.c
index 7477dac..5772ebb 100644
--- a/drivers/media/dvb/mantis/mantis_hif.c
+++ b/drivers/media/dvb/mantis/mantis_hif.c
@@ -22,8 +22,6 @@
 #include linux/signal.h
 #include linux/sched.h
 
-#include linux/signal.h
-#include linux/sched.h
 #include linux/interrupt.h
 
 #include dmxdev.h
diff --git a/drivers/media/dvb/mantis/mantis_pci.c 
b/drivers/media/dvb/mantis/mantis_pci.c
index 6c7534a..59feeb8 100644
--- a/drivers/media/dvb/mantis/mantis_pci.c
+++ b/drivers/media/dvb/mantis/mantis_pci.c
@@ -41,11 +41,6 @@
 #include dvb_frontend.h
 #include dvb_net.h
 
-#include asm/irq.h
-#include linux/signal.h
-#include linux/sched.h
-#include linux/interrupt.h
-
 #include mantis_common.h
 #include mantis_reg.h
 #include mantis_pci.h
-- 
1.6.1.3

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [ANNOUNCE] git tree repositories

2010-01-19 Thread Andy Walls
On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote:

 BTW: I just made a clone of the git-tree - 365MB *ouff*.

Assuming 53.333 kbps download speed, 0% overhead, no compression:

365 MiB * 2^20 bytes/MiB * 8 bits/byte / 5 bits/sec / 3600 sec/hr =
15.95 hours

:(

Can git resume aborted clones?  It could be many weeks before I have a
20 hour window where I don't have to use my land line phone for voice...

Regards,
Andy

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/2, RFC] gspca: add input support for interrupt endpoints

2010-01-19 Thread Hans de Goede

Hi,

Looks good to me now.

Regards,

Hans

On 01/18/2010 09:01 PM, Németh Márton wrote:

From: Márton Némethnm...@freemail.hu

Add support functions for interrupt endpoint based input handling.

Signed-off-by: Márton Némethnm...@freemail.hu
---
diff -r 875c200a19dc linux/drivers/media/video/gspca/gspca.c
--- a/linux/drivers/media/video/gspca/gspca.c   Sun Jan 17 07:58:51 2010 +0100
+++ b/linux/drivers/media/video/gspca/gspca.c   Mon Jan 18 20:43:55 2010 +0100
@@ -3,6 +3,9 @@
   *
   * Copyright (C) 2008-2009 Jean-Francois Moine (http://moinejf.free.fr)
   *
+ * Camera button input handling by Márton Németh
+ * Copyright (C) 2009-2010 Márton Némethnm...@freemail.hu
+ *
   * This program is free software; you can redistribute it and/or modify it
   * under the terms of the GNU General Public License as published by the
   * Free Software Foundation; either version 2 of the License, or (at your
@@ -41,6 +44,9 @@

  #include gspca.h

+#includelinux/input.h
+#includelinux/usb/input.h
+
  /* global values */
  #define DEF_NURBS 3   /* default number of URBs */
  #if DEF_NURBS  MAX_NURBS
@@ -112,6 +118,186 @@
.close  = gspca_vm_close,
  };

+/*
+ * Input and interrupt endpoint handling functions
+ */
+#ifdef CONFIG_INPUT
+#if LINUX_VERSION_CODE  KERNEL_VERSION(2, 6, 19)
+static void int_irq(struct urb *urb, struct pt_regs *regs)
+#else
+static void int_irq(struct urb *urb)
+#endif
+{
+   struct gspca_dev *gspca_dev = (struct gspca_dev *) urb-context;
+   int ret;
+
+   ret = urb-status;
+   switch (ret) {
+   case 0:
+   if (gspca_dev-sd_desc-int_pkt_scan(gspca_dev,
+   urb-transfer_buffer, urb-actual_length)  0) {
+   PDEBUG(D_ERR, Unknown packet received);
+   }
+   break;
+
+   case -ENOENT:
+   case -ECONNRESET:
+   case -ENODEV:
+   case -ESHUTDOWN:
+   /* Stop is requested either by software or hardware is gone,
+* keep the ret value non-zero and don't resubmit later.
+*/
+   break;
+
+   default:
+   PDEBUG(D_ERR, URB error %i, resubmitting, urb-status);
+   urb-status = 0;
+   ret = 0;
+   }
+
+   if (ret == 0) {
+   ret = usb_submit_urb(urb, GFP_ATOMIC);
+   if (ret  0)
+   PDEBUG(D_ERR, Resubmit URB failed with error %i, ret);
+   }
+}
+
+static int gspca_input_connect(struct gspca_dev *dev)
+{
+   struct input_dev *input_dev;
+   int err = 0;
+
+   dev-input_dev = NULL;
+   if (dev-sd_desc-int_pkt_scan)  {
+   input_dev = input_allocate_device();
+   if (!input_dev)
+   return -ENOMEM;
+
+   usb_make_path(dev-dev, dev-phys, sizeof(dev-phys));
+   strlcat(dev-phys, /input0, sizeof(dev-phys));
+
+   input_dev-name = dev-sd_desc-name;
+   input_dev-phys = dev-phys;
+
+   usb_to_input_id(dev-dev,input_dev-id);
+
+   input_dev-evbit[0] = BIT_MASK(EV_KEY);
+   input_dev-keybit[BIT_WORD(KEY_CAMERA)] = BIT_MASK(KEY_CAMERA);
+   input_dev-dev.parent =dev-dev-dev;
+
+   err = input_register_device(input_dev);
+   if (err) {
+   PDEBUG(D_ERR, Input device registration failed 
+   with error %i, err);
+   input_dev-dev.parent = NULL;
+   input_free_device(input_dev);
+   } else {
+   dev-input_dev = input_dev;
+   }
+   } else
+   err = -EINVAL;
+
+   return err;
+}
+
+static int alloc_and_submit_int_urb(struct gspca_dev *gspca_dev,
+ struct usb_endpoint_descriptor *ep)
+{
+   unsigned int buffer_len;
+   int interval;
+   struct urb *urb;
+   struct usb_device *dev;
+   void *buffer = NULL;
+   int ret = -EINVAL;
+
+   buffer_len = ep-wMaxPacketSize;
+   interval = ep-bInterval;
+   PDEBUG(D_PROBE, found int in endpoint: 0x%x, 
+   buffer_len=%u, interval=%u,
+   ep-bEndpointAddress, buffer_len, interval);
+
+   dev = gspca_dev-dev;
+
+   urb = usb_alloc_urb(0, GFP_KERNEL);
+   if (!urb) {
+   ret = -ENOMEM;
+   goto error;
+   }
+
+   buffer = usb_buffer_alloc(dev, ep-wMaxPacketSize,
+   GFP_KERNEL,urb-transfer_dma);
+   if (!buffer) {
+   ret = -ENOMEM;
+   goto error_buffer;
+   }
+   usb_fill_int_urb(urb, dev,
+   usb_rcvintpipe(dev, ep-bEndpointAddress),
+   buffer, buffer_len,
+   int_irq, (void *)gspca_dev, interval);
+   gspca_dev-int_urb = urb;
+   ret = usb_submit_urb(urb, GFP_KERNEL);
+   if (ret  0) {
+   PDEBUG(D_ERR, submit URB failed with error 

[PATCH] cx23885: Wrong command printed in cmd_to_str()

2010-01-19 Thread Roel Kluin
The wrong command was printed for case CX2341X_ENC_SET_DNR_FILTER_MODE,
and a typo in case CX2341X_ENC_SET_PCR_ID.

Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
Or is this intended?

diff --git a/drivers/media/video/cx23885/cx23885-417.c 
b/drivers/media/video/cx23885/cx23885-417.c
index 88c0d24..2ab97ad 100644
--- a/drivers/media/video/cx23885/cx23885-417.c
+++ b/drivers/media/video/cx23885/cx23885-417.c
@@ -681,7 +681,7 @@ static char *cmd_to_str(int cmd)
case CX2341X_ENC_SET_VIDEO_ID:
return  SET_VIDEO_ID;
case CX2341X_ENC_SET_PCR_ID:
-   return  SET_PCR_PID;
+   return  SET_PCR_ID;
case CX2341X_ENC_SET_FRAME_RATE:
return  SET_FRAME_RATE;
case CX2341X_ENC_SET_FRAME_SIZE:
@@ -693,7 +693,7 @@ static char *cmd_to_str(int cmd)
case CX2341X_ENC_SET_ASPECT_RATIO:
return  SET_ASPECT_RATIO;
case CX2341X_ENC_SET_DNR_FILTER_MODE:
-   return  SET_DNR_FILTER_PROPS;
+   return  SET_DNR_FILTER_MODE;
case CX2341X_ENC_SET_DNR_FILTER_PROPS:
return  SET_DNR_FILTER_PROPS;
case CX2341X_ENC_SET_CORING_LEVELS:
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [ANNOUNCE] git tree repositories

2010-01-19 Thread hermann pitton

Am Dienstag, den 19.01.2010, 18:38 -0500 schrieb Andy Walls: 
 On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote:
 
  BTW: I just made a clone of the git-tree - 365MB *ouff*.
 
 Assuming 53.333 kbps download speed, 0% overhead, no compression:
 
 365 MiB * 2^20 bytes/MiB * 8 bits/byte / 5 bits/sec / 3600 sec/hr =
 15.95 hours
 
 :(
 
 Can git resume aborted clones?  It could be many weeks before I have a
 20 hour window where I don't have to use my land line phone for voice...
 
 Regards,
 Andy
 


Hi Andy,

:) please take it only as that.

What about assuming a 1800 kbps low level flat rate and all phone calls
for free, except for some exotic ;) mobile net providers, for the
whole family, including a mobile flat, 4 different phone numbers, video
on demand, and much more you don't need, for 30€ per months?

It is always said, we are so much in delay with such here, but seeing
the above calculation, it is ten years back paying for nothing the
triple money and wait for a day. And preferably the phone of course is
blocked during that.

You are living in the USA? Seems sending CDs per express air mail is
much cheaper ..., even using Brazil as a relay ;)

Are you sure, you did not miss to update your provider ten years back
the first time?

We have local traffic since years, leaving Germany in the north, coming
in over there through Canada, crossing the whole States, and coming back
from Florida to arrive a few miles away from me, just because of unused
backbones. Also VOIP calls are quite fine these days, but local
thunderstorms in between are still often a disaster for hours in summer.

Taking the smileys out now, in fact distributions have Gigas of updates
within a few weeks these days. Andy for sure has an argument.


Cheers,
Hermann






--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] mxl5005s: bad checks of state-Mode

2010-01-19 Thread Roel Kluin
Regardless of the state-Mode in both cases the same value was
written.
If state-Mode wasn't set, it is always 0.

Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
 drivers/media/common/tuners/mxl5005s.c |7 +++
 1 files changed, 3 insertions(+), 4 deletions(-)

Or were the ones and zeroes in these MXL_ControlWrite in the wrong place?

diff --git a/drivers/media/common/tuners/mxl5005s.c 
b/drivers/media/common/tuners/mxl5005s.c
index 605e28b..3967412 100644
--- a/drivers/media/common/tuners/mxl5005s.c
+++ b/drivers/media/common/tuners/mxl5005s.c
@@ -1815,9 +1815,8 @@ static u16 MXL_BlockInit(struct dvb_frontend *fe)
 
/* Charge Pump Control Dig  Ana */
status += MXL_ControlWrite(fe, RFSYN_CHP_GAIN, state-Mode ? 5 : 8);
-   status += MXL_ControlWrite(fe,
-   RFSYN_EN_CHP_HIGAIN, state-Mode ? 1 : 1);
-   status += MXL_ControlWrite(fe, EN_CHP_LIN_B, state-Mode ? 0 : 0);
+   status += MXL_ControlWrite(fe, RFSYN_EN_CHP_HIGAIN, 1);
+   status += MXL_ControlWrite(fe, EN_CHP_LIN_B, 0);
 
/* AGC TOP Control */
if (state-AGC_Mode == 0) /* Dual AGC */ {
@@ -2161,7 +2160,7 @@ static u16 MXL_IFSynthInit(struct dvb_frontend *fe)
}
}
 
-   if (state-Mode || (state-Mode == 0  state-IF_Mode == 0)) {
+   if (state-Mode || state-IF_Mode == 0) {
if (state-IF_LO == 5700UL) {
status += MXL_ControlWrite(fe, IF_DIVVAL,   0x10);
status += MXL_ControlWrite(fe, IF_VCO_BIAS, 0x08);
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] mxl5005s: bad checks of state-Mode

2010-01-19 Thread Devin Heitmueller
On Tue, Jan 19, 2010 at 9:20 PM, Roel Kluin roel.kl...@gmail.com wrote:
 Regardless of the state-Mode in both cases the same value was
 written.
 If state-Mode wasn't set, it is always 0.

 Signed-off-by: Roel Kluin roel.kl...@gmail.com
 ---
  drivers/media/common/tuners/mxl5005s.c |    7 +++
  1 files changed, 3 insertions(+), 4 deletions(-)

 Or were the ones and zeroes in these MXL_ControlWrite in the wrong place?

 diff --git a/drivers/media/common/tuners/mxl5005s.c 
 b/drivers/media/common/tuners/mxl5005s.c
 index 605e28b..3967412 100644
 --- a/drivers/media/common/tuners/mxl5005s.c
 +++ b/drivers/media/common/tuners/mxl5005s.c
 @@ -1815,9 +1815,8 @@ static u16 MXL_BlockInit(struct dvb_frontend *fe)

        /* Charge Pump Control Dig  Ana */
        status += MXL_ControlWrite(fe, RFSYN_CHP_GAIN, state-Mode ? 5 : 8);
 -       status += MXL_ControlWrite(fe,
 -               RFSYN_EN_CHP_HIGAIN, state-Mode ? 1 : 1);
 -       status += MXL_ControlWrite(fe, EN_CHP_LIN_B, state-Mode ? 0 : 0);
 +       status += MXL_ControlWrite(fe, RFSYN_EN_CHP_HIGAIN, 1);
 +       status += MXL_ControlWrite(fe, EN_CHP_LIN_B, 0);

        /* AGC TOP Control */
        if (state-AGC_Mode == 0) /* Dual AGC */ {
 @@ -2161,7 +2160,7 @@ static u16 MXL_IFSynthInit(struct dvb_frontend *fe)
                }
        }

 -       if (state-Mode || (state-Mode == 0  state-IF_Mode == 0)) {
 +       if (state-Mode || state-IF_Mode == 0) {
                if (state-IF_LO == 5700UL) {
                        status += MXL_ControlWrite(fe, IF_DIVVAL,   0x10);
                        status += MXL_ControlWrite(fe, IF_VCO_BIAS, 0x08);

Roel,

Thanks for pointing this out.

This patch should not be applied.

While I agree with Roel's assessment that the logic is incorrect,
removing the conditional logic and forcing the register writes to the
given value is almost certainly the incorrect fix.  I will have to
look at the datasheet and see what the logic is actually supposed to
be.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [ANNOUNCE] git tree repositories

2010-01-19 Thread Mauro Carvalho Chehab
Andy Walls wrote:
 On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote:
 
 BTW: I just made a clone of the git-tree - 365MB *ouff*.
 
 Assuming 53.333 kbps download speed, 0% overhead, no compression:
 
 365 MiB * 2^20 bytes/MiB * 8 bits/byte / 5 bits/sec / 3600 sec/hr =
 15.95 hours

It is an one time download, since, once you got it, the updates are cheap.

Btw, it is a way small than a single CD needed for you to install Linux.

If you want to get it and you're not willing to pay to a decent Internet
connection, just ask someone to get it for you and save on a CD.

Of course you can also keep using -hg.

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [ANNOUNCE] git tree repositories

2010-01-19 Thread Andy Walls
On Wed, 2010-01-20 at 02:10 +0100, hermann pitton wrote:
 Am Dienstag, den 19.01.2010, 18:38 -0500 schrieb Andy Walls: 
  On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote:
  
   BTW: I just made a clone of the git-tree - 365MB *ouff*.
  
  Assuming 53.333 kbps download speed, 0% overhead, no compression:
  
  365 MiB * 2^20 bytes/MiB * 8 bits/byte / 5 bits/sec / 3600 sec/hr =
  15.95 hours
  
  :(
  
  Can git resume aborted clones?  It could be many weeks before I have a
  20 hour window where I don't have to use my land line phone for voice...
  
  Regards,
  Andy
  
 
 
 Hi Andy,
 
 :) please take it only as that.


:)

 What about assuming a 1800 kbps low level flat rate and all phone calls
 for free, except for some exotic ;) mobile net providers, for the
 whole family, including a mobile flat, 4 different phone numbers, video
 on demand, and much more you don't need, for 30€ per months?
 
 It is always said, we are so much in delay with such here, but seeing
 the above calculation, it is ten years back paying for nothing the
 triple money and wait for a day. And preferably the phone of course is
 blocked during that.

Yes, I realize I am in the dark ages.

I haven't been able to build a cost case for my normal home
communications needs to pay for Cable or Satellite internet service.  I
really dislike monthly recurring household costs for services that bill
me whether I use them or not, like communications.  I try to pay only
for plans that meet my common usage needs and no more.

My oldest child is to the point where she will need to start using the
internet for research for school next year.  I'll have to open my wallet
soon, as my household communications needs are growing.


 You are living in the USA? Seems sending CDs per express air mail is
 much cheaper ..., even using Brazil as a relay ;)

You beat me to that joke.  Although I was going to say New Zealand...


 Are you sure, you did not miss to update your provider ten years back
 the first time?

I live in a very rural area:  No fiber optic, no DSL, EV-DO requires
directional antenna and amplifier.

Cable TV  internet is available, but is unreliable and expensive.
Satellite internet is available, of course.


Regards,
Andy

 Taking the smileys out now, in fact distributions have Gigas of updates
 within a few weeks these days. Andy for sure has an argument.
 
 
 Cheers,
 Hermann


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [ANNOUNCE] git tree repositories

2010-01-19 Thread Andy Walls
On Wed, 2010-01-20 at 01:29 -0200, Mauro Carvalho Chehab wrote: 
 Andy Walls wrote:
  On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote:
  
  BTW: I just made a clone of the git-tree - 365MB *ouff*.
  
  Assuming 53.333 kbps download speed, 0% overhead, no compression:
  
  365 MiB * 2^20 bytes/MiB * 8 bits/byte / 5 bits/sec / 3600 sec/hr =
  15.95 hours
 
 It is an one time download, since, once you got it, the updates are cheap.
 
 Btw, it is a way small than a single CD needed for you to install Linux.
 
 If you want to get it and you're not willing to pay to a decent Internet
 connection,

If only I could pay for a *decent* one.

If I just want bandwidth at a poor level of service, poor reliability
and high cost, then I'll pay for the local cable TV internet service.

I'm in one of the white areas on the map on page 33 of:

http://www.tccsmd.org/downloads/Broadband%20Final%20Report.pdf

I don't really have options for getting a good value for my dollar on
broadband internet.

(The residential broadband deployment in the US is just terrible IMO.)


 just ask someone to get it for you and save on a CD.

Nah.  Next time I head to the library, I'll just bring a laptop along:
free WiFi.


 Of course you can also keep using -hg.

That was my plan.

Regards,
Andy

 Cheers,
 Mauro

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html