I have finished doing the following:-
Seperate 627b start-stream into bridge & sensor functions
- Adds functions to control OV7660 series Image Sensors
- Adds functions to initialize Sn9C20x series micro-controllers/bridges
Signed-off-by: Neekhil <Nickel...@Gmail.com>
All users please help test this patch.
apply this patch via git am like below, (get a copy of driver source &
copy the patch in the same directory)
$ git am ./0004-Seperate-627b-start-stream-into-bridge-sensor-func.patch
Note: this applies cleanly on top of commit
c68ab53ff8f2c5e3969731fd7e3b1e6b6fe235bd
We can now start using the same base Bridge(SN9C20x) sequences,
and let only model specific sequences remain in the various init/start streams.
Brightness/contrast/exposure on 627b
The default settings aren't correct in natural & artificial lighting,
hence you need to test it with the following software
Universal control panel for v4l2 devices (As suggested by Brian)
get your binary packages here,
http://www.debian-multimedia.org/dists/stable/main/binary-i386/package/v4l2ucp.php
or here,
http://www.debian-multimedia.org/dists/stable/main/binary-amd64/package/v4l2ucp.php
launch this software by executing the following command $ v4l2ucp
With this GUI software you can adjust the picture quality without
mucking around with the command line/debugfs !
I also request developers (who own NON 627b webcams) to test if this
patch breaks their webcams's
if not, please confirm & go ahead and push this patch to main repo. So
that I can finish the checkpatch cleanup that I started earlier on top
of this commit.
Brian, can you suggest what to do to support resolution switching
scaling patch you posted earlier on top of this reduces start stream
sequence.
Neekhil
checking for Qt... yes:
QT_CXXFLAGS=-I/usr/lib64/qt-3.3/include -DQT_THREAD_SUPPORT
QT_DIR=/usr/lib64/qt-3.3
QT_LIBS=-L/usr/lib64/qt-3.3/lib -lqt-mt -lSM -lICE -L/usr/lib64
-lX11 -lXext -lXmu -lXt -lXi
QT_UIC=/usr/lib64/qt-3.3/bin/uic
QT_MOC=/usr/lib64/qt-3.3/bin/moc
checking correct functioning of Qt installation... failure
configure: error: Failed to find matching components of a complete
Qt installation. Try using more options,
see ./configure --help.
If anybody knows which part of QT is missing I could probably solve it
but I really don't understand what problem it has.
GWater
GWater
GWater
and ofcourse, I used alien to convert this simple package *.deb to *.rpm ;-)
-JoJo
Hello,
With this patch, I have now no image on my 627b webcam.
gqcam said :
Sometimes a white picture is shown without errors.
And other times a black picture and these messages :
grab_image: incorrect input_type 135691536
Error reading image...
Without this patch I had an image, very bad but an image.
Note that with or without this patch my webcam does not work under mplayer
with a green image and the errors :
microdia: isoc_init() submit_urb 194 failed with error -27
--
Alain rpnpif
I believe the cause of this issue could be,
a) recent commit to head (but both of you said, latest head works fine ?)
b) both the failure reports of 0c45:627b are in embeded webcams, Mine
is standalone webcam, USB 2.0
so its very possible that the bare minimum that works for me, will
require some more writes to work for your embeded ones,
c) one of the failure reports seems to be with USB 1.1 (not enough
info to rule it out)
Possibly we can try a mix of mine & Brian's bridge writes to see if it
gets initialized properly
Neekhil
with standalone webcam you can un-plug & replug the device, with embeded
we cannot do that, so its possible that the "reset all bridge registers" command
was not part of this patch.
-JoJo
few of the register writes had failed, & I got the green screen as
another poster mentioned
so i re-ran the init sequence
index 7ed058c..333d4d0 100644
--- a/microdia-dev.c
+++ b/microdia-dev.c
@@ -5058,6 +5058,7 @@ int microdia_627b_start_stream(struct usb_microdia *dev)
int sn9c20x_initialize(struct usb_microdia *dev);
ret = sn9c20x_initialize(dev);
+ ret = sn9c20x_initialize(dev);
if (dev->sensor_init)
dev->sensor_init(dev);
this time no error in register writes, & I get dark video in 1st try !
some issues noticed
/* Get green diagonal bands w/o this dummy write, Bridge does not know
sensor address ? */
reg = 0x10c0;
buf[0] = 0x80; buf[1] = 0x21; buf[2] = 0x00; buf[3] = 0x00;
buf[4] = 0x00; buf[5] = 0x00; buf[6] = 0x00; buf[7] = 0x00;
buf[8] = 0x03;
ret = usb_microdia_control_write(dev, reg, buf, 9);
if (ret < 0)
goto err;
that comment / what it implies seems wrong, else we'll need to make it
a paramater
may be someone can tell us whether what the comments tell us about
these register's purpose is true or not ?
can we replace the above with a call to sn9c20x_initialize_i2c()
instead ? since 9th byte doesn't matter.
-JoJo
Hello,
I have just installing an USB2 card on my system and the behaviour of the
webcam is very different (with MS Windows, this webcam works also under
USB1.1).
No change on the image with mplayer but error messages are now :
mplayer tv:// -tv
noaudio:driver=v4l2:width=640:height=480:outfmt=yuy2:device=/dev/video1:fps=30
...
Playing tv://.
TV file format detected.
Selected driver: v4l2
name: Video 4 Linux 2 input
author: Martin Olschewski <olsch...@zpr.uni-koeln.de>
comment: first try, more to come ;-)
Selected device: Microdia USB Video Camera
Capabilites: video capture read/write streaming
supported norms:
inputs: 0 = Webcam;v4l2: ioctl get input failed: Invalid argument
Current input: 1
Current format: YUV420
v4l2: ioctl set format failed: Invalid argument
v4l2: ioctl enum norm failed: Invalid argument
Error: Cannot set norm!
Selected input hasn't got a tuner!
v4l2: ioctl set mute failed: Invalid argument
v4l2: ioctl query control failed: Invalid argument
v4l2: ioctl query control failed: Invalid argument
==========================================================================
Opening video decoder: [raw] RAW Uncompressed Video
VDec: vo config request - 640 x 480 (preferred colorspace: Planar I420)
VDec: using Planar I420 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
VO: [xv] 640x480 => 640x480 Planar I420 [zoom]
Selected video codec: [rawi420] vfm: raw (RAW I420)
==========================================================================
Audio: no sound
Starting playback...
v4l2: ioctl dequeue buffer failed: Invalid argument, idx = 0
v4l2: ioctl query buffer failed: Invalid argument, idx = 0
Exception floating point,?% 0 0
With gqcam, the things are very different.
Without this patch and USB1.1, the image was partially drawn. Now with USB2
the image is complete and stable, but too bright or too white. Setting light
or contrast has not effect.
With the patch and USB1.1, no image was avaliable.
With the patch and USB2, yes ! For the first time the image is fine !!!...
but...
But a flicking appears at a frequency about 1.5Hz (about all the 0.7 seconds).
With ekiga, no image but magenta lines in diagonals are on a white background.
With kopete, the image is running quickly from rigth to left.
So good progress.
--
Alain rpnpif
Hi Alain
Wow, so finally a success report with this patch !
But we are so disappointed ;-0
So common' make a screenshot/video or two,
Dim the lights, take off your shirt, put on some soul music
dance a little, for inspiration look here ;-)
https://microdia.googlegroups.com/web/JwmCapture.avi
OK I believe the issue is that the current SN9C20x init functions work
correctly for descrete webcams[1]
integrated webcams will require tweaking (all register reset)
> But a flicking appears at a frequency about 1.5Hz (about all the 0.7 seconds).
This is the auto exposure/white balance etc fighting each other.
-JoJo
[1] descrete webcams : seperate from computer can be plugges in/out of
a USB port
You made me remember my old friend sn9c20x_initialize_i2c(). This
function is only used in one startstream and we have no prove it is
indeed a general sn9c20x feature and not some special treatment for a
specific sensor. I really want it improved or removed since it will
always cause misunderstandings.
GWater
For the separation of the 7660 code I think it would be somewhat
easier to read if you wrote the initialization routine using a two
dimensional array of register writes like i use in my 965x init. It
would also allow us to use a single sensor init function that just
uses the proper nit sequence as well.
I also think that most of the register writes currently being used for
the start_stream functions would be better off being done within the
initialized function, abut all we really need to do for start stream
is maybe switch on the camera's LED and start the stream.
Removed both sets of register writes.
> For the separation of the 7660 code I think it would be somewhat
> easier to read if you wrote the initialization routine using a two
> dimensional array of register writes like i use in my 965x init. It
> would also allow us to use a single sensor init function that just
> uses the proper nit sequence as well.
>
done and done.
> I also think that most of the register writes currently being used for
> the start_stream functions would be better off being done within the
> initialized function, abut all we really need to do for start stream
> is maybe switch on the camera's LED and start the stream.
>
start_stream functions are executed whenever an app requests a stream
initialized function are executed only if the device is
connected/reconnected or driver is loaded/reloaded
so Mplayer/ekiga/skype won't work after the first time(w/o
reconnecting/reloading the webcam/driver)
so this approach is not very attractive, unless I misunderstood your suggestion.
Plus there shouldn't be any need to do so, as I have removed the
conflicting 10fb-10ff & 1189 writes.
Neekhil
I like the detailed feedback, let me know after testing the latest
driver source if these issues still persist.
Neekhil
On Mon, Aug 25, 2008 at 9:44 PM, Tomasz Torcz <zdz...@gmail.com> wrote:
> Doesn't work for me (Thinkpad z61t) :(
> Without the patch I have good picture with mplayer and
> distorted with Cheese.
> With path I got only green screen in mplayer and cheese doesn't
> show anything except gnome foot (aka spinner).
>
>
>