headers
Németh Márton | 1 Feb 2009 10:24
Picon
Favicon

Linux 2.6.28 + Trust 610 LCD PowerC <at> m Zoom, webcam mode?

Hello Jean-Francois,

I have a Trust 610 LCD PowerC <at> m Zoom camera which can operate in webcam mode
also (USB ID=06d6:0031). I tried to use it together with Linux 2.6.28 and with
xawtv-3.95.dfsg.1 and with gqcam 0.9.1. The /dev/video0 appeared, but no usable
picture was visible.

However, I downloaded http://mxhaard.free.fr/spca50x/Download/gspcav1-20071224.tar.gz
and applied the attached patch (which might be incorrect for some aspects).
So I was able to compile the module and both xawtv and gqcam showed the good
picture.

Do you have any idea why the gspcav1 diver is working and the one which is included
in Linux 2.6.28 not?

Here is the output of v4l-info with the patched working gspcav1 driver:
$ v4l-info

### video4linux device info [/dev/video0] ###
general info
    VIDIOCGCAP
        name                    : "Trust 610 LCD PowerC <at> m Zoom"
        type                    : 0x1 [CAPTURE]
        channels                : 1
        audios                  : 0
        maxwidth                : 464
        maxheight               : 480
        minwidth                : 176
        minheight               : 144
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jean-Francois Moine | 1 Feb 2009 15:24
Picon
Favicon

Re: Linux 2.6.28 + Trust 610 LCD PowerC <at> m Zoom, webcam mode?

On Sun, 01 Feb 2009 10:24:36 +0100
Németh Márton <nm127 <at> freemail.hu> wrote:
> Hello Jean-Francois,

Hello Márton,

> I have a Trust 610 LCD PowerC <at> m Zoom camera which can operate in
> webcam mode also (USB ID=06d6:0031). I tried to use it together with
> Linux 2.6.28 and with xawtv-3.95.dfsg.1 and with gqcam 0.9.1.
> The /dev/video0 appeared, but no usable picture was visible.
> 
> However, I downloaded
> http://mxhaard.free.fr/spca50x/Download/gspcav1-20071224.tar.gz and
	[snip]
> Do you have any idea why the gspcav1 diver is working and the one
> which is included in Linux 2.6.28 not?

The gspcav1 is not maintained anymore.

It seems that your webcam has not been tested with gspcav2.

First, did you use the v4l library and its wrapper when running xawtv
and gqcam?

Then, have you tried my program svv?

If nothing works, please, send me the kernel traces and the image.dat as
indicated in the gspca_README.txt of my page.

Best regards.
(Continue reading)

Permalink | Reply | 2 comments |
headers
D | 1 Feb 2009 18:57
Picon

VIDIOCGMBUF "Invalid argument" (hasciicam on eee, 2.6.27-8-eeepc)

Hi -

I have an asus eee running eeebuntu 8.10, and I'm trying to get
hasciicam [1] to work with the built-in UVC webcam. (All works fine
when using "cheese" to confirm the webcam is working.) The hasciicam
code calls the VIDIOCGMBUF ioctl and that's where it fails. Here's the
code (from hasciicam.c):

  if (ioctl (dev, VIDIOCGMBUF, &grab_map) == -1) {
    perror("!! error in ioctl VIDIOCGMBUF: ");
    return -1;
  }

...where dev is pretty definitely open (we have already successfully
called VIDIOCGCAP and suchlike), and grab_map is a struct of type
video_mbuf as it should be. And here's the result:

  !! error in ioctl VIDIOCGMBUF: Invalid argument

Does this suggest that hasciicam is calling the ioctl incorrectly?
(For example, in [2] it says "a user first sets the desired image size
and depth properties" before calling it, although it doesn't spell out
precisely how that is done.) Or does it mean this particular ioctl is
not available on the given setup?

I'd be grateful for any suggestions.

Thanks
Dan
(Continue reading)

Permalink | Reply | 2 comments |
headers
Laurent Pinchart | 1 Feb 2009 22:27
X-Face
Picon

Re: VIDIOCGMBUF "Invalid argument" (hasciicam on eee, 2.6.27-8-eeepc)

Hi Dan,

