New VINO video drivers for Indy

New VINO video drivers for Indy

[Mikael Nousiainen]

I've released new drivers for SGI Indy's VINO video input (for 2.6 kernels).

For more information, see the webpage:
http://www.mbnet.fi/~turja/vino/

Please test the driver and report the results so that bugs
(yes, I can promise there are lots of them :) can be squashed.

Re: New VINO video drivers for Indy

[Markus Dahms]

Hello Mikael,

> I've released new drivers for SGI Indy's VINO video input (for 2.6 kernels).

That's what I've already waited for. Slowly 2.6.x should get usable for
SGI machines :).

> Please test the driver and report the results so that bugs
> (yes, I can promise there are lots of them :) can be squashed.

I only get a bla[nc]k image using the patched camsource or xawtv from
from Debian Sarge with my IndyCam[1] :(. With the old driver for
2.4.x I got some more results (striped, but at least an image...).
I hope you could give me some hints where to start debugging...

| SGI VINO driver version 0.0.1
| VINO with chip ID 11, revision 0 found
| Philips SAA7191 driver version 0.0.1
| SAA7191 initialized
| SGI IndyCam driver version 0.0.1
| IndyCam v1.0 detected
| IndyCam initialized

What I noticed, too:

* you should really include a directory in your package, I (most people?)
  did 'cd src/; tar zxvf vino-0.0.1.tar.gz' and screwed up my source
  directory a bit.
* (not so important) I cross-compile all kernel-related stuff. Although
  'make -C $MIPSKERNELDIR SUBDIRS=`pwd`' is not as difficult, there
  COULD be support for cross-compiling in the Makefile.

Markus

[1] yes, I opened the cover ;). channel was correct, too.

> 
> 
> 
> 

Re: New VINO video drivers for Indy

[Mikael Nousiainen]

Markus Dahms wrote:

>Hello Mikael,
>
>  
>
>>I've released new drivers for SGI Indy's VINO video input (for 2.6 kernels).
>>    
>>
>
>That's what I've already waited for. Slowly 2.6.x should get usable for
>SGI machines :).
>
>  
>
>>Please test the driver and report the results so that bugs
>>(yes, I can promise there are lots of them :) can be squashed.
>>    
>>
>
>I only get a bla[nc]k image using the patched camsource or xawtv from
>from Debian Sarge with my IndyCam[1] :(. With the old driver for
>2.4.x I got some more results (striped, but at least an image...).
>I hope you could give me some hints where to start debugging...
>  
>
That's strange. There might be some problems with IndyCam initialization 
(register values),
but usually you should be able to get at least a very dark picture. 
Removing and reinstalling the
module (indycam.ko) reinitializes the camera so you can try that.
IndyCam seems to use some very odd logic to decide how bright the 
picture should be.
Try bringing some very bright light sources near the camera ?

I'm pretty sure the image capture works as it should as I've been doing 
a lot of testing
with IndyCam. Are you sure that the camera is a working one ?

Also note that xawtv isn't really a very usable application to test the 
driver as it doesn't
update listings for video standards and image controls when you change 
the input channel.

>| SGI VINO driver version 0.0.1
>| VINO with chip ID 11, revision 0 found
>| Philips SAA7191 driver version 0.0.1
>| SAA7191 initialized
>| SGI IndyCam driver version 0.0.1
>| IndyCam v1.0 detected
>| IndyCam initialized
>
>What I noticed, too:
>
>* you should really include a directory in your package, I (most people?)
>  did 'cd src/; tar zxvf vino-0.0.1.tar.gz' and screwed up my source
>  directory a bit.
>  
>
Yes, I noticed it was missing and the next release will include one. 
I'll be away (travelling) for
the next 2 weeks so it won't come out sooner than that.

>* (not so important) I cross-compile all kernel-related stuff. Although
>  'make -C $MIPSKERNELDIR SUBDIRS=`pwd`' is not as difficult, there
>  COULD be support for cross-compiling in the Makefile.
>
>  
>
I'm really not an expert with makefiles, but I'll see what I can do...

>Markus
>
>[1] yes, I opened the cover ;). channel was correct, too.
>
>  
>
That's good. :)

