New VINO video drivers for Indy
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.
Hello Mikael,
Quoted 1 line
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 :).
Quoted 2 lines
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.
Quoted 4 lines
Quoted 18 lines · Markus Dahms
Hello Mikael,
Quoted 3 lines
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 :).
Quoted 4 lines
Please test the driver and report the results so that bugs (yes, I can promise there are lots of them :) can be squashed.
Quoted 6 lines
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.
Quoted 8 lines
| 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
Quoted 7 lines
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.
Quoted 6 lines
* (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 theMakefile.
I'm really not an expert with makefiles, but I'll see what I can do...
Quoted 6 lines
Markus
[1] yes, I opened the cover ;). channel was correct, too.
That's good. :)
Quoted 9 lines
Quoted 4 lines
Hello again,
Quoted 8 lines
Quoted 1 line
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
Quoted 16 lines · Markus Dahms
Hello again,
Quoted 11 lines
Quoted 3 lines
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 ?
Quoted 8 lines
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
Quoted 1 line · Mikael Nousiainen
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 ;).
Quoted 4 lines · Markus Dahms
Mikael Nousiainen wrote:
Quoted 8 lines
Quoted 3 lines
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...
Quoted 5 lines
And (it was hard enough to capture) one with some lines on it:
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.
Quoted 10 lines
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.