On Sunday 01 February 2009, D wrote:
> Hi -
>
> I have an asus eee running eeebuntu 8.10, and I'm trying to get
> hasciicam [1] to work with the built-in UVC webcam. (All works fine
> when using "cheese" to confirm the webcam is working.) The hasciicam
> code calls the VIDIOCGMBUF ioctl and that's where it fails. Here's the
> code (from hasciicam.c):
>
>   if (ioctl (dev, VIDIOCGMBUF, &grab_map) == -1) {
>     perror("!! error in ioctl VIDIOCGMBUF: ");
>     return -1;
>   }
>
> ...where dev is pretty definitely open (we have already successfully
> called VIDIOCGCAP and suchlike), and grab_map is a struct of type
> video_mbuf as it should be. And here's the result:
>
>   !! error in ioctl VIDIOCGMBUF: Invalid argument
>
> Does this suggest that hasciicam is calling the ioctl incorrectly?
> (For example, in [2] it says "a user first sets the desired image size
> and depth properties" before calling it, although it doesn't spell out
> precisely how that is done.) Or does it mean this particular ioctl is
> not available on the given setup?
>
> I'd be grateful for any suggestions.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alexey Klimov | 2 Feb 2009 06:35
Picon

Re: [REVIEW PATCH 13/14] OMAP: CAM: Add DW9710 Lens Driver

Hello, guys

Sorry me, answering to old letter. May i suggest two small points
described below ?

On Mon, 2009-01-12 at 20:03 -0600, Aguirre Rodriguez, Sergio Alberto
wrote:
> This adds the DW9710 Lens driver
> 
> Signed-off-by: Sergio Aguirre <saaguirre <at> ti.com>
> ---
>  drivers/media/video/Kconfig       |    8 +
>  drivers/media/video/Makefile      |    1 +
>  drivers/media/video/dw9710.c      |  548 +++++++++++++++++++++++++++++++++++++
>  drivers/media/video/dw9710_priv.h |   57 ++++
>  include/media/dw9710.h            |   35 +++
>  5 files changed, 649 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/media/video/dw9710.c
>  create mode 100644 drivers/media/video/dw9710_priv.h
>  create mode 100644 include/media/dw9710.h
> 
> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
> index 1616c32..10075c3 100644
> --- a/drivers/media/video/Kconfig
> +++ b/drivers/media/video/Kconfig
>  <at>  <at>  -313,6 +313,14  <at>  <at>  config VIDEO_MT9P012
>           MT9P012 camera.  It is currently working with the TI OMAP3
>           camera controller.
> 
> +config VIDEO_DW9710
(Continue reading)

Permalink | Reply | 0 comments |
headers
Németh Márton | 2 Feb 2009 08:12
Picon
Favicon

Re: Linux 2.6.28 + Trust 610 LCD PowerC <at> m Zoom, webcam mode?

Jean-Francois Moine wrote:
> On Sun, 01 Feb 2009 10:24:36 +0100
> Németh Márton <nm127 <at> freemail.hu> wrote:
>> Hello Jean-Francois,
> 
> Hello Márton,
> 
>> I have a Trust 610 LCD PowerC <at> m Zoom camera which can operate in
>> webcam mode also (USB ID=06d6:0031). I tried to use it together with
>> Linux 2.6.28 and with xawtv-3.95.dfsg.1 and with gqcam 0.9.1.
>> The /dev/video0 appeared, but no usable picture was visible.
>>
>> However, I downloaded
>> http://mxhaard.free.fr/spca50x/Download/gspcav1-20071224.tar.gz and
> 	[snip]
>> Do you have any idea why the gspcav1 diver is working and the one
>> which is included in Linux 2.6.28 not?
> 
> The gspcav1 is not maintained anymore.
> 
> It seems that your webcam has not been tested with gspcav2.

Yes, I found your status at page http://moinejf.free.fr/webcam.html .

> First, did you use the v4l library and its wrapper when running xawtv
> and gqcam?

I don't really know, I just installed the xawtv package coming with Debian.

> Then, have you tried my program svv?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Getcho Getchev | 2 Feb 2009 10:34

PV143N watchdog