>>
>>
>>    
>>
>
>
>
>  
>

Re: New VINO video drivers for Indy

[Markus Dahms]

Hello again,

>> I only get a bla[nc]k image ...
> That's strange. There might be some problems with IndyCam initialization 
> (register values),
> but usually you should be able to get at least a very dark picture.
> Removing and reinstalling the module (indycam.ko) reinitializes the
> camera so you can try that. IndyCam seems to use some very odd logic
> to decide how bright the picture should be.
> Try bringing some very bright light sources near the camera ?

For some reason it's working now. It's not significantly brighter, I
just checked the camera with kernel 2.4.x before booting 2.6.12.
If I can reproduce the failure I'll write it.
The picture has the same "quality" as with the other driver except
there _are_ fewer horizontal lines (they appear mostly on fast-moving
pictures).

Markus

Re: New VINO video drivers for Indy

[Mikael Nousiainen]

Markus Dahms wrote:

>Hello again,
>
>  
>
>>>I only get a bla[nc]k image ...
>>>      
>>>
>>That's strange. There might be some problems with IndyCam initialization 
>>(register values),
>>but usually you should be able to get at least a very dark picture.
>>Removing and reinstalling the module (indycam.ko) reinitializes the
>>camera so you can try that. IndyCam seems to use some very odd logic
>>to decide how bright the picture should be.
>>Try bringing some very bright light sources near the camera ?
>>    
>>
>
>For some reason it's working now. It's not significantly brighter, I
>just checked the camera with kernel 2.4.x before booting 2.6.12.
>If I can reproduce the failure I'll write it.
>The picture has the same "quality" as with the other driver except
>there _are_ fewer horizontal lines (they appear mostly on fast-moving
>pictures).
>  
>
Ok, nice to know that you got it working...

Could you provide a sample image ?

The image is an interlaced image and it's constructed by joining two 
consencutive frames, so that's what
can cause some "distortion" in the image with fast-moving objects.

The horizontal lines I'm talking about don't have anything to do with 
the content of the image,
they just appear and disappear. The black lines always start from the 
left edge of the picture
and it seems that the pixels from the start of the lines get somehow 
moved forwards to the center of the
same line of the image. (eww, this is difficult to explain :)

Mikael

Re: New VINO video drivers for Indy

[Markus Dahms]

Mikael Nousiainen wrote:

> Could you provide a sample image ?

http://automagically.de/images/p_indycam_01.jpg
http://automagically.de/images/p_indycam_02.jpg

And (it was hard enough to capture) one with some lines on it:

http://automagically.de/images/p_indycam_03.jpg

These pictures where taken with daylight, some of the colors are a bit
strange[1] (I'll try it artificial light in the evening).

Markus

[1] the cyan looking highlighter on the first picture should really be
    green ;).

Re: New VINO video drivers for Indy

[Mikael Nousiainen]

Markus Dahms wrote:

>Mikael Nousiainen wrote:
>
>  
>
>>Could you provide a sample image ?
>>    
>>
>
>http://automagically.de/images/p_indycam_01.jpg
>http://automagically.de/images/p_indycam_02.jpg
>  
>
Everything seems to be ok with these...

>And (it was hard enough to capture) one with some lines on it:
>
>http://automagically.de/images/p_indycam_03.jpg
>  
>
The image is fuzzy because the camera has moved just after the first 
field for the image
has been captured, before capturing the second field (every other line).

The two black lines in the center of the image are the real problem as I 
have no
idea what causes them to appear. As you can easily check, the "missing 
content" is found
from the beginning of the same line.

>These pictures where taken with daylight, some of the colors are a bit
>strange[1] (I'll try it artificial light in the evening).
>
>Markus
>
>[1] the cyan looking highlighter on the first picture should really be
>    green ;).
>
>  
>
Yep, I've noticed same kind of behaviour with my indycam as it does not 
reproduce
blue colors correctly (blue is very weak always).
I've also heard that the camera is designed to be used in fluorescent 
light so
problems with colors seem to be a nice "feature" of the camera... :)

Thanks for the samples.

>
>
>  
>