Microsoft webcam vx-6000
Bilbo75
I would like to know if the Microsoft VX-6000 can work with this
driver.
I've found many posts in Ubuntu's forums talking about a driver
SN9CXXX (the closed source one) working with this camera.
Could you give me some info please?
I've tried to hack manually (I'm not a programmer) the product and the
vendor id ,but without results.
Kopete ,amsn and Skype hang :(
If you need more details I'll be glad to help you :)
Thanks for your time.
JoJo jojo
Hi Bilbo
You need to tell us about your webcam, we need this info
https://groups.google.com/group/microdia/web/howto-get-information-on-your-webcam
-JoJo
Bilbo75
vendor id: 045e
product id : 00f4
Bridge : SN9C201
Image Sensor : OV9650
I've upped the usb descriptors (045e_00f4_device_descriptors.txt) in
the file section.
I can't find any datasheet for the image sensor sorry. :(
Thanks again for your help.You are doing a great job.
Ciao :)
On 20 Apr, 20:48, "JoJo jojo" <onetwoj...@gmail.com> wrote:
>
> > Hi ,I'm new into this group.Your work is awesome guys !
> > I've found many posts in Ubuntu's forums talking about a driver
> > SN9CXXX (the closed source one) working with this camera.
> > Could you give me some info please?
> > I've tried to hack manually (I'm not a programmer) the product and the
> > vendor id ,but without results.
> > Kopete ,amsn and Skype hang :(
> > If you need more details I'll be glad to help you :)
> > Thanks for your time.
>
> Hi Bilbo
>
>
> -JoJo
JoJo jojo
>
> Ok here it is the informations you asked:
>
> vendor id: 045e
> product id : 00f4
>
> Bridge : SN9C201
> Image Sensor : OV9650
>
> I've upped the usb descriptors (045e_00f4_device_descriptors.txt) in
> the file section.
>
> I can't find any datasheet for the image sensor sorry. :(
>
> Thanks again for your help.You are doing a great job.
> Ciao :)
>
Hi Bilbo
seems like your webcam is the same as 0c45:624f,
please try the init/start/stop sequences of 0c45:624f,
in order to make it work on 045e:00f4.
-JoJo
Bilbo75
On amsn I see a good image,BUT the colors look swapped (some rgb
sequence issue?)
On kopete(kde 3.5.8 Slackware12 ) the image is scrambled ,like a large
image wrapped many times
Anyway it's a good start point :) thanks.
On 25 Apr, 03:21, "JoJo jojo" <onetwoj...@gmail.com> wrote:
Bilbo75
Ciao!
JoJo jojo
What does that even mean?,
is 045e:00f4 working correctly ?
In which application its not working correctly ?
(post screenshot whereever applicable.)
-JoJo
Bilbo75
amsn :
http://img161.imageshack.us/my.php?image=amsnvd9.png
kopete:
http://img137.imageshack.us/my.php?image=kopeteoy8.png
Gyachi: doesn't work (lack video4linux2 support)
Skype all ok.
Thanks again! :)
On 25 Apr, 14:05, "JoJo jojo" <onetwoj...@gmail.com> wrote:
> Hi Bilbo,
>
> What does that even mean?,
>
> is 045e:00f4 working correctly ?
> In which application its not working correctly ?
> (post screenshot whereever applicable.)
>
> -JoJo
>
UbuntuUser
have installed and configured the driver but get only this output when
I run dmesg:
[ 189.365215] microdia: Microdia USB2.0 webcam driver startup
[ 189.365322] usbcore: registered new interface driver
usb_microdia_driver
[ 189.365328] microdia: v0.0.0 : Microdia USB Video Camera
The camera is not recognized by the driver, but I can use the webcam
as a microphone in Skype. What are init/start/stop sequences and how
can I find out how to do them? How can I get the camera recognized?
Thanks so much.
On Apr 24, 9:21 pm, "JoJo jojo" <onetwoj...@gmail.com> wrote:
Bilbo75
You will find inside the VendorId e ProductId of the microdia webcams.
You have to modify the VendorId with the code of Microsoft (045E) and
the ProductId of the model 624F with 00F4.
That's all!
Compile it and it will work perfectly!
Ciao!
UbuntuUser
Bilbo75
We have already 2 webcams working fine :)
Thanks so much!
Ciao
JoJo jojo
Well you asked for it, try out the attached patch and let us know.
The ideal way would be to handle it like a normal model,
(but its the same model, why keep different pieces of code, it will
just introduce more bugs)
a penny for your(Devs) thoughts .....
-JoJo
GWater
/**
* ...
comment should include information on bridge and sensor to make an
identification in doxygen possible (I already did this for 624e and
6242). Apart fom that I would not change the function names since it
would only cause confusion. Once we know what the essential startstream
registers mean we can make more general functions which have sensor
specific parts. At least that's my opinion.
GWater
JoJo jojo
patch please ;-)
(or better wait and let them test it out before you commit the patch
with Doxygen, thanks)
-JoJo
Dave Neuer
> Hi Bilbo
>
> Well you asked for it, try out the attached patch and let us know.
>
> The ideal way would be to handle it like a normal model,
> (but its the same model, why keep different pieces of code, it will
> just introduce more bugs)
>
> a penny for your(Devs) thoughts .....
>
> -JoJo
Why not just add the real vendor and product IDs to the big case statement?
case USB_UDIA_624F_PRODUCT_ID:
case USB_UDIA_MICROSOFT_PRODUCT_ID:
.. do init for 624f
break;
Dave
GWater
functions for 624e are sometimes also used for 6242. Maybe both should
be done. :)
GWater
JoJo jojo
OK, I like the switch case
(as is the case with 0c45:62bb, which is 627b again)
..but we will need a seperate switch case for each vendor_id
(example 045e & 145f)
-JoJo
Dave Neuer
We can just put a comment above the relevant functions to accomplish
the former. My main point was, we shouldn't obscure the real vendor
and product IDs.
We'd need to change the UDIA_INFO() at the top of that case block to
take a format string for the vendor & product, too, so people aren't
confused when they look at their dmesg.
Dave
Dave Neuer
>
> Hi Dave
>
> OK, I like the switch case
> (as is the case with 0c45:62bb, which is 627b again)
>
> ..but we will need a seperate switch case for each vendor_id
> (example 045e & 145f)
Why?
Dave
JoJo jojo
Because in switch case
vendor_id == USB_MICRODIA_VENDOR_ID
vendor_id == 045e/145f
so the big switchcase only works for 0c45 ones and not 045e/145f
But I agreee with you in principle, if a webcam says its 045e/145f
then it must be recognized as
045e/145f and not 0c45: 624f/627b
(which is why I added the "Read Vendor/Product ID" to kernel log via UDIA_INFO)
-JoJo
Jerome Lacoste
> vendor_id == USB_MICRODIA_VENDOR_ID
> vendor_id == 045e/145f
> so the big switchcase only works for 0c45 ones and not 045e/145f
BTW, wouldn't it be interesting to replace the big switch case with
some sort of hashtable mapping device ids to an array (or struct) of
function pointers ?
Cheers,
Jerome
Dave Neuer
> vendor_id == USB_MICRODIA_VENDOR_ID
> vendor_id == 045e/145f
> so the big switchcase only works for 0c45 ones and not 045e/145f
if (vendor_id == USB_MICRODIA_VENDOR_ID
|| vendor_id == USB_MICROSOFT_VENDOR_ID)
works, right?
Or even better:
int device_id = le16_to_cpu(udev->descriptor.idVendor) << 16
& le16_to_cpu(udev->descriptor.idProduct);
switch (device_id) {
Then again, perhaps we've reached that magic point in time when it
makes sense to break things out by sensor and bridge?
Furthermore, is it time to change the name of the driver? Clearly, our
driver is more accurately termed the sn9c201 driver than the Microdia
driver (and has the added benefit that it's less likely to get us into
trademark trouble)?
Dave
GWater
cause confusion I would only use another name for releases of the
driver. We could add a note though.
Problem with splitting is for me that I don't have a sensor datasheet
like everybody else seems to have.
GWater
JoJo jojo
>
> On Mon, Apr 28, 2008 at 2:29 PM, JoJo jojo <onetw...@gmail.com> wrote:
> >
> > Hi Dave
> >
>
> > Because in switch case
> > vendor_id == USB_MICRODIA_VENDOR_ID
> > vendor_id == 045e/145f
> > so the big switchcase only works for 0c45 ones and not 045e/145f
>
> if (vendor_id == USB_MICRODIA_VENDOR_ID
> || vendor_id == USB_MICROSOFT_VENDOR_ID)
So we want to change
http://repo.or.cz/w/microdia.git?a=blob;f=microdia-usb.c;h=01d0db128b7ba22ddfc50901b2643caa82599cd1;hb=e32db588aa1782d110b42c7c29178e12be759373#l756
// Detect device
if (vendor_id == USB_MICRODIA_VENDOR_ID) {
switch (product_id) {
case USB_UDIA_6027_PRODUCT_ID:
TO
// Detect device
if ((vendor_id == USB_MICRODIA_VENDOR_ID) || (vendor_id == 0x045e) ||
(vendor_id == 0x145f))
{
switch (product_id) {
case USB_UDIA_6027_PRODUCT_ID:
and add the product_ids again ?
(what if we have exact same product_id under both microdia & microsoft
vendor_ids ?
see !! you haven't thought it through ;-)
>
> works, right?
>
> Or even better:
>
> int device_id = le16_to_cpu(udev->descriptor.idVendor) << 16
> & le16_to_cpu(udev->descriptor.idProduct);
>
> switch (device_id) {
>
soln. is either separate switch, or hack to force it to identify is as
another model.
> Then again, perhaps we've reached that magic point in time when it
> makes sense to break things out by sensor and bridge?
>
Yes Nicolas seems to think so too, his Syntek Driver is very big,
so it has a facility to just build the kernel module for a single
vendor_id: product_id combo.
Syntek has capabilities to build for a single (vendor:product ID).
This helps keep the kernel module size small, which in turn keeps the
kernel memory from
fragmenting, which in turn perhaps gets you that extra 1 mSeconds
faster response.
More VROOOM !!!!!
> Furthermore, is it time to change the name of the driver? Clearly, our
> driver is more accurately termed the sn9c201 driver than the Microdia
> driver (and has the added benefit that it's less likely to get us into
> trademark trouble)?
I did some considerable research. Microdia is a biological term.
Trademark is never given on a generic term(which means you can't
trademark Microdia).
But trademark has been given on a specific color, font & design on a
particular Microdia logo
(which is different from our logo, if we ever have one)
So the armchair lawyer in me says, such a situation will never arise.
(if SONiX starts to come out with their own opensource Microdia driver
even in that case the trademark will be on SONiX and not on microdia).
furthermore its impossible to infringe a trademark, if there are two
competing trademarks
which aren't in the same product category(causing confusion for the consumer)
>
>
>
> Dave
</armchair>
Dave Neuer
>
> // Detect device
> if ((vendor_id == USB_MICRODIA_VENDOR_ID) || (vendor_id == 0x045e) ||
> (vendor_id == 0x145f))
> {
> switch (product_id) {
> case USB_UDIA_6027_PRODUCT_ID:
>
> and add the product_ids again ?
> (what if we have exact same product_id under both microdia & microsoft
> vendor_ids ?
> see !! you haven't thought it through ;-)
The second solution I posted, namely:
> >
> > Or even better:
> >
> > int device_id = le16_to_cpu(udev->descriptor.idVendor) << 16
> > & le16_to_cpu(udev->descriptor.idProduct);
> >
> > switch (device_id) {
Solves that, by having the high 16 bits be the vendor ID, effectively
creating a namespace.
> >
> soln. is either separate switch, or hack to force it to identify is as
> another model.
Or the second solution, posted above again for emphasis.
>
>
> > Then again, perhaps we've reached that magic point in time when it
> > makes sense to break things out by sensor and bridge?
> >
>
> Yes Nicolas seems to think so too, his Syntek Driver is very big,
> so it has a facility to just build the kernel module for a single
> vendor_id: product_id combo.
> Syntek has capabilities to build for a single (vendor:product ID).
But I'm saying vendors don't matter. The Microsoft cam that spawned
this thread is essentially the same exact cam as my Microdia cam. What
I'm saying is that we should base the software on bridge + sensor. The
only thing we need the vendor and product ID's for in this case is to
lookup the chip + sensor combo.
>
> > Furthermore, is it time to change the name of the driver? Clearly, our
> > driver is more accurately termed the sn9c201 driver than the Microdia
> > driver (and has the added benefit that it's less likely to get us into
> > trademark trouble)?
>
> I did some considerable research. Microdia is a biological term.
Got links? I can't find any references other than to the company on
google or Wikipedia:
http://en.wikipedia.org/wiki/Special:Search/Microdia
Trademark analysis aside, I'm less concerned with violating trademarks
than accurately representing what our driver is and does. The fact is
that we support cams from more vendors than Microdia; we support any
combination of a Sonix SN9C201/2 bridge and a bunch of sensors. Seems
more appropriate in this case to call it the sn9c20x driver or some
such (and it's fairly consistent with the naming of other drivers in
the kernel).
Dave
GWater
> Trademark analysis aside, I'm less concerned with violating trademarks
> than accurately representing what our driver is and does. The fact is
> that we support cams from more vendors than Microdia; we support any
> combination of a Sonix SN9C201/2 bridge and a bunch of sensors. Seems
> more appropriate in this case to call it the sn9c20x driver or some
> such (and it's fairly consistent with the naming of other drivers in
> the kernel).
>
> Dave
>
> >
>
any way to solve this in userspace?
I am still with renaming. Nevertheless we should try not to loose the
people who only know us the "Ah, yes those microdia google guys..."-way.
GWater
Dave Neuer
>
> >
> kernel is a point - how are we currently with all the decoding? Is there
> any way to solve this in userspace?
> I am still with renaming. Nevertheless we should try not to loose the
> people who only know us the "Ah, yes those microdia google guys..."-way.
Well, we could save the renaming for the push to get into the kernel
(we could do the rename in a branch off the main code and keep the
name Microdia for the out-of-tree version).
However, does anyone have any reason to believe that the simple stream
format stuff we're doing wouldn't be accepted in the kernel? I know
JPEG decompression cannot, and I've heard people here mention bayer
demosaicing too -- though I've seen contradictory things about that on
LKML since it's linear complexity. But we're not even doing Bayer
demosaicing, are we -- I thought the bridge was doing that for us?
Dave
Bilbo75
I'm sorry to tell you that it doesn't work :(
The file microdia-usb.c it's patched correctly (I think) but the
driver doesn't recognize the camera.
Here it is my steps:
1) I've made a folder named "test" in my ~ directory
2) Inside this folder I've typed this: git clone http://repo.or.cz/r/microdia.git
3) Inside the "microdia" folder created by git I've typed : patch -p1
< ../../0017-Treat-045e-00f4-as-0c45-624f-treat-145f-013d-as-0c4.patch
(all ok ,no warnings)
4)Then I've typed "make" (compilation went ok with no warnings)
5)I've removed the working microdia.ko module from memory(with rmmod)
and from my /lib/modules/2.6.24/usb/media
6)I've typed a "depmod -a"
7)I've copied the microdia.ko module from ~/test/microdia folder in /
lib/modules/2.6.24/usb/media and typed again "depmod -a"
8)Then I've loaded the module (modprobe microdia).
Here it is the dmesg log :
---------------------------------------------------
but no /dev/video0 device. :(
Maybe I did some mistake...let me know .
Thanks in advance for your patience.
Ciao.
On 28 Apr, 19:53, "JoJo jojo" <onetwoj...@gmail.com> wrote:
> Hi Bilbo
>
> Well you asked for it, try out the attached patch and let us know.
>
> The ideal way would be to handle it like a normal model,
> (but its the same model, why keep different pieces of code, it will
> just introduce more bugs)
>
> a penny for your(Devs) thoughts .....
>
> -JoJo
>
> 2KScarica