Greetings,
I am trying to control the PV143N watchdog via bttv driver under linux  
kernel 2.6.24.3.
According to the specification the watchdog is located at address  
0x56, subaddress 0x01.
However when I try to write something (a value of 0, 1 or 2) on that  
address I get NACK result.
I am using i2c_master_send() function and software bitbanging  
algorithm, implemented in bttv-i2c.c
At the beginning I suspected the SCL line (the clock for the  
communication must be set at 100 KHz) but when I saw the delay time is  
5 microseconds I realized the period is 10 microseconds which makes  
100 KHz. I tried to write the same data on address 0x2B and I  
succeeded (although I do not know what is there on that address) so it  
seems the bitbanging algorithm works fine along with the  
i2c_master_send() function. I suspect there must be some pre- 
conditions which I miss. Maybe some initialization on some other  
address or something else?
Did anyone face that problem?

Thanks in advance.

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request <at> redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Permalink | Reply | 4 comments |
headers
D | 2 Feb 2009 10:34
Picon

Re: VIDIOCGMBUF "Invalid argument" (hasciicam on eee, 2.6.27-8-eeepc)

2009/2/1, Laurent Pinchart <laurent.pinchart <at> skynet.be>:
> The UVC driver doesn't support the deprecated V4L1 API. The v4l1compat.so
>  wrapper might help you, as it translates V4L1 calls to V4L2.

Ah, thanks. Doing this...

LD_PRELOAD=/usr/lib64/libv4l/v4l1compat.so ./hasciicam

...allows hasciicam to get beyond the point I described above, but
then it gets terminated with a message " *** buffer overflow detected
***: ./hasciicam terminated".

It looks like the better way forward would be to move up to the
current API. I've found the V4L2 API reference now. Do you know of any
"transition guides" that might help me update the code?

Thanks,
Dan

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request <at> redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Permalink | Reply | 0 comments |
headers
Matthias Schwarzott | 2 Feb 2009 12:45
Picon
Favicon

Re: PV143N watchdog

On Monday 02 February 2009 10:34, Getcho Getchev wrote:
> Greetings,
> I am trying to control the PV143N watchdog via bttv driver under linux
> kernel 2.6.24.3.
> According to the specification the watchdog is located at address
> 0x56, subaddress 0x01.
> However when I try to write something (a value of 0, 1 or 2) on that
> address I get NACK result.
> I am using i2c_master_send() function and software bitbanging
> algorithm, implemented in bttv-i2c.c
> At the beginning I suspected the SCL line (the clock for the
> communication must be set at 100 KHz) but when I saw the delay time is
> 5 microseconds I realized the period is 10 microseconds which makes
> 100 KHz. I tried to write the same data on address 0x2B and I
> succeeded (although I do not know what is there on that address) so it

That really sounds like a common i2c miss-understanding.
Linux kernel i2c functions use only the 7bit address part of the i2c address.
So it sounds like your device has address 0x56 for writing and 0x57 for 
reading. (is this correct?)
Now you give i2c_master_send or i2c_transfer the 7bit part, 0x56 >> 1, and 
that is 0x2B.

Regards
Matthias

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request <at> redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mauro Carvalho Chehab | 2 Feb 2009 13:08
Favicon

Re: [PATCH] newport: newport_*wait() return 0 on timeout

Hi Roel,

It seems that you've sent this driver to the wrong ML. Video adapters are not handled on those ML's.

On Sat, 31 Jan 2009 16:29:39 +0100
Roel Kluin <roel.kluin <at> gmail.com> wrote:

> With a postfix decrement t reaches -1 on timeout which results in a
> return of 0.
> 
> Signed-off-by: Roel Kluin <roel.kluin <at> gmail.com>
> ---
> diff --git a/include/video/newport.h b/include/video/newport.h
> index 1f5ebea..001b935 100644
> --- a/include/video/newport.h
> +++ b/include/video/newport.h
>  <at>  <at>  -453,7 +453,7  <at>  <at>  static __inline__ int newport_wait(struct newport_regs *regs)
>  {
>  	int t = BUSY_TIMEOUT;
>  
> -	while (t--)
> +	while (--t)
>  		if (!(regs->cset.status & NPORT_STAT_GBUSY))
>  			break;
>  	return !t;
>  <at>  <at>  -463,7 +463,7  <at>  <at>  static __inline__ int newport_bfwait(struct newport_regs *regs)
>  {
>  	int t = BUSY_TIMEOUT;
>  
> -	while (t--)
(Continue reading)

Permalink | Reply | 6 comments |

Gmane