Date: Sat, 24 Apr 2010 14:09:02 +0200 From: maillist@diode.be To: freebsd-usb@freebsd.org Subject: webcamd and cameras with Micron (MT9M0x1 and MT9T0x1) chips Message-ID: <20100424140902.4b7meoicg084g04g@webmail.diode.be>
next in thread | raw e-mail | index | archive | help
Hello list members, In the last months I have been toying with the video4bsd module and webcamd, as this finally gave me a possibility to use CMOS cameras with FreeBSD in an optics experiment (thanks!). For this I set up a box with 8-STABLE, and followed the instructions from http://www.selasky.org/hans_petter/video4bsd/ , using ports where applicable. I had instant success with an older Philips Toucam, and also with a Logitech C300 at full resolution (1024x1280). What didn't work back then was a Micron MT9T031 usb camera. I had hoped this would have worked with the mt9t031.c driver from v4l in the webcamd code. But there are some aspects of this camera that suggest it could be an early prototype. As it didn't associate with a driver on other OS'es as well, I didn't look into this further. Now I have a Mightex MCE-B013-US monochrome 1.3MPixel camera, which utilizes a Micron MT9M001 chip. There is a mt9m001.c file in the v4l code, but unfortunately this camera isn't recognized either. This made me wonder whether there is something special with these Micron CMOS-chips (and the code) that differs from other webcams. For both Micron cameras, #webcamd -B just gives `Cannot find USB device'. dmesg output for the Mightex camera (MT9M001 chip): ugen3.2: <Mightex> at usbus3 and usbconfig -d ugen3.2 dump_device_desc gives: ugen3.2: <USB-MT9M001-2 Mightex> at usbus3, cfg=3D0 md=3DHOST spd=3DHIGH (480Mbps) pwr=3DON bLength =3D 0x0012 bDescriptorType =3D 0x0001 bcdUSB =3D 0x0200 bDeviceClass =3D 0x0000 bDeviceSubClass =3D 0x0000 bDeviceProtocol =3D 0x0000 bMaxPacketSize0 =3D 0x0040 idVendor =3D 0x04b4 idProduct =3D 0x0228 bcdDevice =3D 0x0000 iManufacturer =3D 0x0001 <Mightex> iProduct =3D 0x0002 <USB-MT9M001-2> iSerialNumber =3D 0x0000 <no string> bNumConfigurations =3D 0x0001 For the MT9T031 camera (likely prototype), dmesg gives: ugen3.2: <Micron> at usbus3 and usbconfig -d ugen3.2 dump_device_desc: ugen3.2: <Demo2A Micron> at usbus3, cfg=3D0 md=3DHOST spd=3DHIGH (480Mbps) p= wr=3DON bLength =3D 0x0012 bDescriptorType =3D 0x0001 bcdUSB =3D 0x0200 bDeviceClass =3D 0x0000 bDeviceSubClass =3D 0x0000 bDeviceProtocol =3D 0x0000 bMaxPacketSize0 =3D 0x0040 idVendor =3D 0x0634 idProduct =3D 0x1007 bcdDevice =3D 0x0021 iManufacturer =3D 0x0001 <Micron> iProduct =3D 0x0002 <Demo2A> iSerialNumber =3D 0x0000 <no string> bNumConfigurations =3D 0x0001 Now, I have no coding skills, but thought it would be good to have a =20 look into the driver code. I hoped I would find Vendor and Product =20 id's that differed from how the camera identified, this explaining the =20 refusal to associate. But while some other v4l drivers appear to =20 contain things like {USB_DEVICE(0xXXXX, 0xXXXX), .driver_info=3DXXXXX}, =20 such code is absent from the mt9xxxx.c files. Instead, there is a =20 function data =3D reg_read(client, MT9M001_CHIP_VERSION) that does some =20 sort of identification. But this is on the i2c level, reading the chip =20 version number. I thought that for doing this, the system would =20 already need to know what Micron chip it is dealing with. Any thoughts would be appreciated. Thanks. Tiemen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100424140902.4b7meoicg084g04g>