Re: Plan to support Rockchip VPU in DRM, is it a good idea
each package, and sometimes they grabbed the wrong CD, too. Evidence of that was that Google used to give a lot of links to complaints about needing a functioning Windows driver for certain cheap cameras. Unless things have changed, the Linux driver for these cameras is the only one in existence for any operating system which will tell these cameras apart and send the right initialization sequence. Moreover, the method for detecting the chipset was completely undocumented by the manufacturers, who did not even acknowledge requests for information. It is impossible to make a common way to send those settings to driver.For the samsung MFC, you don't need to do any parse work at all. Then, as I said, you need to write driver code which will know one of them from another. Surely you can do this. Even though I continue to subscribe to the linux-media list and read with interest much of what I receive, I have not written much code for several years. I have two excuses. First, I am 75 years old now. Second, I have a full-time job doing something else. But you work for a chip vendor. Thus on the one hand you and your company are certainly deserving of praise for troubling yourselves to communicate with Linux kernel developers at all. There are those who do not (see above for an example). But on the other hand you are dealing with very experienced people, who have written a lot of code and have done a lot of plannihg about what should go where in what is now a huge mass of kernel code, and who are rightly concerned that this code should be accessible and maintainable by someone else when they are gone from the scene. I am not one of the main developers here, so perhaps you will be more willing to take it from me if I say that you and your company need to take seriously what those main developers are telling you. They have their reasons, and their reasons are very good reasons. Theodore Kilgore Anyway, I would like to follow what Intel does now, we are both stateless video processor. Regards, Hans ___ dri-devel mailing list dri-de...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Randy Li The third produce department -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] gspca: sn9c2028: Add gain and autogain controls Genius Videocam Live v2
,
.start = sd_start,
.stopN = sd_stopN,
+ .dq_callback = sd_dqcallback,
.pkt_scan = sd_pkt_scan,
};
diff --git a/drivers/media/usb/gspca/sn9c2028.h
b/drivers/media/usb/gspca/sn9c2028.h
index 8fd1d3e..6f20c0f 100644
--- a/drivers/media/usb/gspca/sn9c2028.h
+++ b/drivers/media/usb/gspca/sn9c2028.h
@@ -21,8 +21,17 @@
*
*/
-static const unsigned char sn9c2028_sof_marker[5] =
- { 0xff, 0xff, 0x00, 0xc4, 0xc4 };
+static const unsigned char sn9c2028_sof_marker[] = {
+ 0xff, 0xff, 0x00, 0xc4, 0xc4, 0x96,
+ 0x00,
+ 0x00, /* seq */
+ 0x00,
+ 0x00,
+ 0x00, /* avg luminance lower 8 bit */
+ 0x00, /* avg luminance higher 8 bit */
+ 0x00,
+ 0x00,
+};
static unsigned char *sn9c2028_find_sof(struct gspca_dev *gspca_dev,
unsigned char *m, int len)
@@ -32,8 +41,13 @@ static unsigned char *sn9c2028_find_sof(struct gspca_dev
*gspca_dev,
/* Search for the SOF marker (fixed part) in the header */
for (i = 0; i len; i++) {
- if (m[i] == sn9c2028_sof_marker[sd-sof_read]) {
+ if ((m[i] == sn9c2028_sof_marker[sd-sof_read]) ||
+ (sd-sof_read 5)) {
sd-sof_read++;
+ if (sd-sof_read == 11)
+ sd-avg_lum_l = m[i];
+ if (sd-sof_read == 12)
+ sd-avg_lum = (m[i] 8) + sd-avg_lum_l;
if (sd-sof_read == sizeof(sn9c2028_sof_marker)) {
PDEBUG(D_FRAM,
SOF found, bytes to analyze: %u.
--
2.3.5
Hello.
I do not know of this particular camera. But I am very pleased to see
continued interest in the sn9c2028 cameras. Congratulations for these two
patches.
Cheers,
Theodore Kilgore
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW] Submitting Media Patches
Hans, Please check the apparent typo in your text below. what humans to best - what humans do best As for me, I am happy that I can still see well enough to have caught it. Theodore Kilgore On Wed, 22 Oct 2014, Hans Verkuil wrote: During the mini-summit it was decided that we should put up a document on how to post/handle patches etc. for the media drivers in the wiki. I had such a doc already which I'm posting now for review. Once it's all OK Pawel offered to put it up in the wiki. - For general information on how to submit patches see: http://linuxtv.org/wiki/index.php/Developer_Section In particular the section 'Submitting Your Work'. This document goes into more detail regarding media specific requirements when submitting patches and what the patch flow looks like in this subsystem. Note 1: there are always exceptions to the rule, so if you believe certain requirements do not apply to your code, then let us know and we can discuss it. Note 2: this list is not exhaustive and will be updated over time, so make sure you always use the latest version of this document. The latest version will always be available here: TBD. Note 3: when submitting a patch use ./scripts/get_maintainer.pl to figure out who is maintaining the sources you touched. Submitting New Media Drivers When submitting new media drivers for inclusion in drivers/staging/media all that is required is that the driver compiles with the latest kernel, that an entry is added to the MAINTAINERS file, and that a TODO file is added with a list of action items that need to be taken before the driver can be moved to drivers/media. It should be noticed, however, that it is expected that the driver will be fixed to fulfill the requirements for upstream addition. If a driver at staging lacks relevant patches fixing it for more than a few kernel cycles, it can be dropped from staging. We will contact you before doing that provided that the email address of the maintainer is still valid. For inclusion as a non-staging driver the requirements are more strict: General requirements: - It must pass checkpatch.pl, but see the note regarding interpreting the output from checkpatch below. - An entry for the driver is added to the MAINTAINERS file. - The kernel internal APIs are used properly. - Don't reinvent the wheel by adding new defines, math logic, etc. for which there are already solutions in the kernel. - Follow the CodingStyle guidelines, paying specific attention to the follow frequently made mistakes: - Errors should be reported as negative numbers using the kernel error codes. See also the CodingStyle document, chapter 16. - Don't use typedefs. See also the CodingStyle document, chapter 5. - When adding/enhancing the API the documentation must be updated as well, otherwise the patch will not be accepted. V4L2 specific requirements: - Use struct v4l2_device for bridge drivers, use struct v4l2_subdev for sub-device drivers. - Each i2c/spi device should be implemented as a separate sub-device driver. - Use the control framework for control handling. - Use struct v4l2_fh if the driver supports events (implied by the use of controls) or priority handling. - Use videobuf2 for buffer handling. - Must pass the v4l2-compliance tests. - Hybrid tuners should be shared with DVB. - When introducing new APIs: - update v4l2-ctl - updates to v4l2-compliance (if applicable) are highly appreciated - update valgrind: support for v4l2 and media ioctls was added for valgrind 3.10 synced to the 3.18 kernel. This should be kept up to date. Patches should be posted as a bug report. See: http://valgrind.org/support/bug_reports.html DVB specific requirements: - Use the DVB core for both internal and external APIs. - Each I2C-based chip should have its own driver. - Tuners and frontends should be mapped as different drivers. - dvb_frontend_ops should specify the delivery system instead of specifying the frontend type via the dvb_frontend_ops info.type field. - DVB frontends should not implement dummy function handlers; if the function is not implemented, the DVB core should handle it properly. - Hybrid tuners should be shared with V4L. How to deal with checkpatch.pl? === First of all, the requirement to comply to the kernel coding style is there for a reason. Sometimes people feel that it is a pointless exercise: after all, code is code, right? Why would just changing some spacing improve it? But the coding style is not there to help you (at least, not directly), it is there to help those who have to review and/or maintain your code as it takes a lot of time to review code or try to figure out how someone else's code works. By at least
Re: Wrongly identified easycap em28xx
. And whichever driver is installed one of the two cameras will not work. Proof, BTW, that neither of those Windows drivers contains any detection routine. The gspca_mr97310a module for Linux is the only support for those cameras for any operating system that I know of, which actually can tell one of those cameras from the other and apply the right initialiation to it when it is hooked up -- unless somebody has copied us since then. The situation here looks to me similar. What someone needs to do is to find some kind of read command or sequence of commands (probably to the sensor, not to the controller) which will report a distinct answer for each of the various different cameras. Almost certainly, it will not be documented, but it almost certainly has to exist -- if for no other reason, because something is obviously different about the two pieces of hardware. So in my opinion the thing to do is to try to find that magic command. By a combination of educated guessing and trial and error. This needs for someone to have both cameras, or for two or more people who have the different cameras to cooperate together and hunt for the right command which unlocks the mystery. I am out of this one because I don't have one of the cameras currently in question. But I did have a big pile of mr97310a cameras, and that is exactly what I did. Started sending various commands and checking whether or not I got different results until I found what works. So, good luck. The answer is probably there if one looks for it. My two cents, Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
St. Petersburg
To whom it may concern: I expect to participate in the conference Wavelets and Applications which will take place at the Euler Mathematical Institute in St. Petersburg, Russia, July 8 - 15. The conference is about mathematics, not Linux. So during the conference sessions I will be wearing my mathematician hat, not my code-writing hat. But if any of the regulars who frequent this list happen to live in the neighborhood, here is an invitation to meet for a coffee. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
On Thu, 8 Mar 2012, Xavion wrote: Hi Theodore As to getting that kind of resolution out of a webcam, though, it would be a rather tough go due to the amount of data which has to pass over the wire even if it is compressed data. The frame rate would be pretty atrocious. Therefore, you are probably not going to see that kind of resolution in an inexpensive webcam, at least until USB 3 comes into common use. Thanks for offering your thoughts on this matter. You are welcome. It looks like I'll have to keep checking eBay for cheap USB v3 (HD) webcams periodically. Which somebody will need to support because they will probably not work out of the box with an OEM driver CD ;-) For the record, I've only got Motion set to capture four frames per second at the moment. Perhaps for now if you want that kind of resolution and do not care about the frame rate very much, you would be better off to buy a slightly fancier camera and do something like using gphoto2 to take timed shots. I prefer the idea of captured motion to that of timed snapshots. The captured images and videos are automatically uploaded to my Dropbox account. As I'm only a 'free' user, I must limit the storage space that these files consume. Some of the cheap cameras do work pretty well, actually. But as far as I know any resolution better than 640*480 seems to be pretty unusual. Lots of interpolated higher resolution meaning they have inflated the pictures, of course. But some of the 640x480 cameras do better than others. And also I should point out that if 4 fps is OK with you then some of the cameras do not even do compression. If you could get hold of an old SQ905 camera that will do 640x480 it runs on bulk transport and there is no compression of frame data at all. Also, what is interesting is that with all the cheap cameras they cut corners, of course. But the SQ905 cameras always seemed to me to tend to have better optics than a lot of the other cheap cams. Where they really cut down on features was with the controller chip. It will do practically nothing compared to some others. The SQ905 used to be advertised as the cheapest camera controller chip on the market, once upon a time. But the images one gets from those cameras sometimes are not half bad. Also I should mention that if one wants to get better images out then it is best somehow to capture and save the raw data and process it later. This is true for any camera which either produces an uncompressed bitmap raw image, and also for any camera which does compression of said bitmap image before sending it down to the computer. Everything but JPEG, pretty much. Why is this? Because the image processing used with webcams must necessarily have speed as the number one priority, else the frame rate suffers severely. If one is not thus constrained, it is possible to do a much better job with that raw data. But remember that you can maximize image quality, or you can maximize frame rate. Choose one of the two. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
. Therefore, you are probably not going to see that kind of resolution in an inexpensive webcam, at least until USB 3 comes into common use. Perhaps for now if you want that kind of resolution and do not care about the frame rate very much, you would be better off to buy a slightly fancier camera and do something like using gphoto2 to take timed shots. Just a suggestion. And thanks for the patience to work through the problem. This thread has been an interesting read. Theodore Kilgore
Re: v4l-utils migrated to autotools
On Wed, 18 Jan 2012, Mauro Carvalho Chehab wrote: Em 18-01-2012 11:02, Gregor Jasny escreveu: On 1/18/12 1:54 PM, Mauro Carvalho Chehab wrote: Em 18-01-2012 10:47, Gregor Jasny escreveu: On 1/18/12 1:19 PM, Mauro Carvalho Chehab wrote: It would be nice to write at the INSTALL what dependencies are needed for the autotools to work, or, alternatively, to commit the files generated by the autoreconf -vfi magic spell there [1]. The end user gets a tarball created with make dist which contains all the m4 files. Ah, ok. It probably makes sense then to add some scripting at the server to do a daily build, as the tarballs aren't updated very often. They're updated only at the sub-releases: http://linuxtv.org/downloads/v4l-utils/ Judging from the upside-down reports: not the lack of a buildable tarball but the lack of updated distribution packages is a problem. For Ubuntu we have a PPA repository with nightly builds: https://launchpad.net/~libv4l/+archive/development Do you have similar infrastructure for Fedora / RedHat, too? There are two separate issues here: 1) users that just get the distro packages. For them, the updated distro packages is the issue. For those, it is very good to have v4l-utils properly packaged on Ubuntu. Thanks for that! Hans is maintaining v4l-utils at Fedora. I don't think he's currently using the -git unstable versions at Fedora Rawhide (the Fedora under development distro). Yet, every time a new release is lauched, he updates the packages for Fedora. So, I think that this is now properly covered with Fedora and Ubuntu (also Debian?). I think that Suse is also doing something similar. 2) users that are testing the neat features that the newest package has. This covers most of the 900+ subscribers of the linux-media ML. Those users, in general, don't care much about the distro packages. They just want to download the latest sources and compile, in order to test the drivers/tools, and provide us feedback. We want to make life easier for them, as their test is very important for us to detect, in advance, when some regression is happened somewhere. For those users, it may make sense to have a daily tarball or some user-friendly scripting that would allow them to easily clone the git tree and use it. Regards, Mauro As one of the people who comes under category (2) above, let me add a couple of comments, here. First, I was unaware of these changes until I found out about them the hard way, a few days ago. Namely, I did a git pull and added the new stuff to my working copy, then could not compile anything. The error I got said that config.h is missing. Well, it took me all of about 5 minutes to figure out that I had better re-read the Imstall file, which made things totally clear. Run autoconf. Been there with other projects, done that. No problems. I only saw some mail on the list about the changeover a couple of days after that, and had a chuckle. Second, it is no big deal. Autoconf works quite nicely, so what is the problem, exactly? I see not much need for a daily tarball or some user-friendly scripting to fix something which does not appear to be a problem. Well, there is a problem, but I do not see it as a serious one. The problem is that one's tools have to be up to date. That is up to the distro. But it is probably well known that some distros are better at keeping up with things like this than are others. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH for 3.2 URGENT] gspca: Fix bulk mode cameras no longer working (regression fix)
On Fri, 30 Dec 2011, Hans de Goede wrote: Hi, On 12/30/2011 11:21 AM, Jean-Francois Moine wrote: On Thu, 29 Dec 2011 21:36:42 +0100 Hans de Goedehdego...@redhat.com wrote: The new iso bandwidth calculation code accidentally has broken support for bulk mode cameras. This has broken the following drivers: finepix, jeilinj, ovfx2, ov534, ov534_9, se401, sq905, sq905c, sq930x, stv0680, vicam. Thix patch fixes this. Fix tested with: se401, sq905, sq905c, stv0680 vicam cams. Hi Hans, Sorry for I should not be fully awoken yet, but I don't understand the problem from your fix. The patch just sets the altsetting to the highest one for bulk transfer. Does this mean that, in this case, the altsetting table created by build_ep_tb is wrong and the highest altsetting cannot selected? Most bulk mode cameras have only one altsetting, altsetting 0, which is seen as invalid by build_ep_tb, since it is invalid for isoc mode, resulting in the cameras not working with a: no transfer endpoint found error. I've opted to fix things by causing build_ep_tb to not be called for bulk mode cameras at all, since doing bandwidth calculations for bulk mode makes no sense. bulk transfers get whatever bandwidth is left on the bus, there is no guarantee that there are 1000 / interval packets a second like there is with isoc transfers, so the bandwidth is unknown. Also note that because of this interval is 0 for bulk endpoints, since it is unused. So calling build_ep_tb for bulk mode transfers makes no sense. WRT just choosing the highest numbered alt setting this is because some bulk mode cameras (stv0680 based ones) report 2 alt settings (which makes no sense for bulk mode, but they do it anyways), with alt setting 0 not listing any endpoints at all, and alt setting 1 listening the bulk endpoint we want, so by picking the highest alt setting we end up with picking the one and only alt setting most cameras have and picking one which actually has the bulk endpoint listed for weird cases like the stv0680 based ones. Note that I'm spending most of my time today on testing the new bandwidth code with various cameras, I'll send you a patchset with some more proposed patches today. We should then evaluate if we want to get those into 3.2 too. I send this one yesterday since it fixes a large bunch of cameras not working at all and it is a simple and safe fix IMHO. Regards, Hans Jean-Francois, Hans, Without addressing finer points, please let me add the following: 1. I figured out what was holding me back from getting 3.2 to work (it was a config error, apparently originating between keyboard and chair). 2. Based upon my testing today, something like this patch is clearly necessary. Namely, I tested a mass storage camera. Without this patch it would not stream. When I applied the patch, it did. Therefore, I hope very much that the problem which occasioned this patch gets fixed. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH for 3.2 URGENT 0/1] Fix major regression in gspca
On Thu, 29 Dec 2011, Hans de Goede wrote: Hi all, Unfortunately the new iso bandwidth calculation code in gspca has accidentally broken support for bulk mode cameras, breaking support for a wide range of chipsets (see the patch for a full list). Mauro, please send this patch to Linus asap, so that 3.2 won't ship with this regression. Thanks, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Thanks, Hans. BTW, 3.2 so far seems totally broken for me. I could not get nearly so far as to test any of these cameras, even though several of the drivers in question are mine. I started testing the kernel at level 3.2-rc6 and got repeated kernel oopses, happening every time I mounted a partition read-write. It did boot, finally, but it barely booted. So, no testing cameras, as I said. I never got that far. Today I tried the latest, which calls itself 3.2-rc7. Its behavior is even worse. As I recall, it did not even complete the booting. :-/ So I sure hope that at least this patch helps out those people who _can_ boot the new kernel. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fly 110 TV camera
Ilya contacted the gphoto-devel list about this camera. In spite of the name with TV in it, I understand that the camera is in fact installed in a cell phone. In stillcam mode, the camera is, I understand, a mass storage device. But when in webcam mode it comes up with a different ID and is a proprietary device. Some basic relevant information can be seen in the forwarded message, below. Most particularly, the lsusb output is there. Ilya is willing to cooperate in developing support for the camera. Since I pointed out that the first thing one needs is a record of the camera at work, he tried to get some log files. He is running Win 7, and the old snoop programs do not work. Thus, today he sent me two log files which are in an unknown format (file suffix .ulz) which I cannot even seem to find in a Google search (seems to get redirected to .alz). These log files are supposed to be openable if one uses the tool that he used to create them, which is available in a 30-day trial version. Thus two questions: 1. How are other people managing to create USB log files in Win 7? 2. What is a .ulz file, and how does one get opened, other than with some 30-day trial version of some program? Oh, yes, and to the above we can definitely add that there is surely enough fun for all in this. Does anyone else want to play? If so, go right ahead and contact me or Ilya. Theodore Kilgore (message with some relevant background information in it follows) -- Forwarded message -- Date: Sun, 2 Oct 2011 00:02:54 -0500 (CDT) From: Theodore Kilgore kilg...@banach.math.auburn.edu To: Ilya Chernykh anixx...@gmail.com Cc: gphoto-de...@lists.sourceforge.net Subject: Re: [gphoto-devel] Fly 110 TV camera On Sun, 2 Oct 2011, Ilya Chernykh wrote: On Sunday 02 October 2011 01:35:08 you wrote: Now, look at that output. You ought to see information about Class and Subclass and Protocol. You can compare what you get to the list of the standard ones which you can find in lots of places, for example in the usb.ids file which is probably somewhere in your /usr/share directory. If you see Class ff and Subclass ff and Protocol ff it means proprietary, proprietary, proprietary and there is a bit of work to do. It's 0, 0, 0. Not exactly. Says Defined at interface level But at the interface level it says 255, 255, 255 which is ff, ff, ff. Which as I said last time means Proprietary, Proprietary, Proprietary. So, OK. These are not standard ones. You can give the dmesg command. If it sees and reports the webcam and says a module got loaded, it ought to work. You can also check whether ls -l /dev/video* No such file or directory. OK. there would not be. Finally, I would conjecture that the lsusb output for the camera would be of sufficiently general interest that you should go ahead and post it here. Here it is: === Bus 003 Device 005: ID 114d:8000 Alpha Imaging Technology Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x114d Alpha Imaging Technology Corp. idProduct 0x8000 bcdDevice1.00 iManufacturer 0 iProduct0 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x (Bus Powered
Re: spca1528 device (Device 015: ID 04fc:1528 Sunplus Technology)..libv4l2: error turning on stream: Timer expired issue
On Sun, 4 Sep 2011, Mauricio Henriquez wrote: Hi guys, Not sure if is the right place to ask since this device use a gspca driver and not sure if that driver is related to uvc or not, if not please point me to the right place... Looks right to me, and I hope that someone has more direct knowledge about your camera, which I do not. I do have a couple of questions, however, and a comment. Recently I'm trying to make work a Sunplus crappy mini HD USB camera, lsusb list this info related to the device: Picture Transfer Protocol (PIMA 15470) Bus 001 Device 015: ID 04fc:1528 Sunplus Technology Co., Ltd idVendor 0x04fc Sunplus Technology Co., Ltd idProduct 0x1528 bcdDevice1.00 iManufacturer 1 Sunplus Co Ltd iProduct2 General Image Devic iSerial 0 ... Using the gspca-2.13.6 on my Fed12 (2.6.31.6-166.fc12.i686.PAE kernel), the device is listed as /dev/video1 and no error doing a dmesg...but trying to make it work, let say with xawtv, I get: This is xawtv-3.95, running on Linux/i686 (2.6.31.6-166.fc12.i686.PAE) xinerama 0: 1600x900+0+0 WARNING: No DGA direct video mode for this display. /dev/video1 [v4l2]: no overlay support v4l-conf had some trouble, trying to continue anyway Warning: Missing charsets in String to FontSet conversion Warning: Missing charsets in String to FontSet conversion libv4l2: error turning on stream: Timer expired ioctl: VIDIOC_STREAMON(int=1): Timer expired ioctl: VIDIOC_S_STD(std=0x0 []): Invalid argument v4l2: oops: select timeout ..or doing: xawtv -c /dev/video1 -nodga -novm -norandr -noxv -noxv-video I get: ioctl: VIDIOC_STREAMON(int=1): Timer expired ioctl: VIDIOC_S_STD(std=0x0 []): Invalid argument v4l2: oops: select timeout libv4l2: error turning on stream: Timer expired libv4l2: error reading: Invalid argument vlc, cheese, etc give me similar Timeout related messages... The comment: Perhaps a good thing to try would be the nice, simple, basic program svv, which you can get from the website of Jean-Francois Moine. Some of these other things do not always work. Especially I have had trouble with xawtv, though the xawtv people may have fixed a lot of problems while I was not watching them. The question: Is this a dual-mode camera which is also supposed to have still camera capabilities? If so, you might be interested in contacting the Gphoto project. I just searched for it there, and it does not seem to be listed. I assume that the specialists on the spca cameras will step forward. I am not one of them, as I said. Good luck. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB mini-summit at LinuxCon Vancouver
On Thu, 11 Aug 2011, Alan Stern wrote: On Thu, 11 Aug 2011, Alan Cox wrote: Actually there are more issues than that - you've also got to worry about a security/permission model, and that is hard to get right, especially if you are not very careful that anything that can be retrieved which might violate the security model (eg the last frame on the capture) has been blanked before handover etc. As far as I can tell, these same security issues exist today. I don't see them getting any worse than they are now. And applications that are touching both video (even indirectly) and still camera may get surprise deadlocks if they accidentally reference both the still and video device even via some library or service. No, not deadlocks. Just -EBUSY errors. Well, a user program can assume that the kernel driver left the device in a clean state. The reverse isn't always true, however -- it's one Not it cannot - the user program doesn't know a) if the kernel driver has ever been loaded b) the values the kernel driver leaves set (and those will change no doubt at times) c) if the camera has been plugged and unplugged and not yet had the kernel driver loaded That's true. The program can't assume that a kernel driver was ever bound to the device; all it can assume is that _if_ a kernel driver was bound then it left the device in a sane state -- whatever sane might mean in this context. To me it sounds like a recipe for disaster. For those tiny number of devices involved just use V4L and if need be some small V4L tweaks to handle still mode. In most cases the interface is basically identical and I'd bet much of the code is identical too. I'm not against moving the whole thing into the kernel. I'm just pointing out that an easier-to-code-up solution will accomplish much the same result. Alan Stern Alan, As I said, I am agnostic, though leaning in the direction that Hans de Goede is pointing. What he says about a single control mechanism seems to make a lot of sense. If you can come up with an outline of the easier to code solution, that would be interesting, though. I assume you are also going to be in Vancouver? If you will be there on Monday, then Hans and I are already planning to meet and discuss. BTW, as to using V4L with tweaks to handle still mode, it would probably be more difficult than is imagined. For, though the operations required to process still images and webcam frames are in principle similar, the priorities and constraints are too different. Therefore, my understanding is that the libgphoto2 image processing routines, not the libv4l image processing routines, would still be used for still images. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB mini-summit at LinuxCon Vancouver
On Thu, 11 Aug 2011, Mauro Carvalho Chehab wrote: Em 11-08-2011 17:01, Theodore Kilgore escreveu: As I said, I am agnostic, though leaning in the direction that Hans de Goede is pointing. What he says about a single control mechanism seems to make a lot of sense. If you can come up with an outline of the easier to code solution, that would be interesting, though. I assume you are also going to be in Vancouver? If you will be there on Monday, then Hans and I are already planning to meet and discuss. BTW, as to using V4L with tweaks to handle still mode, it would probably be more difficult than is imagined. For, though the operations required to process still images and webcam frames are in principle similar, the priorities and constraints are too different. Therefore, my understanding is that the libgphoto2 image processing routines, not the libv4l image processing routines, would still be used for still images. I agree with Alan Cox: most of the code that the driver needs is already there: register read/write routines, bulk transfer support, etc. The amount of extra code for adding still cam functionality is probably not big. From the kernel driver's perspective, it doesn't matter if the access will come via libv4l, libgphoto2 or whatever. The driver should be able to allow simultaneous open, while protecting the data access when userspace requests data stream or still image retrieve. instead of using the V4L2 device node to access the stored images, it probably makes more sense to use a separate device for that, that will handle a separate set of ioctl's, and just use read() to retrieve the image data, after selecting the desired image number, via ioctl(). It probably makes sense to add a new set of callbacks at the gspca core in order to handle the new device node, and letting it to avoid start streaming while the store access is happening, and vice-versa. Alternatively, we may create a separate still cam core library to handle the new device node,. If all agree around such solution, I suggest to take the most complex case and try to map it into the driver and core, and see how it behaves, testing with some simple command line applications, only changing the libgphoto2 code after those initial tests. Writing a simple code for reading still images should be easy, and we have already some testing tools for V4L2. After coding the core changes that are common to all drives, I suspect that adding the remaining 4 drivers will be quick. With regards to libgphoto2, all it needs to do is to test if the new device nodes exist. If they exist, then the new code will be used. Otherwise, it will fallback to the libusb. This way, we can incrementally add the Dual mode drivers into the kernel. There is one advantage on using this strategy: if, in the future, new Dual Cams arise, one can write first a still cam kernel driver, adding V4L support later. Cheers, Mauro Try it out with one camera seems to me to be a reasonable way forward. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB mini-summit at LinuxCon Vancouver
On Thu, 11 Aug 2011, Alan Stern wrote: snip No, I'm not going to Vancouver. Well, someday, somewhere, we will be together in the same place at the same time and able to enjoy a good seafood restaurant. However I will attend the Linux Plumbers conference in Santa Rosa. Which I expect I will not. Until next time we meet, cheers. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB mini-summit at LinuxCon Vancouver
On Wed, 10 Aug 2011, Alan Stern wrote: On Tue, 9 Aug 2011, Hans de Goede wrote: Hi, On 08/09/2011 04:19 PM, Alan Stern wrote: On Tue, 9 Aug 2011, Hans de Goede wrote: According to Theodore, we have developed 5 drivers for them because the stillcam modes in different devices use four different vendor-specific drivers. Yes, but so the the webcam modes of the different devices, so for the 5 (not sure if that is the right number) dual-cam mode chipsets we support there will be 5 drivers, each supporting both the webcam and the access to pictures stored in memory of the chipset they support. So 5 chipsets - 5 drivers each supporting 1 chipset, and both functions of the single logical device that chipset represents. Does it really make sense to combine 5 drivers into one? Right, that is not the plan. The plan is to simply stop having 2 drivers for 1 logical (and physical) block. So we go from 10 drivers, 5 stillcam + 5 webcam, to just 5 drivers. We will also likely be able to share code between the code for the 2 functionalities for things like generic set / get register functions, initialization, etc. Okay, I didn't realize that the different cameras used different webcam drivers as well as different stillcam drivers. Oh, yes. They are Proprietary devices. And that means what it says. :-) And all different from each other, too. As far as I can see, there's nothing to stop anybody from adding the stillcam functionality into the webcam drivers right now. If some common code can be abstracted out into a shared source file, so much the better. That would solve the problem, right? I think everyone involved believes that it would solve the problem. The question has been all along whether or not there is any other way which would work. Also the question of what, exactly, belongs in the kernel and what does not. For, if something has been historically supported in userspace (stillcam support, in this case) and has worked well there, I would think it is kind of too bad to have to move said support into the kernel just because the same hardware requires kernel support for another functionality and the two sides clash. I mean, the kernel is already big enough, no? But the logic that Hans has set forth seems rather compelling. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB mini-summit at LinuxCon Vancouver
On Wed, 10 Aug 2011, Alan Stern wrote: On Wed, 10 Aug 2011, Theodore Kilgore wrote: Okay, I didn't realize that the different cameras used different webcam drivers as well as different stillcam drivers. Oh, yes. They are Proprietary devices. And that means what it says. :-) And all different from each other, too. As far as I can see, there's nothing to stop anybody from adding the stillcam functionality into the webcam drivers right now. If some common code can be abstracted out into a shared source file, so much the better. That would solve the problem, right? I think everyone involved believes that it would solve the problem. The question has been all along whether or not there is any other way which would work. Also the question of what, exactly, belongs in the kernel and what does not. For, if something has been historically supported in userspace (stillcam support, in this case) and has worked well there, I would think it is kind of too bad to have to move said support into the kernel just because the same hardware requires kernel support for another functionality and the two sides clash. I mean, the kernel is already big enough, no? But the logic that Hans has set forth seems rather compelling. The alternative seems to be to define a device-sharing protocol for USB drivers. Kernel drivers would implement a new callback (asking them to give up control of the device), and usbfs would implement new ioctls by which a program could ask for and relinquish control of a device. The amount of rewriting needed would be relatively small. A few loose ends would remain, such as how to handle suspends, resumes, resets, and disconnects. Assuming usbfs is the only driver that will want to share a device in this way, we could handle them. Hans, what do you think? Alan Stern Alan, Hans seems to have argued cogently for doing all of this in the kernel and for abandoning the usbfs-based drivers for these particular drivers for dual-mode cameras and, I would conjecture, for drivers for dual-mode hardware in general. Therefore, I anticipate that he won't like that very much. My position: I do not have preconceptions about how the problem gets handled, and at this point I remain agnostic and believe that all approaches ought to be carefully analysed. I can imagine, abstractly, that things like this could be handled by -- moving all basic functionality to the kernel, and fixing the relevant libgphoto2 drivers to look to the kernel instead of to libusb. (What Hans argues for, and I am not opposed if his arguments convince other concerned parties) -- doing some kind of patch job to make current arrangement somehow to work better (this seems to be the position of Adam Baker; I do share the skepticism Hans has expressed about how well this could all be pasted together) -- doing something like the previous, but also figuring out how to bring udev rules into play, which would make it all work better (just tossing this one in, for laughs, but who knows someone might like it) -- moving the kernel webcam drivers out of the kernel and doing with these cameras _everything_ including webcam function through libusb. I myself do not have the imagination to be able to figure out how this could be done without a rather humongous amount of work (for example, which streaming apps that are currently available would be able to live with this?) but unless I misunderstand what he was saying, Greg K-H seems to think that this would be the best thing to do. Which one of these possibile approaches gets adopted is a policy issue which I would consider is ultimately way above my pay grade. My main motivation for bringing up the issue was to get it to the front burner so that _something_ gets done. It is a matter which has been left alone for too long. Therefore, I am very glad that the matter is being addressed. Let me add to this that I have gotten permission for time off and for a expense money which might possibly cover my air fare. I hope to arrive in Vancouver by sometime on Monday and intend to attend the mini-summit. I suggest that we get all intersted parties together and figure out what is the best way to go. I hope everyone who is actively concerned can meet in Vancouver, and if all goes well then on Monday as well as Tuesday. I can hang around for another day or two after Tuesday, but I do not expect to register for LinuxCon or be involved in it. When I leave Vancouver I will probably go to Seattle and spend a couple of days with my oldest son, the musician, before coming home on the next weekend. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB mini-summit at LinuxCon Vancouver
On Wed, 10 Aug 2011, Greg KH wrote: On Wed, Aug 10, 2011 at 01:33:25PM -0500, Theodore Kilgore wrote: -- moving the kernel webcam drivers out of the kernel and doing with these cameras _everything_ including webcam function through libusb. I myself do not have the imagination to be able to figure out how this could be done without a rather humongous amount of work (for example, which streaming apps that are currently available would be able to live with this?) but unless I misunderstand what he was saying, Greg K-H seems to think that this would be the best thing to do. No, I never said that. Or if I accidentally did, I do not think that is the best thing to do at all, sorry for any confusion. OK. Which one of these possibile approaches gets adopted is a policy issue which I would consider is ultimately way above my pay grade. As no one is being paid here, there are no pay grades, so don't worry about that :) I meant this, of course, in a metaphorical sense. Cheers, Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB mini-summit at LinuxCon Vancouver
On Wed, 10 Aug 2011, Mauro Carvalho Chehab wrote: Em 10-08-2011 15:33, Theodore Kilgore escreveu: Hans seems to have argued cogently for doing all of this in the kernel and for abandoning the usbfs-based drivers for these particular drivers for dual-mode cameras and, I would conjecture, for drivers for dual-mode hardware in general. Therefore, I anticipate that he won't like that very much. My position: I do not have preconceptions about how the problem gets handled, and at this point I remain agnostic and believe that all approaches ought to be carefully analysed. I can imagine, abstractly, that things like this could be handled by -- moving all basic functionality to the kernel, and fixing the relevant libgphoto2 drivers to look to the kernel instead of to libusb. (What Hans argues for, and I am not opposed if his arguments convince other concerned parties) Not looking on the amount of work to be done, I think that this would give better results, IMO. Okay. I would guess that I am one of the guys who gets to do the work, though. -- doing some kind of patch job to make current arrangement somehow to work better (this seems to be the position of Adam Baker; I do share the skepticism Hans has expressed about how well this could all be pasted together) Adam Baker's proposal of a locking between usbfs and the kernel driver seems to be interesting, but, as he pointed, there are some side effects to consider, like suspend/resume, PM, etc. -- doing something like the previous, but also figuring out how to bring udev rules into play, which would make it all work better (just tossing this one in, for laughs, but who knows someone might like it) I don't think this is a good alternative. I was trying to mention all alternatives. I should have also mentioned leave things the way they are but that is certainly out the window. -- moving the kernel webcam drivers out of the kernel and doing with these cameras _everything_ including webcam function through libusb. I myself do not have the imagination to be able to figure out how this could be done without a rather humongous amount of work (for example, which streaming apps that are currently available would be able to live with this?) but unless I misunderstand what he was saying, Greg K-H seems to think that this would be the best thing to do. I also don't think that this a good alternative. As Hans V. pointed, one of our long term targets is to create per-sensor I2C drivers that are independent from the bridges. Also, moving it to userspace would require lots of work with the duplication of V4L and gspca core into userspace for the devices that would be moved, and may have some performance impacts. A good argument, though it probably does not affect the devices on my list one way or the other. Which one of these possibile approaches gets adopted is a policy issue which I would consider is ultimately way above my pay grade. My main motivation for bringing up the issue was to get it to the front burner so that _something_ gets done. It is a matter which has been left alone for too long. Therefore, I am very glad that the matter is being addressed. Let me add to this that I have gotten permission for time off and for a expense money which might possibly cover my air fare. I hope to arrive in Vancouver by sometime on Monday and intend to attend the mini-summit. I suggest that we get all intersted parties together and figure out what is the best way to go. I hope everyone who is actively concerned can meet in Vancouver, and if all goes well then on Monday as well as Tuesday. I can hang around for another day or two after Tuesday, but I do not expect to register for LinuxCon or be involved in it. It will be great to have you there for those discussions. My take on this was that it seems to have become important for me to attend, which, frankly, I was not expecting. So thanks for the nice words. When I leave Vancouver I will probably go to Seattle and spend a couple of days with my oldest son, the musician, before coming home on the next weekend. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Workshop-2011] Media Subsystem Workshop 2011
On Tue, 9 Aug 2011, Hans de Goede wrote: Hi, On 08/08/2011 07:39 PM, Theodore Kilgore wrote: On Mon, 8 Aug 2011, Mauro Carvalho Chehab wrote: snip Mauro, In fact none of the currently known and supported cameras are using PTP. All of them are proprietary. They have a rather intimidating set of differences in functionality, too. Namely, some of them have an isochronous endpoint, and some of them rely exclusively upon bulk transport. Some of them have a well developed set of internal capabilities as far as handling still photos are concerned. I mean, such things as the ability to download a single photo, selected at random from the set of photos on the camera, and some do not, requiring that the ability to do this is emulated in software -- by first downloading all previously listed photos and sending the data to /dev/null, then downloading the desired photo and saving it. Some of them permit deletion of individual photos, or all photos, and some do not. For some of them it is even true, as I have previously mentioned, that the USB command string which will delete all photos is the same command used for starting the camera in streaming mode. But the point here is that these cameras are all different from one another, depending upon chipset and even, sometimes, upon firmware or chipset version. The still camera abilities and limitations of all of them are pretty much worked out in libgphoto2. My suggestion would be that the libgphoto2 support libraries for these cameras ought to be left the hell alone, except for some changes in, for example, how the camera is accessed in the first place (through libusb or through a kernel device) in order to address adequately the need to support both modes. I know what is in those libgphoto2 drivers because I wrote them. I can definitely promise that to move all of that functionality over into kernel modules would be a nightmare and would moreover greatly contribute to kernel bloat. You really don't want to go there. I strongly disagree with this. The libgphoto2 camlibs (drivers) for these cameras handle a number of different tasks: 1) Talking to the camera getting binary blobs out of them (be it a PAT or some data) 2) Interpreting said blobs 3) Converting the data parts to pictures doing post processing, etc. I'm not suggesting to move all of this to the kernel driver, we just need to move part 1. to the kernel driver. I did not assume otherwise. This is not rocket science. No, but both Adam and I realized, approximately at the same time yesterday afternoon, something which is rather important here. Gphoto is not developed exclusively for Linux. Furthermore, it has a significant user base both on Windows and on MacOS, not to mention BSD. It really isn't nice to be screwing around too much with the way it works. We currently have a really bad situation were drivers are fighting for the same device. The problem here is that these devices are not only one device on the physical level, but also one device on the logical level (IOW they have only 1 usb interface). All true. Which is why I brought the topic up for discussion in the first place and why it now gets on the program of the USB Summit. It is time to quit thinking in band-aides and solve this properly, 1 logical device means it gets 1 driver. This may be an approach which means some more work then others, but I believe in the end that doing it right is worth the effort. Clearly, we agree about doing it right is worth the effort. The whole discussion right now is about what is right. As for Mauro's resource locking patches, these won't work because the assume both drivers are active at the same time, which is simply not true. Only 1 driver can be bound to the interface at a time, and when switching from the gspca driver to the usbfs driver, gspca will see an unplug which is indistinguishable from a real device unplug. Things would not have to happen so, of course. Things did not used to happen so. Presence of kernel support for streaming used to block stillcam access through libusb. Period. End of discussion. The code change in libusb which changes that default behavior is quite recent. It was done because the kernel was *not* addressing the problem at all. That change could presumably be reversed if it were decided that the kernel is going to do the work instead. A POV could be defended, that this behavior of libusb was put in as a stopgap measure because the kernel was not doing its job. In which case the right thing to do is to put the missing functionality into the kernel drivers and take out from libusb the attempt to provide it, when libusb really can't do the job completely. More over a kernel only solution without libgphoto changes won't solve the problem of a libgphoto app keeping the device open locking out streaming. Eh? You really lose me
Re: [Workshop-2011] Media Subsystem Workshop 2011
On Tue, 9 Aug 2011, Hans de Goede wrote: Hi, snip OK, another example. The cameras supported in camlibs/jl2005c do not have webcam ability, but someone could at any time design and market a dualmode which has in stillcam mode the same severe limitation. What limitation? Well, the entire memory of the camera must be dumped, or else the camera jams itself. You can stop dumping in the middle of the operation, but you must continue after that. Suppose that you had ten pictures on the camera and you only wanted to download the first one. Then you can do that and temporarily stop downloading the rest. But while exiting you have to check whether the rest are downloaded or not. And if they are not, then it has to be done, with the data simply thrown in the trash, and then the camera's memory pointer reset before the camera is released. How, one might ask, did anyone produce something so primitive? Well, it is done. Perhaps the money saved thereby was at least in part devoted to producing better optics for the camera. At least, one can hope so. But people did produce those cameras, and people have bought them. But does anyone want to reproduce the code to support this kind of crap in the kernel? And go through all of the hoops required in order to fake the behavior which one woulld expect from a real still camera? It has already been done in camlibs/jl2005c and isn't that enough? This actually is an example where doing a kernel driver would be easier, a kernel driver never exits. So it can simply remember where it was reading (and cache the data it has read sofar). If an app requests picture 10, we read 1-10, cache them and return picture 10 to the app, then the same or another app asks for picture 4, get it from cache, asks for picture 20 read 11-20, etc. This, in fact, is the way that the OEM software for most of these cheap cameras works. The camera is dumped, and then raw files for the pictures are created in C:\TEMP. Then the raw files are all processed immediately into viewable pictures, after which thumbnails (which did not previously exist as separate entities) can be created for use in the GUI app. Then, if the user chooses to save certain of the photos, the chosen photos are merely copied to a more permanent location. And when the camera-accessing app is exited, the temporary files are all deleted. Clearly, the OEM approach recommends itself for simplicity. Nevertheless, there is an obvious disadvantage. Namely, *all* of the raw data from the camera needs to be fetched and, as you say, kept in cache. That cache is either going to use RAM, or is going to be based in swap. And not every piece of hardware is a big, honking system with plenty of gigabytes in the RAM slots, and moreover there exist systems with low memory where it is also considered not a good idea to use swap. Precisely because of these realities, the design of libgphoto2 has consciously rejected the approach used in the OEM drivers. Rather, it is a priority to lower the memory footprint by dealing with the data piece by piece. This means, essentially, handling the photos on the camera one at a time. It is worth considering that some of the aforementioned low-powered systems with low quantities of RAM on board, and with no allocated swap space are running Linux these days. Having written code for various small digital picture frames (the keychain models) I know where you are coming from. Trust me I do. Not to worry. I know where you are coming from, too. Trust me I do. Recently I had an interesting bug report, with a corrupt PAT (picture allocation table) turns out that when deleting a picture through the menu inside the frame a different marker gets written to the PAT then when deleting it with the windows software, Fun huh? Yes, of course it is fun. We should not have signed up to do this kind of work if we can't take a joke, right? But, more seriously, there may be some reason why that different character is used -- or OTOH maybe not, and somebody was just being silly. Unfortunately, experience tells me it is probably necessary to figure out which of the two possibilities it is. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB mini-summit at LinuxCon Vancouver
On Tue, 9 Aug 2011, Hans de Goede wrote:
Hi,
On 08/09/2011 04:19 PM, Alan Stern wrote:
On Tue, 9 Aug 2011, Hans de Goede wrote:
I would really like to see the dual mode camera and TV tuner discussion
separated. They are 2 different issues AFAIK.
1) Dual mode cameras:
In the case of the dual mode camera we have 1 single device (both at
the hardware level and at the logical block level), which can do 2 things,
but not at the same time. It can stream live video data from a sensor,
or it can retrieve earlier taken pictures from some picture memory.
Unfortunately even though these 2 functions live in a single logical
block,
historically we've developed 2 drivers for them. This leads to fighting
over device ownership (surprise surprise), and to me the solution is
very clear, 1 logical block == 1 driver.
According to Theodore, we have developed 5 drivers for them because the
stillcam modes in different devices use four different vendor-specific
drivers.
Yes, but so the the webcam modes of the different devices, so for
the 5 (not sure if that is the right number) dual-cam mode chipsets
we support there will be 5 drivers, each supporting both the
webcam and the access to pictures stored in memory of the chipset
they support. So 5 chipsets - 5 drivers each supporting 1 chipset,
and both functions of the single logical device that chipset
represents.
Does it really make sense to combine 5 drivers into one?
Right, that is not the plan. The plan is to simply stop having 2 drivers
for 1 logical (and physical) block. So we go from 10 drivers, 5 stillcam
+ 5 webcam, to just 5 drivers. We will also likely be able to share
code between the code for the 2 functionalities for things like generic
set / get register functions, initialization, etc.
Probably this is a good time for some inventory to be done.
sure of the exact number of drivers. The jeilinj driver does not count
here. It is a standard mass storage device as a still camera, and if it is
going to be hooked up as a webcam then it has to have some buttons pushed
just so, prior to hookup -- after which it comes up with a different USB
Product number as a proprietary webcam device, supported by the jeilinj
driver. Thus, this is not one of the droids we are looking for.
Specifically, the currently affected drivers are sq905, sq905c, mr97310a,
and sn9c2028.
Fuji Finepix seems to produce both still cameras (PTP protocol) and
webcams. If there are currently any dual-mode cameras, it is not obvious.
Perhaps any of these which can be dual mode are like the jeilinj cameras
and come up under different Product numbers in the different modes, which
is not a problem.
There do seem to exist stv06xx dual-mode cameras:
stv0680/stv0680.c: { STM:USB Dual-mode camera, 0x0553, 0x0202, 1
},
is found in camlibs/stv0680, for example, along with a whole bunch of
other cameras with the same Vendor:Product number. It seems, too, that the
same Vendor:Product number is listed in gspca/stv0680.c
So I guess we found another affected driver.
The intersection seems to be void between the lists of the spca50x cameras
and webcams, though one can not be certain about the future. I do know of
another dualmode camera, powered by the JL2005A chip. I wrote a kernel
module for it some months ago. Said module has not been sent upward
because of mysterious issues with one of the three cameras used for
testing it.
We also find among the gspca driver files this
* GSPCA sub driver for W996[78]CF JPEG USB Dual Mode Camera Chip.
*
* Copyright (C) 2009 Hans de Goede hdego...@redhat.com
but I am not sure about which cameras are using this.
Theodore Kilgore
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Workshop-2011] Media Subsystem Workshop 2011
On Tue, 9 Aug 2011, Hans de Goede wrote: Hi, On 08/09/2011 07:10 PM, Theodore Kilgore wrote: On Tue, 9 Aug 2011, Hans de Goede wrote: snip No, but both Adam and I realized, approximately at the same time yesterday afternoon, something which is rather important here. Gphoto is not developed exclusively for Linux. Furthermore, it has a significant user base both on Windows and on MacOS, not to mention BSD. It really isn't nice to be screwing around too much with the way it works. Right, so my plan is not to rip out the existing camlibs from libgphoto2, but to instead add a new camlib which talks to /dev/video# nodes which support the new to be defined v4l2 API for this. This camlib will then take precedence over the old libusb based ones when running on a system which has a new enough kernel. On systems without the new enough kernel the matching portdriver won't find any ports, so the camlib will be effectively disabled. And then, I assume you mean, the old camlib will still work. On BSD the port driver for this new /dev/video# API and the camlib won't even get compiled. snip It is time to quit thinking in band-aides and solve this properly, 1 logical device means it gets 1 driver. This may be an approach which means some more work then others, but I believe in the end that doing it right is worth the effort. Clearly, we agree about doing it right is worth the effort. The whole discussion right now is about what is right. I'm sorry but I don't get the feeling that the discussion currently is focusing on what is right. You are very impatient. To me too much attention is being spend on not throwing away the effort put in the current libgphoto2 camlibs, which I don't like for 2 reasons: 1) It distracts from doing what is right 2) It ignores the fact that a lot has been learned in doing those camlibs, really really a lot. and all that can be re-used in a kernel driver. Note that your two items can contradict or cancel each other out if one is not careful? Let me try to phrase it in a way I think you'll understand. If we agree on doing it right over all other things (such as the fact that doing it right may take a considerable effort). Then this could be an interesting assignment for some of the computer science students I used to be a lecturer for. This assignment could read something like Given the existing situation and knowledge describe all that here, do a re-design for the driverstack for these dual mode cameras, assuming a completely fresh start. Now if I were to give this assignment to a group of students, and they would keep coming back with the but re-doing the camlibs in kernelspace is such a large effort, and we already have them in userspace argument against using one unified driver for these devices, I would give them an F, because they are clearly missing the assuming a completely fresh start part of the assignment. Well, for one thing, Hans, we do not have here any instructor who is giving us an assignment. And nobody is in the position to specify that the assignment says assuming a completely fresh start -- unless Linus happens to be reading this thread and chimes in. Otherwise, unless there is a convincing demonstration that assuming a completely fresh start is an absolute and unavoidable necessity, someone is probably going to disagree. I'm sorry if this sounds a bit harsh, Yes, I am sorry about that, too. but this is the way how the current discussion feels to me. If we agree on aiming for doing it right then with that comes to me doing a software design from scratch, so without taking into account what is already there. Here, a counter-argument is to point out, as I did in a mail earlier this afternoon, that without taking account what is already there might possibly let one overlook something important. And, no, I am not referring to the userspace-kernelspace problem with this. I am referring to the fact that simply to dump the entire contents of the camera into cache (and to keep it there for quite a while) might not necessarily be a good idea and it had been quite consciously rejected to do that in the design of libgphoto2. Not because it is in userspace, but because to do that eats up and ties up RAM of which one cannot assume there is a surplus. Do not misunderstand, though. I am not even going so far as to say that libgphoto2 made the right decision. It certainly has its drawbacks, in that it places severe requirements on someone programming a driver for a really stupid camera. But what I *am* saying is that the issue was anticipated, the issue was faced, and a conscious decision was made. This is the opposite of not anticipating, not facing an issue, and not making any conscious decision. Oh, another example of such lack of deep thought has produced the current crisis, too. I am referring to the amazing decision of some user interface
Re: [Workshop-2011] Media Subsystem Workshop 2011
On Mon, 8 Aug 2011, Mauro Carvalho Chehab wrote: Em 07-08-2011 23:26, Theodore Kilgore escreveu: (first of two replies to Adam's message; second reply deals with other topics) On Sun, 7 Aug 2011, Adam Baker wrote: On Friday 05 August 2011, Hans de Goede wrote: This sounds to be a good theme for the Workshop, or even to KS/2011. Agreed, although we don't need to talk about this for very long, the solution is basically: 1) Define a still image retrieval API for v4l2 devices (there is only 1 interface for both functions on these devices, so only 1 driver, and to me it makes sense to extend the existing drivers to also do still image retrieval). 2) Modify existing kernel v4l2 drivers to provide this API 3) Write a new libgphoto driver which talks this interface (only need to do one driver since all dual mode cams will export the same API). 1) is something to discuss at the workshop. This approach sounds fine as long as you can come up with a definition for the API that covers the existing needs and is extensible when new cameras come along and doesn't create horrible inefficiencies by not matching the way some cameras work. I've only got one example of such a camera and it is a fairly basic one but things I can imagine the API needing to provide are 1) Report number of images on device 2) Select an image to read (for some cameras selecting next may be much more efficient than selecting at random although whether that inefficiency occurs when selecting, when reading image info or when reading image data may vary) 3) Read image information for selected image (resolution, compression type, FOURCC) 4) Read raw image data for selected image 5) Delete individual image (not supported by all cameras) 6) Delete all images (sometimes supported on cameras that don't support individual delete) I'm not sure if any of these cameras support tethered capture but if they do then add Take photo Set resolution I doubt if any of them support EXIF data, thumbnail images, the ability to upload images to the camera or any sound recording but if they do then those are additional things that gphoto2 would want to be able to do. Adam, Yipe. This looks to me like one inglorious mess. I do not know if it is feasible, or not, but I would wish for something much more simple. Namely, if the camera is not a dual-mode camera then nothing of this is necessary, of course. But if it is a dual-mode camera then the kernel driver is able to hand off the camera to a (libgphoto2-based) userspace driver which can handle all of the gory details of what the camera can do in its role as a still camera. This would imply that there is a device which libgphoto2 can access, presumably another device which is distinct from /dev/videoX, lets call it right now /dev/camX just to give it a name during the discussion. So then what happens ought to be something like the following: 1. Camera is plugged in, detected, and kernel module is fired up. Then either 2a. A streaming app is started. Then, upon request from outside the kernel, the /dev/videoX is locked in and /dev/camX is locked out. The camera streams until told to quit streaming, and in the meantime any access to /dev/camX is not permitted. When the streaming is turned off, the lock is released. or 2b. A stillcam app is started. Then similar to 2a, but the locking is reversed. I think that this kind of thing would keep life simple. As I understand what Hans is envisioning, it is pretty much along the same lines, too. It would mean, of course, that the way that libgphoto2 would access one of these cameras would be directly to access the /dev/camX provided by the kernel, and not to use libusb. But that can be done, I think. As I mentioned before, Hans has written several libgphoto2 drivers for digital picture frames which are otherwise seen as USB mass storage devices. Something similar would have to be done with dual-mode cameras. I will send a second reply to this message, which deals in particular with the list of abilities you outlined above. The point is, the situation as to that list of abilities is more chaotic than is generally realized. And when people are laying plans they really need to be aware of that. From what I understood from your proposal, /dev/camX would be providing a libusb-like interface, right? If so, then, I'd say that we should just use the current libusb infrastructure. All we need is a way to lock libusb access when another driver is using the same USB interface. Hans and Adam's proposal is to actually create a /dev/camX node that will give fs-like access to the pictures. As the data access to the cameras generally use PTP (or a PTP-like protocol), probably one driver will handle several
Re: [Workshop-2011] Media Subsystem Workshop 2011
On Mon, 8 Aug 2011, Alan Stern wrote: On Sun, 7 Aug 2011, Theodore Kilgore wrote: This indirectly answers my question, above, about whatever device there may or may not be. What I get from this, and also from a bit of snooping around, is that there is not any dev that gets created in order to be accessed by libusb. Just an entry under /proc/bus/usb, which AFAICT is at most a pseudo-device. Thanks. Nowadays, most distributions create device nodes under /dev/bus/usb. A few also support the old /proc/bus/usb files. What does this mean, exactly, in practice? You are right that I have the /dev/bus/usb/ files but does everybody have them, these days? So, Alan, what do you think is the best way to go about the problem? The camera can act as a stillcam or as a webcam. The problem is to provide access to both, with equal facility (and of course to lock out access to whichever action is not currently in use, if the other one is). The current situation with libusb does not cut it, as among other things it currently does only half the job and seemingly cannot address the locking problem. Alan, I do not know if you have actually followed what has been going on. One of the things which has been happening is that we have a real, immediate mess on our hands, in that some folks have put together distros which insist upon automatically mounting all stilcams whenever they are plugged in, thereby destroying the ability of any dual-mode camera to function as a webcam. This brilliant move seems to have been conceived in sin, or at least in total ignorance or disregard of the underlying problems, but it has been done and sold to the public as a convenience. So it seems to me that the infrastructural problem needs attention. Hans suggests to create two explicit devices, /dev/video (as already done and something like /dev/cam. Then access webcam function as now and stillcam function with libgphoto2, as now, but through /dev/cam instead of through libusb. This would seem to me to solve all the problems, but at the expense of some work. Can you think of something more clever? I'm not familiar with the MTP protocol used in the stillcam mode, or how feasible it would be to implement that protocol in a kernel driver. What? You, too? :-/ As I said to Mauro, all of the currently affected cameras that I know of are proprietary. And proprietary means what it says. It means that the protocol depends upon the controller chip in the camera, not upon any standard. And not just the commands, but also the methodologies and approaches which underlie the command structure can differ wildly. Maybe a good compromise would be to create a kind of stub driver that could negotiate the device access while still delegating most of the real work to userspace. Hooray. This appears to me to be a very good solution. This could become a bigger problem if this kind of design becomes an ongoing trend. To do what Hans was suggesting, today we have to merge two separate drivers... Actually, the current count is even worse. It is four drivers, not two. See previous remarks about proprietary protocols. then tomorrow we would have to merge two others and then later on even more. Before you know it, we would end up with a single gigantic kernel driver to manage every USB device! More exactly, a gillion kernel drivers, each one to control each proprietary device, and then, I suppose, one ring to rule them all ... But that is just as bad as your nightmare, so it makes no difference in the end, does it? Obviously not a sustainable approach in the long run. I agree approximately 120% with this. Let's think of a more clever way. If we get the basic idea right, it really ought not to be too terribly difficult. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB mini-summit at LinuxCon Vancouver
On Mon, 8 Aug 2011, Sarah Sharp wrote: On Fri, Aug 05, 2011 at 09:45:56AM +0200, Hans de Goede wrote: Hi, On 08/05/2011 12:56 AM, Greg KH wrote: On Thu, Aug 04, 2011 at 07:21:47PM -0300, Mauro Carvalho Chehab wrote: I think it is important to separate oranges from apples here, there are at least 3 different problem classes which all seem to have gotten thrown onto a pile here: 1) The reason Mauro suggested having some discussion on this at the USB summit is because of a discussion about dual mode cameras on the linux media list. ... 3) Re-direction of usb devices to virtual machines. This works by using the userspace usbfs interface from qemu / vmware / virtualbox / whatever. The basics of this work fine, but it lacks proper locking / safeguards for when a vm takes over a usb device from the in kernel driver. Hi Hans and Mauro, We have do room in the schedule for the USB mini-summit for this discussion, since the schedule is still pretty flexible. The preliminary schedule is up here: http://userweb.kernel.org/~sarah/linuxcon-usb-minisummit.html I think it's best to discuss the VM redirection in the afternoon when some of the KVM folks join us after Hans' talk on USB redirection over the network. It sounds like we need a separate topic for the dual mode cameras and TV tuners. Mauro, do you want to lead that discussion in the early morning (in a 9:30 to 10:30 slot) or in the late afternoon (in a 15:30 to 16:30 slot)? I want to be sure we have all the video/media developers who are interested in this topic present, and I don't know if they will be going to the KVM forum. Sarah, Alas. I would suspect that I am one of the people most interested in the topic of dual-mode cameras, since I have worked on supporting them both in libgphoto2 and in the kernel. But I teach in a university for a living, and the first classes of Fall Semester 2011 start on August 17 in Auburn, Alabama. Knowing this, I decided, months ago, that I simply could not attend a conference which starts on August 16 in Vancouver. So, after starting all of the current mailing-list discussion on the topic I will not be at the conference. I can only hope that those who do attend will keep me current about what gets discussed. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Workshop-2011] Media Subsystem Workshop 2011
On Mon, 8 Aug 2011, Mauro Carvalho Chehab wrote: Em 08-08-2011 14:39, Theodore Kilgore escreveu: On Mon, 8 Aug 2011, Mauro Carvalho Chehab wrote: Em 07-08-2011 23:26, Theodore Kilgore escreveu: (first of two replies to Adam's message; second reply deals with other topics) In summary, there are currently two proposals: 1) a resource lock for USB interface between V4L and libusb; 2) a PTP-like USB driver, plus a resource lock between V4L and the PTP-like driver. The same resource lock may also be implemented at libusb, in order to avoid concurrency. As you said that streaming on some cameras may delete all pictures from it, I suspect that (2) is the best alternative. Thanks, Mauro Mauro, In fact none of the currently known and supported cameras are using PTP. All of them are proprietary. They have a rather intimidating set of differences in functionality, too. Namely, some of them have an isochronous endpoint, and some of them rely exclusively upon bulk transport. Some of them have a well developed set of internal capabilities as far as handling still photos are concerned. I mean, such things as the ability to download a single photo, selected at random from the set of photos on the camera, and some do not, requiring that the ability to do this is emulated in software -- by first downloading all previously listed photos and sending the data to /dev/null, then downloading the desired photo and saving it. Some of them permit deletion of individual photos, or all photos, and some do not. For some of them it is even true, as I have previously mentioned, that the USB command string which will delete all photos is the same command used for starting the camera in streaming mode. But the point here is that these cameras are all different from one another, depending upon chipset and even, sometimes, upon firmware or chipset version. The still camera abilities and limitations of all of them are pretty much worked out in libgphoto2. My suggestion would be that the libgphoto2 support libraries for these cameras ought to be left the hell alone, except for some changes in, for example, how the camera is accessed in the first place (through libusb or through a kernel device) in order to address adequately the need to support both modes. I know what is in those libgphoto2 drivers because I wrote them. I can definitely promise that to move all of that functionality over into kernel modules would be a nightmare and would moreover greatly contribute to kernel bloat. You really don't want to go there. As to whether to use libusb or not to use libusb: It would be very nice to be able to keep using libusb to get access to these cameras, as then no change in the existing stillcam drivers would be required at all. Furthermore, if it were possible to solve all of the associated locking problems and to do it this way, it would be something that could be generalized to any analogous situation. This would be very nice. I can also imagine, of course, that such an approach might require changes in libusb. For example, the current ability of libusb itself to switch off a kernel device might possibly be a step in the wrong direction, and it might possibly be needed to move that function, somehow, out of libusb and into the kernel support for affected hardware. In the alternative, it ought to be possible for a libgphoto2 driver to hook up directly to a kernel-created device without going through libusb, and, as I have said in earlier messages, some of our driver code (for digital picture frames in particular) does just that. Then, whatever /dev entries and associated locking problems are needed could be handled by the kernel, and libgphoto2 talks to the device. But if things are done this way I strongly suggest that as little of the internals of the libgphoto2 driver are put in the kernel as it is possible to do. Be very economical about that, else there will be a big mess. Doing an specific libusb-like approach just for those cams seems to be the wrong direction, as such driver would be just a fork of an already existing code. I'm all against duplicating it. Well, in practice the fork would presumably be carried out by yours truly. Presumably with the advice and help of concerned parties. too. Since I am involved on both the kernel side and the libgphoto2 side of the support for the same cameras, it would certainly shorten the lines of communication at the very least. Therefore this is not infeasible. So, either we need to move the code from libgphoto2 to kernel As I said, I think you don't want to do that. or work into an approach that will make libusb (or an appropriate substitute) to return -EBUSY when a driver like V4L is in usage, and vice-versa. I never took a look on how libusb works. It seems
Re: [Workshop-2011] Media Subsystem Workshop 2011
On Mon, 8 Aug 2011, Alan Stern wrote: On Mon, 8 Aug 2011, Theodore Kilgore wrote: On Mon, 8 Aug 2011, Alan Stern wrote: On Sun, 7 Aug 2011, Theodore Kilgore wrote: This indirectly answers my question, above, about whatever device there may or may not be. What I get from this, and also from a bit of snooping around, is that there is not any dev that gets created in order to be accessed by libusb. Just an entry under /proc/bus/usb, which AFAICT is at most a pseudo-device. Thanks. Nowadays, most distributions create device nodes under /dev/bus/usb. A few also support the old /proc/bus/usb files. What does this mean, exactly, in practice? You are right that I have the /dev/bus/usb/ files but does everybody have them, these days? Pretty much everybody using udev should have them, which means pretty much every desktop system. OK, so far so good. ... Maybe a good compromise would be to create a kind of stub driver that could negotiate the device access while still delegating most of the real work to userspace. Hooray. This appears to me to be a very good solution. I'm not so sure. It would require vast changes to the userspace program, for example. Such as? I agree approximately 120% with this. Let's think of a more clever way. If we get the basic idea right, it really ought not to be too terribly difficult. The method Hans suggested was rather clunky. If it involves moving practically all of the gory details of the support of stillcam mode for individual dual-mode cameras into the kernel, then it certainly appears clunky to me, too. It also required drivers to know when the device was in use, which may be okay for a video driver but is not so practical for usb-storage (although to be fair, I suspect usb-storage wouldn't need to be involved). Yes, I can see that. Usb-storage is, essentially, in use while the device is attached, and that has to be true because the device is a storage device. And alas, not all storage devices even get mounted, so one cannot decide whether the device is in use just by checking whether or not something on it is mounted ... And it required kernel drivers to inform user programs somehow when they want to get control of the device back, Why, exactly? I mean, fundamentally we have two functionalities of the device which are accessed, at the user level, by two userspace programs. One of them gets the still photos off the camera, and the other one gets the video stream. Perhaps we just need a method for saying No! to either one of those apps if the other one is using the camera? which is not the sort of thing drivers normally have to do. Even if we could come up with a way to let the video driver somehow share ownership of the device with usbfs, we'd still have to set up a protocol for deciding who was in charge at any given time. Would it be okay for the userspace program simply to say I want control now and I'm done, you can have control back? Actually, I would expect that if one program is accessing the device then the other one can't, and this works the same in both directions. Unless you think that what you described is better? For that matter, what should the video driver do if the user program crashes or hangs while in charge of the device? Good one. Commit seppuku? Seriously, though, what should it do if a video streaming userspace program crashes or hangs? Probably, the same thing should happen as it should if a photo-getting program crashes or hangs. Namely whatever needs to be done in order to prevent some kind of catastrophe ought to be implemented. Incidentally, I think that in some respects the fact that webcam support is in the kernel and stillcam support is in userspace is a red herring. The fundamental problem is a piece of hardware which does two different kinds of things which require two different kinds of support. Further to narrow this, though, it is hardware which needs to be usable for either function at any time, which does distinguish it from such things as a one-shot loading of firmware as happens with mass storage USB modems. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Workshop-2011] Media Subsystem Workshop 2011
On Mon, 8 Aug 2011, Adam Baker wrote: On Monday 08 August 2011, Mauro Carvalho Chehab wrote: Well, in practice the fork would presumably be carried out by yours truly. Presumably with the advice and help of concerned parties. too. Since I am involved on both the kernel side and the libgphoto2 side of the support for the same cameras, it would certainly shorten the lines of communication at the very least. Therefore this is not infeasible. Forking the code just because we have something special is the wrong thing to do (TM). I would not like to fork V4L core code due to some special need, but instead to add some glue there to cover the extra case. Maintaining a fork is bad in long term, as the same fixes/changes will likely be needed on both copies. Unfortunately there is some difficulty with libusb in that respect. libgphoto relies upon libusb-0.1 becuase it is cross platform and Win32 support in libusb-1.0 is only just being integrated. The libusb developers consider the libusb-0.1 API frozen and are not willing to extend it to address our problem. libusb doesn't expose the file descriptor it uses to talk to the underlying device so it is hard to extend the interface without forking libusb (The best hope I can think of at the moment is to get the distros to accept a patch for it to add the extra required API call(s) and for libgphoto to use the extra features in that patch if it detects it is supported at compile time). Adam, Yes, you are quite correct about this. I was just on the way out of the house and remembered that this problem exists, decided to re-connect and add this point to the witches' brew that we are working on. What struck me was not the Windows support, though, it was the Mac support. And a number of people run Gphoto stuff on Mac, too. That just reinforces your point, of course. Gphoto is explicitly cross-platform. It is developed on Linux but it is supposed to compile on anyone's C compiler and run on any hardware platform or operating system which has available the minimal support require to make it work. You are right. We, basically, can not screw with the internals of libgphoto2. At the outside, one can not go to the point where any changes would break the support for other platforms. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Workshop-2011] Media Subsystem Workshop 2011
On Mon, 8 Aug 2011, Adam Baker wrote: On Monday 08 August 2011, Mauro Carvalho Chehab wrote: I will send a second reply to this message, which deals in particular with the list of abilities you outlined above. The point is, the situation as to that list of abilities is more chaotic than is generally realized. And when people are laying plans they really need to be aware of that. From what I understood from your proposal, /dev/camX would be providing a libusb-like interface, right? If so, then, I'd say that we should just use the current libusb infrastructure. All we need is a way to lock libusb access when another driver is using the same USB interface. I think adding the required features to libusb is in general the correct approach however some locking may be needed in the kernel regardless to ensure a badly behaved libusb or libusb user can't corrupt kernel state. Hans and Adam's proposal is to actually create a /dev/camX node that will give fs-like access to the pictures. As the data access to the cameras generally use PTP (or a PTP-like protocol), probably one driver will handle several different types of cameras, so, we'll end by having one different driver for PTP than the V4L driver. I'm not advocating this approach, my post was intended as a straw man to allow the advantages and disadvantages of such an approach to be considered by all concerned. I suspected it would be excessively complex but I don't know enough about the various cameras to be certain. Fair enough. Go and have a look at the code in the various subdirectories of libgphoto2/camlibs, and you will see. Also consider that some of those subdirectories do not support currently-supported dual-mode cameras, but some of the ways of doing things that are present there could be applied to any dual-mode camera in the future. A prime example of what I mean can be seen in camlibs/aox. Those cameras are very old now and they probably will never be fully supported. They can download plain bitmap photos, or they can use some kind of compression which is not figured out. They can, as I recall, be run as webcams, too, and then they will presumably use that weird compression. But what is immediately interesting is that in still mode there is no allocation table, or at least none is downloaded. Everything about how many images and what kind of images and what size are they can be read out of a downloaded allocation table on most cameras, but not on these. No. One has to send a sequence of commands and parse the responses to them in order to get the information. I merely mention this example in order to point up the actual complexity of the situation, and the necessity not to make sweeping assumptions about how the camera is supposed to work. Be assured, that already happened when Gphoto was set up, and it made some of these cameras rather hard to support. Why? Well, it was set up with the assumption that all still cameras will do X, and Y, and Z. But be assured that someone either has or will design a still camera which is not capable of doing X, nor Y, nor Z, nor, even, all three of them, at least not in the way envisioned in someone's grand design. OK, another example. The cameras supported in camlibs/jl2005c do not have webcam ability, but someone could at any time design and market a dualmode which has in stillcam mode the same severe limitation. What limitation? Well, the entire memory of the camera must be dumped, or else the camera jams itself. You can stop dumping in the middle of the operation, but you must continue after that. Suppose that you had ten pictures on the camera and you only wanted to download the first one. Then you can do that and temporarily stop downloading the rest. But while exiting you have to check whether the rest are downloaded or not. And if they are not, then it has to be done, with the data simply thrown in the trash, and then the camera's memory pointer reset before the camera is released. How, one might ask, did anyone produce something so primitive? Well, it is done. Perhaps the money saved thereby was at least in part devoted to producing better optics for the camera. At least, one can hope so. But people did produce those cameras, and people have bought them. But does anyone want to reproduce the code to support this kind of crap in the kernel? And go through all of the hoops required in order to fake the behavior which one woulld expect from a real still camera? It has already been done in camlibs/jl2005c and isn't that enough? Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Workshop-2011] Media Subsystem Workshop 2011
(first of two replies to Adam's message; second reply deals with other topics) On Sun, 7 Aug 2011, Adam Baker wrote: On Friday 05 August 2011, Hans de Goede wrote: This sounds to be a good theme for the Workshop, or even to KS/2011. Agreed, although we don't need to talk about this for very long, the solution is basically: 1) Define a still image retrieval API for v4l2 devices (there is only 1 interface for both functions on these devices, so only 1 driver, and to me it makes sense to extend the existing drivers to also do still image retrieval). 2) Modify existing kernel v4l2 drivers to provide this API 3) Write a new libgphoto driver which talks this interface (only need to do one driver since all dual mode cams will export the same API). 1) is something to discuss at the workshop. This approach sounds fine as long as you can come up with a definition for the API that covers the existing needs and is extensible when new cameras come along and doesn't create horrible inefficiencies by not matching the way some cameras work. I've only got one example of such a camera and it is a fairly basic one but things I can imagine the API needing to provide are 1) Report number of images on device 2) Select an image to read (for some cameras selecting next may be much more efficient than selecting at random although whether that inefficiency occurs when selecting, when reading image info or when reading image data may vary) 3) Read image information for selected image (resolution, compression type, FOURCC) 4) Read raw image data for selected image 5) Delete individual image (not supported by all cameras) 6) Delete all images (sometimes supported on cameras that don't support individual delete) I'm not sure if any of these cameras support tethered capture but if they do then add Take photo Set resolution I doubt if any of them support EXIF data, thumbnail images, the ability to upload images to the camera or any sound recording but if they do then those are additional things that gphoto2 would want to be able to do. Adam, Yipe. This looks to me like one inglorious mess. I do not know if it is feasible, or not, but I would wish for something much more simple. Namely, if the camera is not a dual-mode camera then nothing of this is necessary, of course. But if it is a dual-mode camera then the kernel driver is able to hand off the camera to a (libgphoto2-based) userspace driver which can handle all of the gory details of what the camera can do in its role as a still camera. This would imply that there is a device which libgphoto2 can access, presumably another device which is distinct from /dev/videoX, lets call it right now /dev/camX just to give it a name during the discussion. So then what happens ought to be something like the following: 1. Camera is plugged in, detected, and kernel module is fired up. Then either 2a. A streaming app is started. Then, upon request from outside the kernel, the /dev/videoX is locked in and /dev/camX is locked out. The camera streams until told to quit streaming, and in the meantime any access to /dev/camX is not permitted. When the streaming is turned off, the lock is released. or 2b. A stillcam app is started. Then similar to 2a, but the locking is reversed. I think that this kind of thing would keep life simple. As I understand what Hans is envisioning, it is pretty much along the same lines, too. It would mean, of course, that the way that libgphoto2 would access one of these cameras would be directly to access the /dev/camX provided by the kernel, and not to use libusb. But that can be done, I think. As I mentioned before, Hans has written several libgphoto2 drivers for digital picture frames which are otherwise seen as USB mass storage devices. Something similar would have to be done with dual-mode cameras. I will send a second reply to this message, which deals in particular with the list of abilities you outlined above. The point is, the situation as to that list of abilities is more chaotic than is generally realized. And when people are laying plans they really need to be aware of that. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Workshop-2011] Media Subsystem Workshop 2011
On Sun, 7 Aug 2011, Alan Stern wrote: On Sun, 7 Aug 2011, Adam Baker wrote: I've addec Hans de Geode and linux-usb to the CC as this response picks up on a related discussion about the usb mini summit. On Friday 05 August 2011, Theodore Kilgore wrote: If you can solve the locking problem between devices in the kernel then it shouldn't matter if one of the kernel devices is the generic device that is used to support libusb. Hmmm. Perhaps not. While we are on the topic, what exactly do you mean by the generic device that is used to support libusb. Which device is that, exactly? The file drivers/usb/core/devio.c registers itself as a driver called usb_device which is used to provide all of the device drivers that live under /proc/bus/usb Let's get things correct. The driver is called usbfs, not usb_device. The things that live under /proc/bus/usb are files representing USB devices, not device drivers. This indirectly answers my question, above, about whatever device there may or may not be. What I get from this, and also from a bit of snooping around, is that there is not any dev that gets created in order to be accessed by libusb. Just an entry under /proc/bus/usb, which AFAICT is at most a pseudo-device. Thanks. So, Alan, what do you think is the best way to go about the problem? The camera can act as a stillcam or as a webcam. The problem is to provide access to both, with equal facility (and of course to lock out access to whichever action is not currently in use, if the other one is). The current situation with libusb does not cut it, as among other things it currently does only half the job and seemingly cannot address the locking problem. Hans suggests to create two explicit devices, /dev/video (as already done and something like /dev/cam. Then access webcam function as now and stillcam function with libgphoto2, as now, but through /dev/cam instead of through libusb. This would seem to me to solve all the problems, but at the expense of some work. Can you think of something more clever? Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Workshop-2011] Media Subsystem Workshop 2011
On Fri, 5 Aug 2011, Hans de Goede wrote: Hi all, On 08/04/2011 02:34 PM, Mauro Carvalho Chehab wrote: Em 03-08-2011 20:20, Theodore Kilgore escreveu: snip snip Yes, that kind of thing is an obvious problem. Actually, though, it may be that this had just better not happen. For some of the hardware that I know of, it could be a real problem no matter what approach would be taken. For example, certain specific dual-mode cameras will delete all data stored on the camera if the camera is fired up in webcam mode. To drop Gphoto suddenly in order to do the videoconf call would, on such cameras, result in the automatic deletion of all photos on the camera even if those photos had not yet been downloaded. Presumably, one would not want to do that. So, in other words, the Kernel driver should return -EBUSY if on such cameras, if there are photos stored on them, and someone tries to stream. Agreed. Here, too. Not only that, but also -EBUSY needs to be returned if streaming is being done and someone tries to download photos (cf. yesterday's exchange between me and Adam Baker, where it was definitely established that this currently leads to bad stuff happening). IMO, the right solution is to work on a proper snapshot mode, in kernelspace, and moving the drivers that have already a kernelspace out of Gphoto. Well, the problem with that is, a still camera and a webcam are entirely different beasts. Still photos stored in the memory of an external device, waiting to be downloaded, are not snapshots. Thus, access to those still photos is not access to snapshots. Things are not that simple. Yes, stored photos require a different API, as Hans pointed. I think that some cameras just export them as a USB storage. Erm, that is not what I tried to say, or do you mean another Hans? For the record, this one didn't come from me, either. :-) snip snip If I understood you well, there are 4 possible ways: 1) UVC + USB mass storage; 2) UVC + Vendor Class mass storage; 3) Vendor Class video + USB mass storage; 4) Vendor Class video + Vendor Class mass storage. Actually the cameras Theodore and I are talking about here all fall into category 4. Currently true, yes. I expect devices which do any of 1-3 to properly use different interfaces for this, actually the different class specifications mandate that they use different interfaces for this. As is well known, *everybody* obeys the class specifications, too. Always did, and always will. And Linus says that he got the original kernel from the Tooth Fairy, and because he said that we all believe him. The point being, trouble will very likely come along. I think Mauro is right at least to consider the possibility. This sounds to be a good theme for the Workshop, or even to KS/2011. Agreed, although we don't need to talk about this for very long, the solution is basically: 1) Define a still image retrieval API for v4l2 devices (there is only 1 interface for both functions on these devices, True so only 1 driver, and to me it makes sense to extend the existing drivers to also do still image retrieval). 2) Modify existing kernel v4l2 drivers to provide this API 3) Write a new libgphoto driver which talks this interface (only need to do one driver since all dual mode cams will export the same API). Yes, we pretty much agree that this is probably a good way to proceed. However, my curiosity is aroused by something that Adam mentioned yesterday. Namely If you can solve the locking problem between devices in the kernel then it shouldn't matter if one of the kernel devices is the generic device that is used to support libusb. I am not completely sure of what he meant here. I am not intimately conversant with the internals of libusb. However, is there something here which could be used constructively? Could things be set up so that, for example, the kernel module hands the generic device over to libusb? If it were possible to do things that way, it might be the most minimally disruptive approach of all, since it might not require much if any changes in libgphoto2 access to cameras. 1) is something to discuss at the workshop. Regards, Hans Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB mini-summit at LinuxCon Vancouver
On Fri, 5 Aug 2011, Oliver Neukum wrote:
Am Freitag, 5. August 2011, 00:56:03 schrieb Greg KH:
On Thu, Aug 04, 2011 at 07:21:47PM -0300, Mauro Carvalho Chehab wrote:
I know that this problem were somewhat solved for 3G modems, with the
usage
of the userspace problem usb_modeswitch, and with some quirks for the USB
storage driver, but I'm not sure if such tricks will scale forever, as
more
functions are seen on some USB devices.
Well, no matter how it scales it needs to be done in userspace, like
usb_modeswitch does. We made that decision a while ago, and it is
working out very well. I see no reason why you can't do it in userspace
as well as that is the easiest place to control this type of thing.
I thought we had a long discussion about this topic a while ago and came
to this very conclusion. Or am I mistaken?
Circumstances change. We want to keep the stuff in user space as much and
as long as we can. However user space has limitations:
- it has by necessity a race between resumption and access by others
- it cannot resume anything we run a (rw) filesystem over.
Furthermore, today PM actions that lead to a loss of mode are initiated
by user space. If we ever want to oportunistically suspend a system
we also need to restore mode from inside the kernel.
We could avoid all that trouble, if we persuaded vendors to use plain
USB configurations for those purposes.
But that would happen, I suspect, in an alternate universe. Better to
anticipate the trouble, I suspect. :-{
Moreover, the spark for the current discussion was the problem of
dual-mode cameras, which can work both as webcams and stillcams, not the
3G modems that you mention. The problems are analogous but not identical.
-- dual-mode cameras are, typically, Class Proprietary devices in
all of their functions. None of them that I know of are Mass Storage
devices. Therefore, usb_modeswitch would have to be rewritten completely
in order to be used for such hardware. As things stand right now, it has
nothing at all to do with the problem. Not to say, of course, that the
experience gained with usb_modeswitch is totally irrelevant.
-- I don't have one of those modems, but I have the impression
that the need to access the disk partition on one of them is basically a
one-shot deal. Namely, one needs to load some firmware or so on the disk
before the gadget can be used. The problem with a dual-mode camera is that
the user ought to be able to switch at will between a
download-the-pictures stillcam application and a stream application.
While, of course, not being able to start one of these activities while
the other is going on, because that would cause obvious trouble.
The similarity of the modem-and-mass-storage device and the web-and-still
camera is, of course, that both partake of being devices that will do more
than one kind of thing and they need to be supported in that respect.
Other hardware exists with similar characteristics, but sometimes the
functionaliy is not dual but even triple, and one can reasonably suspect
that more of this kind of thing is going to come at us in the future. I
think it is a good occasion to sit back and think things over a bit.
Theodore Kilgore
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Media Subsystem Workshop 2011
On Thu, 4 Aug 2011, Mauro Carvalho Chehab wrote: Em 04-08-2011 15:37, Theodore Kilgore escreveu: Yes, that kind of thing is an obvious problem. Actually, though, it may be that this had just better not happen. For some of the hardware that I know of, it could be a real problem no matter what approach would be taken. For example, certain specific dual-mode cameras will delete all data stored on the camera if the camera is fired up in webcam mode. To drop Gphoto suddenly in order to do the videoconf call would, on such cameras, result in the automatic deletion of all photos on the camera even if those photos had not yet been downloaded. Presumably, one would not want to do that. Some of the sq905 cameras in particular will do this. It depends upon the firmware version. Indeed, for those which do, the same USB command which starts streaming is exploited in the Gphoto driver for deletion of all photos stored on the camera. For the other firmware versions, there is in fact no way to delete all the photos, except to push buttons on the camera case. This is by the way a typical example of the very rudimentary, minimalist interface of some of these cheap cameras. So, in other words, the Kernel driver should return -EBUSY if on such cameras, if there are photos stored on them, and someone tries to stream. Probably, this should work the other way around, too. If not, then there is the question of closing the streaming in some kind of orderly fashion. Yes. IMO, the right solution is to work on a proper snapshot mode, in kernelspace, and moving the drivers that have already a kernelspace out of Gphoto. Well, the problem with that is, a still camera and a webcam are entirely different beasts. Still photos stored in the memory of an external device, waiting to be downloaded, are not snapshots. Thus, access to those still photos is not access to snapshots. Things are not that simple. Yes, stored photos require a different API, as Hans pointed. Yes again. His observations seem to me to be saying exactly the same thing that I did. I think that some cameras just export them as a USB storage. For those, we may eventually need some sort of locking between the USB storage and V4L. I can imagine that this could be the case. Also, to be entirely logical, one might imagine that a PTP camera could be fired up in streaming mode, too. I myself do not know of any cameras which are both USB storage and streaming cameras. In fact, as I understand the USB classes, such a thing would be in principle forbidden. It is possible to use a single USB ID, and having two (or more) interfaces there, each belonging to a different USB class. True. However, unfortunate exceptions are found in the set of sq905 cameras and sq905c cameras, which have only Interface 0 (and, of course, use only Bulk Transport for all data regardless of its nature). Anyway, while abstracting the proper solution, it is safer to consider it as a possible scenario. However, the practical consequence could be that sooner or later someone is going to do just that and that deviant hardware is going to sell like hotcakes and we are going to get pestered. Yes. That's said, there is a proposed topic for snapshot buffer management. Maybe it may cover the remaining needs for taking high quality pictures in Kernel. Again, when downloading photo images which are _stored_ on the camera one is not taking high quality pictures. Different functionality is involved. This may involve, for example, a different Altsetting for the USB device and may also require the use of Bulk transport instead of Isochronous transport. Ok. The gspca driver supports it already. All we need to do is to implement a proper API for retrieving still photos. Yes, I believe that Hans has some idea to do something like this: 1. kernel module creates a stillcam device as well as a /dev/video, for those cameras for which it is appropriate 2. libgphoto2 driver is modified so as to access /dev/camera through the kernel, instead of talking to the camera through libusb. Hans has written some USB Mass Storage digital picture frame drivers for Gphoto, which do something similar. The above strategy seems OK for me. The hole idea is to allocate additional buffers for snapshots, imagining that the camera may be streaming in low quality/low resolution, and, once snapshot is requested, it will take one high quality/high resolution picture. The ability to take a photo is present on some still cameras and not on others. Some still cameras includes some dual-mode cameras. For dual-mode cameras which can be requested to take a photo while running in webcam mode, the ability to do so is, generally speaking, present in the kernel driver. To present
Re: [Workshop-2011] Media Subsystem Workshop 2011
On Thu, 4 Aug 2011, Adam Baker wrote: On Thursday 04 August 2011, Theodore Kilgore wrote: As far as I know, /dev/sdx signifies a device which is accessible by something like the USB mass storage protocols, at the very least. So, if that fits the camera, fine. But most of the cameras in question are Class Proprietary. Thus, not in any way standard mass storage devices. Then it is probably better not to call the new device by that name unless that name really fits. Probably, it would be better to have /dev/cam or /dev/stillcam, or something like that. Correct and that is why this idea doesn't work - /dev/sdx needs to be a block device that can have a file system on it. These cameras don't have a traditional file system and there is a lot of code in gphoto to support all the different types of camera. There does exist the possibility of a relatively simple fix - If libusb include a usb_reattach_kernel_driver_np call to go with the usb_detach_kernel_driver_np then once gphoto had finished with the device it could restore the kernel driver and webcam mode would work. Unfortunately the libusb devs don't want to support it in the 0.1 version of libusb that everyone uses and the reattach function needs knowledge of libusb internals to work reliably. I did come up with a hack that sort of worked but I never worked out how to clean it up to be acceptable to go upstream. http://old.nabble.com/Re-attaching-USB-kernel-drivers-detached-by-libgphoto2- td22978838.html http://libusb.6.n5.nabble.com/re-attaching-after-usb-detach-kernel-driver-np- td6068.html Adam Baker Adam, (without looking at the details of your code) I agree that something like fixing libusb to reattach a kernel driver would partially alleviate the immediate problem of dual-mode cameras. 1. It would provide immediate relief to those people who are afflicted with the shortsightedness of some of the user friendly distros, which have set up a rule that every camera supported by Gphoto will be opened for download of photos as soon as it ls plugged in and the result is that no dual-mode camera can be used in webcam mode -- unless the user knows how to go and fix the mess. 2. It would solve a lot of existing problems for lots of other people. Therefore, I have favored this approach myself, sometimes in the past. The problems, as I see it (partly after some education from people like Hans de Goede), are the following: 1. No locking, and no error-handling. -- What if the user is downloading photos and gets a videoconference telephone call? What if the user, just for fun, starts up a webcam app, at the same time? Well, you might say, it can't start up because the /dev/video is disabled so we are home free on that one. But then -- What if it is the other way around, and the webcam interface is active, and the user (or some idiot automated software like what I mentioned above!) decides to start up the stillcam apps? What then? Does libusb just cut off the /dev/videoX device in the middle of things? 2. This adaptation to libusb solves the specific problem of handling dual-mode hardware for which one of the modes is handled by the kernel and the other mode is handled in userspace, through libusb. The further refinement of libusb addresses only this problem, not the general problem of dual-mode or triple-mode hardware, in the case that all functionality of the hardware is addressed through the kernel. Therefore, your solution ends up being a partial cure to a general problem, not a general cure for a general problem. Further, it is much easier to solve the locking issues which arise if the basic access to the hardware is through the kernel for all of its functionality. Thus, while originally favoring your approach, my position is at this point more in the direction that something needs to be done about this at the level of the kernel. As I said, others have convinced me of this, mainly Hans, because at first I thought your way of doing it was plenty good enough. Thanks for joining the debate, Adam, even though I just gave an opinion that you don't have the most optimal solution. I think that this problem has gone on long enough, and we all need to get together and fix it. Seriously. Cheers, Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Workshop-2011] Media Subsystem Workshop 2011
On Thu, 4 Aug 2011, Adam Baker wrote: On Thursday 04 August 2011, Mauro Carvalho Chehab wrote: That'd also be my understanding. There are already several standard ways to access data on still cameras: mass-storage, PTP, MTP, why invent Yet Another One? Just learn to share a device between several existing drivers. For those that can export data into some fs-like way, this may be the better way. It seems that gvfs does something like that. I've no idea how easy or difficult would be to write Kernel driver for it. As I understand it gvfs uses libgphoto2 and fuse and it is the interface libghoto2 that is the problem. This is correct. Except that the problem is not in libgphoto2 per se, but is at an even lower level. It could be said that the problem is in libusb, because libghoto2 uses libusb. So maybe the solution is to fix up libusb. Or, as I have come recently to think, maybe not. In any event, neither use nor avoidance of gvfs has much of anything to do with the problem at hand. But the problem exists with it or without it. libgphoto2 contains lots of the same sort of code to handle strange data formats from the camera as libv4l so I don't think we want to be moving that code back into the kernel.(The old out of kernel driver for sq905 before Theodore and I rewrote it contained code to do Bayer decoding and gamma correction that was copied from libgphoto2). This is all very much true. Moreover, I do not think that anyone has the idea to put any of that kind of code back into the kernel. But, just in case that anyone is thinking of possible overlap between what is done in libv4l and libgphoto2, someone should point out that things like Bayer demosaicing and gamma correction are not necessarily done the same way in the two libraries. Why is that? Well, it is true because one of the libraries supports streaming and the other one supports still cameras. Thus, the Bayer demosaicing functions in libv4l are optimized for speed, which will directly affect the frames per second rate. The Bayer demosaicing functions in libusb are intended to process image data from still cameras. For a still camera, frame rate is irrelevant and meaningless. Therefore the priority is, or ought to be, to get the best possible image out of the downloaded image data. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Media Subsystem Workshop 2011
On Thu, 4 Aug 2011, Mauro Carvalho Chehab wrote: Em 04-08-2011 18:16, Theodore Kilgore escreveu: This sounds to be a good theme for the Workshop, or even to KS/2011. Thanks. Do you recall when and where is KS/2011 going to take place? The media workshop happens together with the KS/2011. Sunday is an exclusive day for the workshops, Monday is an exclusive day for KS/2011, and Tuesday is a joint day for both KS and the KS workshops. So, as I understand, these are all about to take place in Vancouver, sometime in the next two weeks? It really is the wrong time, but I really wish now that I were going. I would at the very minimum try to get the people together that I know of, who have wrestled with the issue. Hmm... it seems that you didn't read the sites I've pointed on my original email, Not really, no. I had resigned myself to being unable to attend anything like this, so why torture myself with looking in the shop window at what I cannot buy? or that I was not clear enough. Without looking again, I expect that you were quite clear. The Media Subsystem Workshop and the Kernel Summit won't happen in Vancouver. What will happen there is the LinuxCon North-America, plus the USB mini-summit. I should be there, btw. I think I should add an additional topic there to discuss about multi-featured devices. A very good idea. The KS/2011 and the Media Workshop will happen in Prague, on Oct 23-25, just before the LinuxCon Europe. Hmmm. That is still not good because classes are in session. But it is not nearly so bad in the middle of a semester as it is at the beginning. It is even conceivable that I might be able to shake loose some money -- if I were either giving a presentation or would (for example) lead a panel discussion on this topic. I believe that I would find it easier to be a moderator or discussion leader than actually to present about a thing like this. Namely, I can see the issues but not always the solutions. Probably, it is not good to apply to my university for money if I merely were going to attend; mere intent to attend would probably not get me funding for a mathematics conference, either. I also would need enough lead time to be able to get things through the bureaucratic system. There is some kind of very unreasonable deadline now in effect in the university about how soon one needs to apply for foreign travel. So if you think my presence would have some value, I need something to get the application started, over here. Invitation, or something similar. If it is too much trouble or would interfere with already-existing plans, then never mind. I would hardly be upset if I don't go to something which I was not expecting to go to in the first place. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Workshop-2011] Media Subsystem Workshop 2011
On Fri, 5 Aug 2011, Adam Baker wrote: On Thursday 04 August 2011, Theodore Kilgore wrote: On Thu, 4 Aug 2011, Adam Baker wrote: On Thursday 04 August 2011, Theodore Kilgore wrote: As far as I know, /dev/sdx signifies a device which is accessible by something like the USB mass storage protocols, at the very least. So, if that fits the camera, fine. But most of the cameras in question are Class Proprietary. Thus, not in any way standard mass storage devices. Then it is probably better not to call the new device by that name unless that name really fits. Probably, it would be better to have /dev/cam or /dev/stillcam, or something like that. Correct and that is why this idea doesn't work - /dev/sdx needs to be a block device that can have a file system on it. These cameras don't have a traditional file system and there is a lot of code in gphoto to support all the different types of camera. There does exist the possibility of a relatively simple fix - If libusb include a usb_reattach_kernel_driver_np call to go with the usb_detach_kernel_driver_np then once gphoto had finished with the device it could restore the kernel driver and webcam mode would work. Unfortunately the libusb devs don't want to support it in the 0.1 version of libusb that everyone uses and the reattach function needs knowledge of libusb internals to work reliably. I did come up with a hack that sort of worked but I never worked out how to clean it up to be acceptable to go upstream. http://old.nabble.com/Re-attaching-USB-kernel-drivers-detached-by-libgpho to2- td22978838.html http://libusb.6.n5.nabble.com/re-attaching-after-usb-detach-kernel-driver -np- td6068.html Adam Baker Adam, (without looking at the details of your code) I agree that something like fixing libusb to reattach a kernel driver would partially alleviate the immediate problem of dual-mode cameras. 1. It would provide immediate relief to those people who are afflicted with the shortsightedness of some of the user friendly distros, which have set up a rule that every camera supported by Gphoto will be opened for download of photos as soon as it ls plugged in and the result is that no dual-mode camera can be used in webcam mode -- unless the user knows how to go and fix the mess. 2. It would solve a lot of existing problems for lots of other people. Therefore, I have favored this approach myself, sometimes in the past. The problems, as I see it (partly after some education from people like Hans de Goede), are the following: 1. No locking, and no error-handling. -- What if the user is downloading photos and gets a videoconference telephone call? What if the user, just for fun, starts up a webcam app, at the same time? Well, you might say, it can't start up because the /dev/video is disabled so we are home free on that one. But then -- What if it is the other way around, and the webcam interface is active, and the user (or some idiot automated software like what I mentioned above!) decides to start up the stillcam apps? What then? Does libusb just cut off the /dev/videoX device in the middle of things? It does look as though there might be an issue here - the IOCTL that libusb uses calls usb_driver_release_interface in drivers/core/usb/devio.c, the definition of that function says Callers must own the device lock but as far as I can see it won't and a quick test running gphoto2 -L while streaming video does indicate it is making a severe mess of things. I haven't tried it myself. It is one of those things that all by myself I would never have thought of testing. But I am certainly not surprised at the result. 2. This adaptation to libusb solves the specific problem of handling dual-mode hardware for which one of the modes is handled by the kernel and the other mode is handled in userspace, through libusb. The further refinement of libusb addresses only this problem, not the general problem of dual-mode or triple-mode hardware, in the case that all functionality of the hardware is addressed through the kernel. Therefore, your solution ends up being a partial cure to a general problem, not a general cure for a general problem. Further, it is much easier to solve the locking issues which arise if the basic access to the hardware is through the kernel for all of its functionality. If you can solve the locking problem between devices in the kernel then it shouldn't matter if one of the kernel devices is the generic device that is used to support libusb. Hmmm. Perhaps not. While we are on the topic, what exactly do you mean by the generic device that is used to support libusb. Which device is that, exactly? Thus, while originally favoring your approach, my position is at this point more in the direction that something needs to be done
Re: USB mini-summit at LinuxCon Vancouver
On Thu, 4 Aug 2011, Greg KH wrote: On Thu, Aug 04, 2011 at 07:21:47PM -0300, Mauro Carvalho Chehab wrote: I know that this problem were somewhat solved for 3G modems, with the usage of the userspace problem usb_modeswitch, and with some quirks for the USB storage driver, but I'm not sure if such tricks will scale forever, as more functions are seen on some USB devices. Well, no matter how it scales it needs to be done in userspace, like usb_modeswitch does. We made that decision a while ago, and it is working out very well. I see no reason why you can't do it in userspace as well as that is the easiest place to control this type of thing. I thought we had a long discussion about this topic a while ago and came to this very conclusion. Or am I mistaken? thanks, greg k-h Greg, A little bit more of precision would help me a lot, here. Precisely what is one supposed to do in userspace? I would naturally assume that the user will control the device by announcing what the user wants to do with the device. Such control would therefore have to start in userspace. But this is such an obvious truism that you must mean something else. What, then? To say to do things like usb_modeswitch is rather vague. For one thing, usb_modeswitch, being something out there in userspace, does _not_ affect what is in the kernel. However, what is (or is not) in the kernel might make it possible (or, in the alternative, impossible) to facilitate the action of some kind of userspace function-switching program similar to usb_modeswitch, not so? As to the long discussion about this topic a while ago that may have been a discussion in which I was also involved. For, I do remember a discussion about this topic a few months ago. In one respect my memory differs from yours, however: It was not my impression that any definite conclusions were reached, certainly not a consensus. BTW, I did try to lay out what I remembered as three alternatives that came up, along with arguments for and against each of them, in my message which kicked off this thread today. It is of course a real possibility that you have seen the perfect solution in your mind to these problems, which have vexed a lot of people for years, and others have not. If that is the way it is, then perhaps you just wish that we would all shut up, implement what is obvious, and we could all be happy. This could certainly be the case. You have written a lot more code than I have, and you obviously must have started doing that when you were at least 30 years younger, perhaps even 40 years younger, than I was when I started. So I would be the first to say that you are much better at it than I am. But there are others here, too, who seem actively to have been sucked into this discussion, and they are similarly younger and more clever than I am, too. Giving due consideration to this, it would probably get the job done a lot faster if you just take the time to describe what grand vision you yourself have in mind for the solution of the problem, with a sufficient accounting of the details that people can all see what it is and exactly how and why it would work absolutely perfectly, and then we can just get busy and do it. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Media Subsystem Workshop 2011
moved to userspace. This would of course involve difficulties approximately equivalent to item 1. An advantage, in the eyes of some, would be to cut down on the yet-another-driver-for-yet-another-piece-of-peculiar-hardware syndrome which obviously contributes to an in principle unlimited increase in the size of the kernel codebase. A disadvantage would be that it would create some disruption in webcam support. 3. A further modification to libusb reactivates the kernel module automatically, as soon as the userspace app which wanted to access the device through a libusb-based driver library is closed. This seems attractive, but it has certain deficiencies as well. One of them is that it can not necessarily provide a smooth and informative user experience, since circumstances can occur in which something appears to go wrong, but the user gets no clear message saying what the problem is. In other words, it is a patchwork solution which only slightly refines the current patchwork solution in libusb, which is in itself only a slight improvement on the original, unaddressed problem. 4. ??? Several people are interested in this problem, but not much progress has been made at this time. I think that the topic ought to be put somehow on the front burner so that lots of people will try to think of the best way to handle it. Many eyes, and all that. Not saying change your schedule, as I said. Have a nice conference. I wish I could attend. But I do hope by this message to raise some general concern about this problem. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Media Subsystem Workshop 2011
On Wed, 3 Aug 2011, Mauro Carvalho Chehab wrote: Em 03-08-2011 16:53, Theodore Kilgore escreveu: On Wed, 3 Aug 2011, Mauro Carvalho Chehab wrote: As already announced, we're continuing the planning for this year's media subsystem workshop. To avoid overriding the main ML with workshop-specifics, a new ML was created: workshop-2...@linuxtv.org I'll also be updating the event page at: http://www.linuxtv.org/events.php Over the one-year period, we had 242 developers contributing to the subsystem. Thank you all for that! Unfortunately, the space there is limited, and we can't affort to have all developers there. Due to that some criteria needed to be applied to create a short list of people that were invited today to participate. The main criteria were to select the developers that did significant contributions for the media subsystem over the last 1 year period, measured in terms of number of commits and changed lines to the kernel drivers/media tree. As the used criteria were the number of kernel patches, userspace-only developers weren't included on the invitations. It would be great to have there open source application developers as well, in order to allow us to tune what's needed from applications point of view. So, if you're leading the development of some V4L and/or DVB open-source application and wants to be there, or you think you can give good contributions for helping to improve the subsystem, please feel free to send us an email. With regards to the themes, we're received, up to now, the following proposals: -+-- THEME| Proposed-by: -+-- Buffer management: snapshot mode | Guennadi Rotation in webcams in tablets while streaming is active | Hans de Goede V4L2 Spec ? ambiguities fix | Hans Verkuil V4L2 compliance test results | Hans Verkuil Media Controller presentation (probably for Wed, 25) | Laurent Pinchart Workshop summary presentation on Wed, 25 | Mauro Carvalho Chehab -+-- From my side, I also have the following proposals: 1) DVB API consistency - what to do with the audio and video DVB API's that conflict with V4L2 and (somewhat) with ALSA? 2) Multi FE support - How should we handle a frontend with multiple delivery systems like DRX-K frontend? 3) videobuf2 - migration plans for legacy drivers 4) NEC IR decoding - how should we handle 32, 24, and 16 bit protocol variations? Even if you won't be there, please feel free to propose themes for discussion, in order to help us to improve even more the subsystem. Thank you! Mauro Mauro, Not saying that you need to change the program for this session to deal with this topic, but an old and vexing problem is dual-mode devices. It is an issue which needs some kind of unified approach, and, in my opinion, consensus about policy and methodology. As a very good example if this problem, several of the cameras that I have supported as GSPCA devices in their webcam modality are also still cameras and are supported, as still cameras, in Gphoto. This can cause a collision between driver software in userspace which functions with libusb, and on the other hand with a kernel driver which tries to grab the device. Recent attempts to deal with this problem involve the incorporation of code in libusb which disables a kernel module that has already grabbed the device, allowing the userspace driver to function. This has made life a little bit easier for some people, but not for everybody. For, the device needs to be re-plugged in order to re-activate the kernel support. But some of the user-friencly desktop setups used by some distros will automatically start up a dual-mode camera with a gphoto-based program, thereby making it impossible for the camera to be used as a webcam unless the user goes for a crash course in how to disable the feature which has been so thoughtfully (thoughtlessly?) provided. As the problem is not confined to cameras but also affects some other devices, such as DSL modems which have a partition on them and are thus seen as Mass Storage devices, perhaps it is time to try to find a systematic approach to problems like this. There are of course several possible approaches. 1. A kernel module should handle everything related to connecting up the hardware. In that case, the existing userspace driver has to be modified to use the kernel module instead of libusb. Those who support this option would say
Re: Improving kernel - userspace (usbfs) usb device hand off
On Sun, 12 Jun 2011, Hans de Goede wrote: Hi, On 06/11/2011 06:19 PM, Theodore Kilgore wrote: On Sat, 11 Jun 2011, Hans de Goede wrote: Hi, Given the many comments in this thread, I'm just going reply to this one, and try to also answer any other ones in this mail. As far as the dual mode camera is involved, I agree that that should be fixed in the existing v4l2 drivers + libgphoto. I think that Felipe's solution to also handle the stillcam part in kernel space for dual mode cameras (and add a libgphoto cam driver which knows how to talk the new kernel API for this), is the best solution. Unfortunately this will involve quite a bit of work, but so be it. Hans, It appears to me that the solution ought to be at hand, actually. I was not aware of the recent changes in libusb, which I understand are supposed to allow a kernel driver to be hooked up again. To review the situation: 1. As of approximately 2 years ago, libusb already was so configured as to suspend the kernel module for a dual-mode device if a userspace-based program tried to claim the device. 2. At this point with the more recent versions of libusb (see the last message from yesterday, from Xiaofan Chen), we are supposed to be able to re-activate the kernel module for the device when it is relinquished by userspace. This ought to take care of the problems completely, provided that the new capabilities of libusb are actually used and called upon in libgphoto2. I have checked on what is happening, just now, on my own machine. I have libusb version 1.08 which ought to be recent enough. The advertised abilities did not work, however. Presumably, what is missing is on the other end of the problem, most likely in the functions in libgphoto2 which hook up a camera. That code would presumably need to call upon the new functionality of libusb. My currently installed version of libgphoto2 (from svn, but several months old) clearly does not contain the needed functionality. But it might have been put in recently and I did not notice. I guess that the first thing to do is to update my gphoto tree and then to see what happens. If things still don't work, then something needs to be updated and then things ought to work. I will try to see that something gets done about this. Thank you for raising the old issue of dual-mode devices yet again, and thanks to Xiaofan Chen for pointing out that the needed missing half of the functionality is supposed to exist now in libusb. That had escaped my attention. Actually libusb and libgphoto have been using the rebind orginal driver functionality of the code for quite a while now, Oh? I can see that libusb is doing that, and I can also see that there is a public function for _unbinding_ a kernel driver, namely int usb_detach_kernel_driver_np() found in usb.h and it is used in libgphoto, as well. I am not sure that there is any corresponding rebind function which is public. Is it perhaps int usb_get_driver_np() ??? By context (looking at libgphoto2-port/usb/libusb.c) I would think that this function is not the rebind function, but is only checking whether or not there is any potential conflict with a kernel driver. If I am right, then where is the publicly exported rebind function, and where does it currently get used in libgphoto2? So frankly after my eagerness yesterday I do not see how it can easily be made to work, after all. unfortunately this does not solve the problem, unless we somehow move to 1 central coordinator for the device the user experience will stay subpar. Example, user downloads pictures from the camera using shotwell, gthumb, fspot or whatever, keeps the app in question open and the app in question keeps the gphoto2 device handle open. User wants to do some skyping with video chat, skype complains it cannot find the device, since the kernel driver currently is unbound. - Poor user experience. Poor user experience, or merely poor user? The user ought to know better. Of course, I do agree that there are lots of such people, and it is a good idea to try to put up warning signs. With having both functions in the kernel, the kernel could actually allow skype to use the dual mode cameras as video source, and if the user then were to switch to f-spot and try to import more photo's then he will get an -ebusy in f-spot. If he finishes skyping and then returns to f-spot everything will just continue working. This is the kind of seamless user experience I'm aiming for here. Regards, Hans Yes, I can see where you are coming from. But if the camera really will not let you run skype and fspot at the same time, which I do not believe it would allow on _any_ operating system, then each app should give an error message which says it cannot be run unless and until the other app has been closed. If that has
Re: Improving kernel - userspace (usbfs) usb device hand off
On Sat, 11 Jun 2011, Hans de Goede wrote: Hi, Given the many comments in this thread, I'm just going reply to this one, and try to also answer any other ones in this mail. As far as the dual mode camera is involved, I agree that that should be fixed in the existing v4l2 drivers + libgphoto. I think that Felipe's solution to also handle the stillcam part in kernel space for dual mode cameras (and add a libgphoto cam driver which knows how to talk the new kernel API for this), is the best solution. Unfortunately this will involve quite a bit of work, but so be it. Hans, It appears to me that the solution ought to be at hand, actually. I was not aware of the recent changes in libusb, which I understand are supposed to allow a kernel driver to be hooked up again. To review the situation: 1. As of approximately 2 years ago, libusb already was so configured as to suspend the kernel module for a dual-mode device if a userspace-based program tried to claim the device. 2. At this point with the more recent versions of libusb (see the last message from yesterday, from Xiaofan Chen), we are supposed to be able to re-activate the kernel module for the device when it is relinquished by userspace. This ought to take care of the problems completely, provided that the new capabilities of libusb are actually used and called upon in libgphoto2. I have checked on what is happening, just now, on my own machine. I have libusb version 1.08 which ought to be recent enough. The advertised abilities did not work, however. Presumably, what is missing is on the other end of the problem, most likely in the functions in libgphoto2 which hook up a camera. That code would presumably need to call upon the new functionality of libusb. My currently installed version of libgphoto2 (from svn, but several months old) clearly does not contain the needed functionality. But it might have been put in recently and I did not notice. I guess that the first thing to do is to update my gphoto tree and then to see what happens. If things still don't work, then something needs to be updated and then things ought to work. I will try to see that something gets done about this. Thank you for raising the old issue of dual-mode devices yet again, and thanks to Xiaofan Chen for pointing out that the needed missing half of the functionality is supposed to exist now in libusb. That had escaped my attention. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Improving kernel - userspace (usbfs) usb device hand off
is done in userspace or in kernelspace, so long as it can be done, somehow, after libusb relinquishes the camera. Or, fix things up somehow so that the kernel module automatically re-activates itself when the userspace app (using libgphoto2) is closed down. Finally, another possible alternative would be to figure out how to do something in the kernel module which permits the camera to be accessed by libusb. If there is going to be discussion about this problem in Vancouver, I am really sorry that I will probably be able to attend. Classes for the Fall semester begin at Auburn University on August 17. Nevertheless, this is a problem in which I have been interested for a long time. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Improving kernel - userspace (usbfs) usb device hand off
On Fri, 10 Jun 2011, Felipe Balbi wrote: Hi, On Fri, Jun 10, 2011 at 01:16:47PM -0500, Theodore Kilgore wrote: As I have been involved in writing the drivers (both the kernel and the libgphoto2 drivers) for many of the affected cameras, perhaps I should expand on this problem. There are lots of responses to this original message of Hans. I will try to take some of their comments into account, below. First, some background. 1. All of the cameras in question have only one USB Vendor:Product number. In this sense, they are not good citizens which have different Product there's nothing in the USB spec that says you need different product IDs for different modes of operation. No matter if it's still or webcam configuration, the underlying function is the same: capture images using a set of lenses and image sensor. True, true. But I will add that most of these cameras are Class 255, Subclass 255, Protocol 255 (Proprietary, Proprietary, Proprietary). numbers for the two distinct modes of functioning. Thus, the problems are from that standpoint unavoidable. I don't see any problems in this situation. If, for that particular product, webcam and still image functionality are mutually exclusive, then that's how the product (and their drivers) have to work. Yes. If the linux community decided to put webcam functionality in kernel and still image functionality on a completely separate driver, that's entirely our problem. As I understand, the basic reason why webcam functionality needs to be in the kernel is speed. Quick reaction time, and faster data transmission. Most but not all webcams use isochronous data transport. The ones which do not, cannot get as high a rate of frames per second. Isochronous data transport has historically seemed to need kernel support in order to work properly. Related to this, libusb has not supported isochronous data transport. But still cameras use bulk transport. This is natural because one needs to move data which is stored on the camera to a place on the computer where it can be processed (if needed) and stored. There is no impediment to userspace talking to a USB device, so why not go ahead and do the job that way if the kernel is not needed? The second thing to mention is that libgphoto2 at this point is supporting well over 1,000 cameras. True, there are not 1,000 driver libraries, but there are quite a few. My impression is that nobody wants to put stuff like that in the kernel unless it is absolutely necessary, just because some of those cameras are dual-mode cameras. Don't people complain on a fairly regular basis about kernel code bloat? 2. Until recently in the history of Linux, there was an irreconcilable conflict. If a kernel driver for the video streaming mode was present and installed, it was not possible to use the camera in stillcam mode at all. Thus the only solution to the problem was to blacklist the kernel module so that it would not get loaded automatically and only to install said module by hand if the camera were to be used in video streaming mode, then to rmmod it immediately afterwards. Very cumbersome, obviously. true... but why couldn't we combine both in kernel or in userspace altogether ? Why do we have this split ? (words from a newbie in V4L2, go easy :-p) See above. 3. The current state of affairs is an advance on (2) but it is still inelegant. What happens now is, libusb has been revised in such a way that the kernel module is disabled (though still present) if a userspace driver (libgphoto2) wants to access the device (the camera). If it is desired to do video streaming after that, the camera needs to be re-plugged, which then causes the module to be automatically re-loaded. It's still wrong. This should be just another USB_REQ_SET_CONFIGURATION(). If this is was just one single driver, you could easily do that. Well, I think it ought to be possible anyway. Up to that point, I agree. Though I confess I do not exactly know how. 4. Hans is absolutely correct about the problem with certain Gnome apps (and certain distros which blindly use them), which load up the libgphoto2 driver for the camera as soon as it is detected. The consequence (cf. item 3) is that the camera can never be used as a webcam. The only solution to that problem is to disable the automatic loading of the libgphoto2 driver. I would only add to this, that it is not pleasant to have to deal with frustrated users. At this point, my usual advice is that this is a distro problem. Ask your distro for help. Or, to move the libgphoto2 driver to kernel, combine it in the same driver that handles streaming. No ? See above. 5. It could be said that those who came up with the user-friendly solution described in (4) were not very clever, and perhaps they ought to fix their own mess. I would strongly agree that they ought to have
Re: Improving kernel - userspace (usbfs) usb device hand off
On Fri, 10 Jun 2011, Alan Stern wrote: On Fri, 10 Jun 2011, Felipe Balbi wrote: I don't see any problems in this situation. If, for that particular product, webcam and still image functionality are mutually exclusive, then that's how the product (and their drivers) have to work. If the linux community decided to put webcam functionality in kernel and still image functionality on a completely separate driver, that's entirely our problem. And the problem is how to coordinate the two of them. 2. Until recently in the history of Linux, there was an irreconcilable conflict. If a kernel driver for the video streaming mode was present and installed, it was not possible to use the camera in stillcam mode at all. Thus the only solution to the problem was to blacklist the kernel module so that it would not get loaded automatically and only to install said module by hand if the camera were to be used in video streaming mode, then to rmmod it immediately afterwards. Very cumbersome, obviously. true... but why couldn't we combine both in kernel or in userspace altogether ? Why do we have this split ? (words from a newbie in V4L2, go easy :-p) I think the problem may be that the PTP protocol used in the still-cam mode isn't suitable for a kernel driver. Or if it is suitable, it would have to be something like a shared-filesystem driver -- nothing like a video driver. You certainly wouldn't want to put it in V4L2. Or, to move the libgphoto2 driver to kernel, combine it in the same driver that handles streaming. No ? No. Something else is needed. Alan Stern Agreed. Something else is needed. But what? Also, very good point about PTP. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
On Tue, 12 Apr 2011, Russell King - ARM Linux wrote: On Tue, Apr 12, 2011 at 11:06:34PM +0200, Janusz Krzysztofik wrote: The patch tries to solve this regression by using virt_to_phys(bus_to_virt(mem-dma_handle)) instead of problematic virt_to_phys(mem-vaddr). Who says that DMA handles are bus addresses in the strictest sense? DMA handles on ARM are the bus address to program 'dev' with in order for it to access the memory mapped by dma_alloc_coherent(). On some ARM platforms, this bus address is dependent on 'dev' - such as platforms with more than one root PCI bus, and so bus_to_virt() just doesn't hack it. What is really needed is for this problem - the mapping of DMA coherent memory into userspace - to be solved with a proper arch API rather than all these horrible hacks which subsystems instead invent. That's something I tried to do with the dma_mmap_coherent() stuff but it was shot down by linux-arch as (iirc) PA-RISC objected to it. Hence why ARM only implements it. Maybe the video drivers should try to resurect the idea, maybe only allowing this support for architectures which provide dma_mmap_coherent(). I do not know how this fits into the present discussion. Perhaps everyone who reads the above message is well aware of what is below. If so my comment below is superfluous. But just in case things are otherwise it might save someone a bit of trouble in trying to write something which will work everywhere: If one is speaking here of architecture problems, there is the additional problem that some ARM systems might have not two PCI buses, but instead no PCI bus at all. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debug code in HG repositories
Mauro, A few comments in-line. Vide infra. On Mon, 10 Jan 2011, Mauro Carvalho Chehab wrote: Em 07-01-2011 21:42, Theodore Kilgore escreveu: Have you tried Mauro's media_build tree? I had to use it today to test a driver from git on a 2.6.35 kernel. Works quite nicely. Perhaps we should promote this more. Probably a good idea. I have been too busy to know about it, myself. And I even do try to keep up with what is going on. I could add backwards compatibility builds to my daily build script that uses this in order to check for which kernel versions this compiles if there is sufficient interest. Nice, but don't bust your behind with a thing like that. Back when we were discussing the idea of getting off of hg and onto git, I suggested approximately the previous three minor versions of the kernel, no more. And if there was a serious problem with 2.(current_release - 1) or 2.(current_release - 2) such as instability or security issues, whatever, then just drop that one. I think that to do this is reasonable if you or anyone else has the time and needed skills. More than this is not reasonable under any circumstances. I think Hans can enable it. The backport effort on media-build is a way easier than with -hg. For example, in order to support kernel 2.6.31 (the oldest one on that tree), we need only 10 patches. The patches themself are simple: $ wc -l *.patch 61 v2.6.31_nodename.patch 540 v2.6.32_kfifo.patch 42 v2.6.33_input_handlers_are_int.patch 70 v2.6.33_pvrusb2_sysfs.patch 40 v2.6.34_dvb_net.patch 22 v2.6.34_fix_define_warnings.patch 16 v2.6.35_firedtv_handle_fcp.patch 104 v2.6.35_i2c_new_probed_device.patch 145 v2.6.35_work_handler.patch 104 v2.6.36_input_getkeycode.patch 1144 total And almost all patches are trivial. Great. I am glad Hans is able to do that. I also think that before some changes were made things had reached the point of being both ridiculous and impossible. People doing the work were being run ragged, and demands for legacy support were obviously unreasonable. I forget what all of the issues were in the pre-2.6.20 kernels. I vaguely recall there were some really bad ones. One of them that I have personal knowledge about was a major error in the USB Mass Storage module, detected and fixed somewhere around 2.6.18. Namely, if a device says it is Class 08 the spec says the first pair of bulk endpoints will be used. Before the fix, last pair was being searched instead. The mistake is not confronted very often, of course, because few USB devices have more than one pair of bulk endpoints. But for those that do, ouch. In fact, the hardware which brought the mistake to daylight was the same camera which is supported in gspca/jeilinj.c. In still mode as a standard mass storage device, that camera uses the first pair of bulk endpoints. As it is supposed to do. But until things were fixed, the mass storage support was attempting to use the second pair, which did not work out very well. The second pair of the bulk endpoints gets used only in webcam mode for passing commands and responses. The point of the above story is that sometimes in kernel development things are changed from wrong to right. Those who petulantly want their favorite ancient kernel to be supported simply ought to understand and accept out of hand. Should any kernel prior to the fixing of the above problem continue in use in any environment where it needs to support USB mass storage devices? Obviously not. The moral for the present and future is obvious, too. Now, as to the question of switching over to and using git, here are my recent personal experiences: I started to do this switch-over only about a month ago, having been too busy for several months previous due to an illness in the family. I found that everything had changed in the meantime, and the hg trees had gone away. Issue 0: This issue came up just as I was deciding to switch from 32 to 64 bit computing, so a lot of other stuff needed to be fixed or upgraded at the same time. I was busy. Well, lots of people are busy, and for lots of reasons. Issue 1: Which git tree? For someone who is going to get in at the beginning, this is not obvious. This issue got solved, of course, but it was the first one to face. For an outsider, I suspect that even this is somewhat intimidating. It is now well-indicated at the top of the git page at linuxtv.org. Nice. Issue 2: Problems totally unrelated to drivers/media rendered the new kernel unusable for very a long time, approximately a couple of weeks. I think I can call myself experienced in kernel configuration and compilation, and also not a total neophyte as a developer. The issue was a rather evil interaction between the new kernel, the new X driver for the ATI Radeon chip, and the introduction of in-kernel
Re: Debug code in HG repositories
a good idea. I have been too busy to know about it, myself. And I even do try to keep up with what is going on. I could add backwards compatibility builds to my daily build script that uses this in order to check for which kernel versions this compiles if there is sufficient interest. Nice, but don't bust your behind with a thing like that. Back when we were discussing the idea of getting off of hg and onto git, I suggested approximately the previous three minor versions of the kernel, no more. And if there was a serious problem with 2.(current_release - 1) or 2.(current_release - 2) such as instability or security issues, whatever, then just drop that one. I think that to do this is reasonable if you or anyone else has the time and needed skills. More than this is not reasonable under any circumstances. Now, as to the question of switching over to and using git, here are my recent personal experiences: I started to do this switch-over only about a month ago, having been too busy for several months previous due to an illness in the family. I found that everything had changed in the meantime, and the hg trees had gone away. Issue 0: This issue came up just as I was deciding to switch from 32 to 64 bit computing, so a lot of other stuff needed to be fixed or upgraded at the same time. I was busy. Well, lots of people are busy, and for lots of reasons. Issue 1: Which git tree? For someone who is going to get in at the beginning, this is not obvious. This issue got solved, of course, but it was the first one to face. For an outsider, I suspect that even this is somewhat intimidating. Issue 2: Problems totally unrelated to drivers/media rendered the new kernel unusable for very a long time, approximately a couple of weeks. I think I can call myself experienced in kernel configuration and compilation, and also not a total neophyte as a developer. The issue was a rather evil interaction between the new kernel, the new X driver for the ATI Radeon chip, and the introduction of in-kernel modeswitching (KMS) in X. It came about that if KMS was turned on then the video would cut off completely halfway through the boot procedure, and if KMS was turned off then I could not run X. I could use the distro kernel 2.6.35.7 and a locally compiled 2.6.35.7 as well just fine, but I could not safely submit a patch based on it. And my patches could not be tested against the git kernel because I could not run the git kernel. This problem was ultimately solved, and I was able to submit a rather small patch to add a camera to an existing driver, on Christmas Eve. Issue 3: I still need to grab the git tree for libv4l and start using it. I have not even begun this. For some of the reasons why I am behind schedule, see previous items. The point is, problems similar to those which hit me could hit anybody at any time and anybody means exactly what it says. This was not the first time that I have installed a development kernel. It was the first time I had any serious problems after doing so. Now, it is also true that after I finally got the issues worked through I was pleased with the results and would still run the new kernel by preference. But the problems were extremely time consuming. IMHO problems like this are sooner or later inevitable when it is mandatory to use a development kernel. Users are impatient. Testers are impatient. Developers are impatient. We are all impatient when things like this happen. People who are not sufficiently knowledgeable, who are not sufficiently tenacious, or who simply do not have sufficient time or motivation will just quit. It is something to think about. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Adds the Lego Bionicle to existing sq905c
On Sat, 25 Dec 2010, Hans de Goede wrote: Hi, On 12/25/2010 10:20 AM, Mauro Carvalho Chehab wrote: Em 24-12-2010 17:55, Hans de Goede escreveu: Mauro, Will you pick up this patch directly or should I put it in my tree ? Either way works for me (but I prefer if one of the gspca maintainers/sub-mainainers pick). If you don't pick it, please reply with your ack. Given that nothing else is going into my tree at the moment I would prefer for you to pick it up directly, so: Acked-by: Hans de Goede hdego...@redhat.com Thanks Regards, Hans And thank you. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Adds the Lego Bionicle to existing sq905c
On Sat, 25 Dec 2010, Jean-Francois Moine wrote: On Sat, 25 Dec 2010 10:36:20 +0100 Hans de Goede hdego...@redhat.com wrote: On 12/25/2010 10:20 AM, Mauro Carvalho Chehab wrote: Em 24-12-2010 17:55, Hans de Goede escreveu: Mauro, Will you pick up this patch directly or should I put it in my tree ? Either way works for me (but I prefer if one of the gspca maintainers/sub-mainainers pick). If you don't pick it, please reply with your ack. Given that nothing else is going into my tree at the moment I would prefer for you to pick it up directly, so: Acked-by: Hans de Goede hdego...@redhat.com Hi Mauro and Hans, As I have some changes to do in this driver, ... Jean-Francois, If you do not mind, tell me more about the some changes. More cameras? Or something else? Someone in the family has been quite sick for the last several months, which has taken a lot of my time and energy and may do so in the future, too. I have not had the time to do much more than to look at the mail I get every day, much less to continue work on related projects. Several things that I wanted to do months ago are sitting incomplete and in limbo waiting for me to be less busy and preoccupied. But I have not lost interest. Wishing for you and for all of us a peaceful and prosperous year 2011. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Adds the Lego Bionicle to existing sq905c
This patch adds the Vendor:Product number of the Lego Bionicle camera to
the existing gspca/sq905c.c and also a line for the camera in gspca.txt.
The camera works out of the box with these small changes. So this is
just in time for Christmas. Think of the children.
Signed-off-by: Theodore Kilgore kilg...@auburn.edu
-
diff --git a/Documentation/video4linux/gspca.txt
b/Documentation/video4linux/gspca.txt
index 6a562ee..261776e 100644
--- a/Documentation/video4linux/gspca.txt
+++ b/Documentation/video4linux/gspca.txt
@@ -366,6 +366,7 @@ t61317a1:0128 TASCORP JPEG Webcam,
NGS Cyclops
vc032x 17ef:4802 Lenovo Vc0323+MI1310_SOC
pac207 2001:f115 D-Link DSB-C120
sq905c 2770:9050 Disney pix micro (CIF)
+sq905c 2770:9051 Lego Bionicle
sq905c 2770:9052 Disney pix micro 2 (VGA)
sq905c 2770:905c All 11 known cameras with this ID
sq905 2770:9120 All 24 known cameras with this ID
diff --git a/drivers/media/video/gspca/sq905c.c
b/drivers/media/video/gspca/sq905c.c
index c2e88b5..8ba1995 100644
--- a/drivers/media/video/gspca/sq905c.c
+++ b/drivers/media/video/gspca/sq905c.c
@@ -301,6 +301,7 @@ static int sd_start(struct gspca_dev *gspca_dev)
static const __devinitdata struct usb_device_id device_table[] = {
{USB_DEVICE(0x2770, 0x905c)},
{USB_DEVICE(0x2770, 0x9050)},
+ {USB_DEVICE(0x2770, 0x9051)},
{USB_DEVICE(0x2770, 0x9052)},
{USB_DEVICE(0x2770, 0x913d)},
{}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problems with using the -rc kernel in the git tree
On Mon, 20 Dec 2010, Alex Deucher wrote: On Sun, Dec 19, 2010 at 6:56 PM, Theodore Kilgore kilg...@banach.math.auburn.edu wrote: Hans, Thanks for the helpful advice about how to set up a git tree for current development so that I can get back into things. However, there is a problem with that -rc kernel, at least as far as my hardware is concerned. So if I am supposed to use it to work on camera stuff there is an obstacle. I started by copying my .config file over to the tree, and then running make oldconfig (as you said and as I would have done anyway). The problem seems to be centered right here (couple of lines from .config follow) CONFIG_DRM_RADEON=m # CONFIG_DRM_RADEON_KMS is not set I have a Radeon video card, obviously. Specifically, it is (extract from X config file follows) # Device configured by xorgconfig: Section Device Identifier ATI Radeon HD 3200 Driver radeon Now, what happens is that with the kernel configuration (see above) I cannot start X in the -rc kernel. I get bumped out with an error message (details below) whereas that _was_ my previous configuration setting. But if in the config for the -rc kernel I change the second line by turning on CONFIG_DRM_RADEON_KMS the situation is even worse. Namely, the video cuts off during the boot process, with the monitor going blank and flashing up a message that it lost signal. After that the only thing to do is a hard reset, which strangely does not result in any check for a dirty file system, showing that things _really_ got screwed. These problems wit the video cutting off at boot are with booting into the _terminal_, BTW. I do not and never have made a practice of booting into X. I start X from the command line after boot. Thus, the video cutting off during boot has nothing to do with X at all, AFAICT. So as I said there are two alternatives, both of them quite unpleasant. Here is what the crash message is on the screen from the attempt to start up X, followed by what seem to be the relevant lines from the log file, with slightly more detail. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Sun Dec 19 14:32:12 2010 (==) Using config file: /etc/X11/xorg.conf (==) Using system config directory /usr/share/X11/xorg.conf.d (II) [KMS] drm report modesetting isn't supported. (EE) RADEON(0): Unable to map MMIO aperture. Invalid argument (22) (EE) RADEON(0): Memory map the MMIO region failed (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found Please consult the The X.Org Foundation support at http://wiki.x.org for help. Please also check the log file at /var/log/Xorg.0.log for additional information. xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error xinit: unable to connect to X server: Connection refused xinit: server error kilg...@khayyam:~$ And the following, too, from the log file, which perhaps contains one or two more details: [ 48.050] (--) using VT number 7 [ 48.052] (II) [KMS] drm report modesetting isn't supported. [ 48.052] (II) RADEON(0): TOTO SAYS feaf [ 48.052] (II) RADEON(0): MMIO registers at 0xfeaf: size 64KB [ 48.052] (EE) RADEON(0): Unable to map MMIO aperture. Invalid argument (22) [ 48.052] (EE) RADEON(0): Memory map the MMIO region failed [ 48.052] (II) UnloadModule: radeon [ 48.052] (EE) Screen(s) found, but none have a usable configuration. [ 48.052] Fatal server error: [ 48.052] no screens found [ 48.052] There are a couple of suggestions about things to try, such as compiling with CONFIG_DRM_RADEON_KMS and then passing the parameter modeset=0 to the radeon module. But that does not seem to help, either. The help screens in make menuconfig do not seem to praise the CONFIG_DRM_RADEON_KMS very highly, and seem to indicate that this is still a very experimental feature. There are no such equivalent problems with my current kernel, which is a home-compiled 2.6.35.7. I realize that this is a done decision, but it is exactly this kind of thing that I had in mind when we had the Great Debate on the linux-media list about whether to use hg or git. My position was to let hardware support people to run hg with the compatibility layer for recent kernels (and 2.6.35.7 is certainly recent!). Well, the people who had such a position did not win. So now here is unfortunately the foreseeable result. An experimental kernel with some totally unrelated bug which affects my hardware and meanwhile stops all progress. If you enable radeon KMS, you need
Re: Power frequency detection.
On Sun, 19 Dec 2010, Paulo Assis wrote: Hi, 2010/12/18 Theodore Kilgore kilg...@banach.math.auburn.edu: Does anyone know whether, somewhere in the kernel, there exists a scheme for detecting whether the external power supply of the computer is using 50hz or 60hz? The reason I ask: A certain camera is marketed with Windows software which requests the user to set up the option of 50hz or 60hz power during the setup. Judging by what exists in videodev2.h, for example, it is evidently possible to set up this as a control setting in a Linux driver. I am not aware of any streaming app which knows how to access such an option. Most uvc cameras present this as a control, so any v4l2 control app should let you access it. If your camera driver also supports this control then this shouldn't be a problem for any generci v4l2 app. here are a couple of ones: v4l2ucp (control panel) guvcview (guvcview --control_only will work along side other apps just like v4l2ucp) uvcdynctrl from libwebcam for command line control utility . Regards, Paulo Thank you. I still think that it would be even more clever to detect the line frequency automatically and then just to set the proper setting, if needed or desirable. That was one of the parts of my question about it, after all. But if nobody has ever had a reason to do such detection already it would perhaps be much more trouble than it is worth just do support a cheap camera. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Power frequency detection.
On Sun, 19 Dec 2010, Andy Walls wrote: Theodore, Aside from detect measurment of the power line, isn't a camera the best sort of sensor for this measurment anyway? Just compute the average image luminosity over several frames and look for (10 Hz ?) periodic variation (beats), indicating a mismatch. Sure you could just ask the user, but where's the challenge in that. ;) Regards, Andy Well, if it is established policy to go with doing this as a control, I guess we can just go ahead instead of doing something fancy. But it is nice to hear from you. Here is why. The camera in question is another jeilinj camera. Its OEM software for that other OS does present the option to choose line frequency. It also asks for the user to specify an image quality index. I can not recall that the software I got with my camera did any such thing. As I recall, it merely let the camera to start streaming. Bur at the moment I have no idea where I put that old CD. So, while I have you on the line, do you recall whether or not the OEM software for the camera you bought for your daughter present any such setup options? The new camera may be different in some particulars from the ones we have. It does have a new Product number, so apparently Jeilin might not have thought it is identical to the other ones. It does use a slightly different initialization sequence. Therefore, the quick-and-dirty way to support it would be just to introduce a patch which has switch statements or conditionals all over the place, and just to support whatever the camera was observed to do. However, that is obviously dirty as well as quick. While playing around with the code a bit, I have managed to make my old camera work with essentially the same init sequence that the new one is using. If this can be done right, it would clear a lot of crud out of the driver code. Unfortunately, doing it right involves testing... Finally, one concern that I have in the back of my mind is the question of control settings for a camera which streams in bulk mode and requires the setup of a workqueue. The owner of the camera says that he has encountered no problems with running the two controls mentioned above. Clearly, that is not a complete answer which overcomes all possible objections. Rather, things are OK if and only if we can ensure that these controls can be run only while the workqueue that does the streaming is inactive. Somehow, I suspect that the fact that a sensible user would only run such commands at camera setup is an insufficient guarantee that no problems will ever be encountered. So, as I said, the question of interaction of a control and a workqueue is another problem interesting little problem. Your thoughts on this interesting little problem would be appreciated. As I said, Merry Christmas :-) Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
problems with using the -rc kernel in the git tree
Hans, Thanks for the helpful advice about how to set up a git tree for current development so that I can get back into things. However, there is a problem with that -rc kernel, at least as far as my hardware is concerned. So if I am supposed to use it to work on camera stuff there is an obstacle. I started by copying my .config file over to the tree, and then running make oldconfig (as you said and as I would have done anyway). The problem seems to be centered right here (couple of lines from .config follow) CONFIG_DRM_RADEON=m # CONFIG_DRM_RADEON_KMS is not set I have a Radeon video card, obviously. Specifically, it is (extract from X config file follows) # Device configured by xorgconfig: Section Device Identifier ATI Radeon HD 3200 Driver radeon Now, what happens is that with the kernel configuration (see above) I cannot start X in the -rc kernel. I get bumped out with an error message (details below) whereas that _was_ my previous configuration setting. But if in the config for the -rc kernel I change the second line by turning on CONFIG_DRM_RADEON_KMS the situation is even worse. Namely, the video cuts off during the boot process, with the monitor going blank and flashing up a message that it lost signal. After that the only thing to do is a hard reset, which strangely does not result in any check for a dirty file system, showing that things _really_ got screwed. These problems wit the video cutting off at boot are with booting into the _terminal_, BTW. I do not and never have made a practice of booting into X. I start X from the command line after boot. Thus, the video cutting off during boot has nothing to do with X at all, AFAICT. So as I said there are two alternatives, both of them quite unpleasant. Here is what the crash message is on the screen from the attempt to start up X, followed by what seem to be the relevant lines from the log file, with slightly more detail. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Sun Dec 19 14:32:12 2010 (==) Using config file: /etc/X11/xorg.conf (==) Using system config directory /usr/share/X11/xorg.conf.d (II) [KMS] drm report modesetting isn't supported. (EE) RADEON(0): Unable to map MMIO aperture. Invalid argument (22) (EE) RADEON(0): Memory map the MMIO region failed (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found Please consult the The X.Org Foundation support at http://wiki.x.org for help. Please also check the log file at /var/log/Xorg.0.log for additional information. xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error xinit: unable to connect to X server: Connection refused xinit: server error kilg...@khayyam:~$ And the following, too, from the log file, which perhaps contains one or two more details: [48.050] (--) using VT number 7 [48.052] (II) [KMS] drm report modesetting isn't supported. [48.052] (II) RADEON(0): TOTO SAYS feaf [48.052] (II) RADEON(0): MMIO registers at 0xfeaf: size 64KB [48.052] (EE) RADEON(0): Unable to map MMIO aperture. Invalid argument (22) [48.052] (EE) RADEON(0): Memory map the MMIO region failed [48.052] (II) UnloadModule: radeon [48.052] (EE) Screen(s) found, but none have a usable configuration. [48.052] Fatal server error: [48.052] no screens found [48.052] There are a couple of suggestions about things to try, such as compiling with CONFIG_DRM_RADEON_KMS and then passing the parameter modeset=0 to the radeon module. But that does not seem to help, either. The help screens in make menuconfig do not seem to praise the CONFIG_DRM_RADEON_KMS very highly, and seem to indicate that this is still a very experimental feature. There are no such equivalent problems with my current kernel, which is a home-compiled 2.6.35.7. I realize that this is a done decision, but it is exactly this kind of thing that I had in mind when we had the Great Debate on the linux-media list about whether to use hg or git. My position was to let hardware support people to run hg with the compatibility layer for recent kernels (and 2.6.35.7 is certainly recent!). Well, the people who had such a position did not win. So now here is unfortunately the foreseeable result. An experimental kernel with some totally unrelated bug which affects my hardware and meanwhile stops all progress. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Power frequency detection.
On Sun, 19 Dec 2010, Andy Walls wrote: On Sun, 2010-12-19 at 14:51 -0600, Theodore Kilgore wrote: On Sun, 19 Dec 2010, Andy Walls wrote: Theodore, Aside from detect measurment of the power line, isn't a camera the best sort of sensor for this measurment anyway? Just compute the average image luminosity over several frames and look for (10 Hz ?) periodic variation (beats), indicating a mismatch. Sure you could just ask the user, but where's the challenge in that. ;) Regards, Andy Well, if it is established policy to go with doing this as a control, I guess we can just go ahead instead of doing something fancy. My policy is let computers do what computers do well, and let people do what people do well. Looking at an image, recognizing flicker, and twiddling knobs to make it go away (to one's own satisfaction) is much better left to a person for one time adjustments. OK. But it is nice to hear from you. Here is why. The camera in question is another jeilinj camera. Its OEM software for that other OS does present the option to choose line frequency. It also asks for the user to specify an image quality index. I can not recall that the software I got with my camera did any such thing. As I recall, it merely let the camera to start streaming. Bur at the moment I have no idea where I put that old CD. The Software for our Sakar branded Jeilin camera was a little smarter. Oh. So _you_ had a Sakar branded camera. This was one of the things that causes problems recently. In gspca.txt we have the supported camera listed as jeilinj 0979:0280 Sakar 57379 which seemed to me to be quite wrong, as (unless I have made a bad mistake) the Sakar 57379 has a Jeilin 2005C or D chip inside (proprietary interface camera, Product number 0x227, definitely not one of these guys) and AFAICT the Jeilin 2005C-D cameras can not be made to stream at all, operating only in stillcam mode. So, when I was contacted about this new camera I saw that listing and thought it had to be wrong! Hoping that you still have some way to check what the Sakar product number of your cam really was... I seem to recall image size adjustments. Yes, the new one does. And these adjustments do seem to work with my old one, too. I also recall the driver binary contained multiple different MJPEG headers that I guess it could have tack back on to the incoming stream. Hmmm. Probably that had something to do with the quality setting? However, the camera suffered such love/abuse at the hands of my 11 year old daughter that it no longer functions, even with the electrical tape that still holds the case together. ;) So, while I have you on the line, do you recall whether or not the OEM software for the camera you bought for your daughter present any such setup options? I cannot. The new camera may be different in some particulars from the ones we have. It does have a new Product number, so apparently Jeilin might not have thought it is identical to the other ones. It does use a slightly different initialization sequence. Therefore, the quick-and-dirty way to support it would be just to introduce a patch which has switch statements or conditionals all over the place, and just to support whatever the camera was observed to do. However, that is obviously dirty as well as quick. While playing around with the code a bit, I have managed to make my old camera work with essentially the same init sequence that the new one is using. If this can be done right, it would clear a lot of crud out of the driver code. Unfortunately, doing it right involves testing... When researching Jeilin's offerings on their website long ago I recall a few different chipsets, but only one that matched the MJPEG type camera application. It's probably just the difference between different firmware versions in the camera with the same Jeilin camera chipset. Finally, one concern that I have in the back of my mind is the question of control settings for a camera which streams in bulk mode and requires the setup of a workqueue. The owner of the camera says that he has encountered no problems with running the two controls mentioned above. Clearly, that is not a complete answer which overcomes all possible objections. Rather, things are OK if and only if we can ensure that these controls can be run only while the workqueue that does the streaming is inactive. Somehow, I suspect that the fact that a sensible user would only run such commands at camera setup is an insufficient guarantee that no problems will ever be encountered. So, as I said, the question of interaction of a control and a workqueue is another problem interesting little problem. Your thoughts on this interesting little problem would be appreciated. I am unfamiliar with: 1. Any USB interface
Re: Power frequency detection.
On Sun, 19 Dec 2010, Adam Baker wrote: On Sunday 19 Dec 2010, Theodore Kilgore wrote: Finally, one concern that I have in the back of my mind is the question of control settings for a camera which streams in bulk mode and requires the setup of a workqueue. The owner of the camera says that he has encountered no problems with running the two controls mentioned above. Clearly, that is not a complete answer which overcomes all possible objections. Rather, things are OK if and only if we can ensure that these controls can be run only while the workqueue that does the streaming is inactive. Somehow, I suspect that the fact that a sensible user would only run such commands at camera setup is an insufficient guarantee that no problems will ever be encountered. So, as I said, the question of interaction of a control and a workqueue is another problem interesting little problem. Your thoughts on this interesting little problem would be appreciated. I don't think you can assume a user won't try to adjust such controls while streaming - what I said, actually if I had one I'd certainly want to try swapping the control while streaming to see if I could see any affect on the output. Yeah, I tell people that I like to see if I can hook things together and make something go bang. Or, that I do research about locating that elusive magic smoke in the hardware, which makes it run. So maybe I would try that too, just for the pure hell of it. But I did say something about a sensible user? Neither of us, apparently. And come down to it, if one cannot trust you, and cannot trust me, as much work as we did together, then nobody can be trusted at all. :-} Even though sq905.c doesn't have any controls on the camera it still ended up needing the locking that would make this safe. See the header comment on sq905_dostream If the controls are locked while the workqueue is doing the streaming, then probably that does fix the problem? Most likely, that is the simplest thing to do. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Power frequency detection.
On Sun, 19 Dec 2010, Andy Walls wrote: On Sun, 2010-12-19 at 18:13 -0600, Theodore Kilgore wrote: On Sun, 19 Dec 2010, Andy Walls wrote: The Software for our Sakar branded Jeilin camera was a little smarter. Oh. So _you_ had a Sakar branded camera. This was one of the things that causes problems recently. In gspca.txt we have the supported camera listed as jeilinj 0979:0280 Sakar 57379 which seemed to me to be quite wrong, as (unless I have made a bad mistake) the Sakar 57379 has a Jeilin 2005C or D chip inside (proprietary interface camera, Product number 0x227, definitely not one of these guys) and AFAICT the Jeilin 2005C-D cameras can not be made to stream at all, operating only in stillcam mode. So, when I was contacted about this new camera I saw that listing and thought it had to be wrong! OK, I looked again more closely in libgphoto2/camlibs/jl2005c/library.c, in which one sees Sakar no. 75379 If you are my age you _do_ need to look twice. Then three times. Then have a friend point out that you did not see something right. In case you are missing it, too 57379 != 75379 So, thanks. At least that is one thing I do not need to fix. Hoping that you still have some way to check what the Sakar product number of your cam really was... The Internet never forgets: http://www.spinics.net/lists/linux-media/msg07025.html http://www.spinics.net/lists/linux-media/msg07127.html Yes, I guess that clears it all up. I _do_ still have those messages somewhere, but it is every so much easier to do it this way. It looks like I hypothesized my camera had a JL2008 chips given the AVI files it created had JL2008V2C in it. This appears to be a very reasonable hypothesis. I never thought the camera has a JL2005C chip in it. I just thought I had erroneously listed a camera in gspca.txt which was in fact some other kind of camera. But, as I said, 57379 != 75379 and they are not the same camera, either. Thanks again. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Power frequency detection.
Does anyone know whether, somewhere in the kernel, there exists a scheme for detecting whether the external power supply of the computer is using 50hz or 60hz? The reason I ask: A certain camera is marketed with Windows software which requests the user to set up the option of 50hz or 60hz power during the setup. Judging by what exists in videodev2.h, for example, it is evidently possible to set up this as a control setting in a Linux driver. I am not aware of any streaming app which knows how to access such an option. Information about which streaming app ought to be used which could take advantage of a setting for line frequency would be welcome, too, of course. As I said, I do not know of a single one and would therefore have trouble with testing any such control setting unless I could find the software which can actually present the choice to the user. But my main question is whether the kernel already does detect the line frequency anywhere else, for whatever reason. For, it occurs to me that a far more elegant solution -- if the camera really does need to have the line frequency detected -- would be do do the job automatically and not to bother the user about such a thing. In other news, in case anyone has any children who are in love with Lego, the Lego Bionicle camera which is currently on sale has an SQ905C type chip in it. I just added its Product number to the Gphoto driver last night. And it works perfectly in webcam mode if one adds its product number in gspca/sq905c.c. I will get around to doing that formally, of course, when I get time. But if anyone wants just to add the number and re-compile the Vendor:Product number for the new camera is 0x2770:0x9051. Merry Christmas. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Mon, 18 Oct 2010, Steven Rostedt wrote: On Tue, 2010-10-19 at 12:45 +1000, Dave Airlie wrote: On Tue, Oct 19, 2010 at 12:24 PM, Greg KH g...@kroah.com wrote: So, there is no need for the i830 driver? Can it just be removed because i915 works instead? No because it provides a different userspace ABI to the i915 driver to a different userspace X driver etc. like I'm sure the intersection of this driver and reality are getting quite limited, but its still a userspace ABI change and needs to be treated as such. Xorg 6.7 and XFree86 4.3 were the last users of the old driver/API. Thus, you are saying that this will break for people with older user apps and have a newer kernel? So it really only leaves the problem case of what do distros do if we mark things as BROKEN_ON_SMP, since no distro builds UP kernels and when you boot the SMP kernels on UP they don't run as SMP so not having the driver load on those is a problem. Maybe we just need some sort of warn on smp if a smp unfriendly driver is loaded and we transition to SMP mode. Though this sounds like either (a) something we do now and I don't about it, (b) work. So you are saying that just because distros will never build such a thing, we should keep it building for SMP mode? Why not prevent it from being built and if a distro really cares, then they will pony up the development to fix the driver up? Distros build the driver now even it it didn't work on SMP it wouldn't matter to the 99% of people who have this hw since it can't suppport SMP except in some corner cases. So not building for SMP is the same as just throwing it out of the kernel since most people don't run kernel.org kernels, and shouldn't have to just to get a driver for some piece of hardware that worked fine up until now. Ah! Exactly! Thus, those that do not run kernel.org kernels are using a distro kernel. Wont these same people use the distro userspace? That is, if they have upgraded their kernel, most likely, they also update their X interface. Look at this from a user who has this hardware pov, it works for them now with a distro kernel, us breaking it isn't going to help that user or make any distro care, its just going to screw over the people who are actually using it. But they can use the i915 driver instead, because they are using the newer userspace apps. In other words, if someone really cares, then they will do the work, otherwise why worry? Especially as it seems that no one here is going to do it, right? Well the thing is doing the work right is a non-trivial task and just dropping support only screws the people using the hardware, it doesn't place any burden on the distro developers to fix it up. If people are really serious about making the BKL go away completely, I think the onus should be on them to fix the drivers not on the users who are using it, like I'm guessing if this gets broken the bug will end up in Novell or RH bugzilla in a year and nobody will ever see it. Well the problem comes down to testing it. I don't know of any developer that is removing the BKL that actually owns hardware to test out these broken drivers. And for the change not being trivial, means that there's no way to do in correctly. -- Steve I might be able to find some hardware still lying around here that uses an i810. Not sure unless I go hunting it. But I get the impression that if the kernel is a single-CPU kernel there is not any problem anyway? Don't distros offer a non-smp kernel as an installation option in case the user needs it? So in reality how big a problem is this? Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux V4L2 support dual stream video capture device
On Tue, 14 Sep 2010, Laurent Pinchart wrote: Hi Theodore, On Monday 13 September 2010 19:17:48 Theodore Kilgore wrote: On Mon, 13 Sep 2010, Laurent Pinchart wrote: On Friday 07 May 2010 20:20:38 Wang, Wen W wrote: Hi all, I'm wondering if V4L2 framework supports dual stream video capture device that transfer a preview stream and a regular stream (still capture or video capture) at the same time. We are developing a device driver with such capability. Our proposal to do this in V4L2 framework is to have two device nodes, one as primary node for still/video capture and one for preview. If the device supports multiple simultaneous video streams, multiple video nodes is the way to go. The primary still/video capture device node is used for device configuration which can be compatible with open sourced applications. This will ensure the normal V4L2 application can run without code modification. Device node for preview will only accept preview buffer related operations. Buffer synchronization for still/video capture and preview will be done internally in the driver. I suspect that the preview device node will need to support more than the buffer-related operations, as you probably want applications to configure the preview video stream format and size. This is our initial idea about the dual stream support in V4L2. Your comments will be appreciated! You should use the media controller framework. This will allow applications to configure all sizes in the pipeline, including the frame sizes for the two video nodes. Hi, Wen, You have hit upon an old and rather vexing problem. It affects many devices, not just your prospective one. The problem is that still mode is supported in Linux for a lot of cameras through userspace tools, namely libgphoto2 which uses libusb to interface with the device. But if the same device can also do video streaming then the streaming has to be supported through a kernel module. Thus until now it is not possible to do both of these smoothly and simultaneously. As I have written both the kernel support and the libgphoto2 support for several dual-mode cameras, I am looking into the related problems, along with Hans de Goede. But right now I am dealing instead with a rather severe illness of a family member. So there is not much coding going on over here. What I think that both of us (Hans and I) agree on is that the kernel modules for the affected devices have to be rewritten in order to allow the opening and closing of the different modes of the devices, and (perhaps) the userspace support has to take that into account as well. There might also have to be some additions to libv4l2 in order to make it aware of such devices. We have not gotten very far with this project. Hans is quite busy, and so am I (see above). In spite of my present preoccupation, however, I would be very curious about any details of your envisioned camera. For example: Does it use the isochronous mode for streaming and the bulk mode for stills? Or not? There seems to be a small misunderstanding. The device Wen is working on (as far as I'm aware of) isn't a USB device. Ah, OK. Put down the misunderstanding to the fact that I am too busy dealing with someone's illness right now, and I seem to have time only for quick skimming of the mail. Sorry. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux V4L2 support dual stream video capture device
On Mon, 13 Sep 2010, Laurent Pinchart wrote: Hi Wen, On Friday 07 May 2010 20:20:38 Wang, Wen W wrote: Hi all, I'm wondering if V4L2 framework supports dual stream video capture device that transfer a preview stream and a regular stream (still capture or video capture) at the same time. We are developing a device driver with such capability. Our proposal to do this in V4L2 framework is to have two device nodes, one as primary node for still/video capture and one for preview. If the device supports multiple simultaneous video streams, multiple video nodes is the way to go. The primary still/video capture device node is used for device configuration which can be compatible with open sourced applications. This will ensure the normal V4L2 application can run without code modification. Device node for preview will only accept preview buffer related operations. Buffer synchronization for still/video capture and preview will be done internally in the driver. I suspect that the preview device node will need to support more than the buffer-related operations, as you probably want applications to configure the preview video stream format and size. This is our initial idea about the dual stream support in V4L2. Your comments will be appreciated! You should use the media controller framework. This will allow applications to configure all sizes in the pipeline, including the frame sizes for the two video nodes. Hi, Wen, You have hit upon an old and rather vexing problem. It affects many devices, not just your prospective one. The problem is that still mode is supported in Linux for a lot of cameras through userspace tools, namely libgphoto2 which uses libusb to interface with the device. But if the same device can also do video streaming then the streaming has to be supported through a kernel module. Thus until now it is not possible to do both of these smoothly and simultaneously. As I have written both the kernel support and the libgphoto2 support for several dual-mode cameras, I am looking into the related problems, along with Hans de Goede. But right now I am dealing instead with a rather severe illness of a family member. So there is not much coding going on over here. What I think that both of us (Hans and I) agree on is that the kernel modules for the affected devices have to be rewritten in order to allow the opening and closing of the different modes of the devices, and (perhaps) the userspace support has to take that into account as well. There might also have to be some additions to libv4l2 in order to make it aware of such devices. We have not gotten very far with this project. Hans is quite busy, and so am I (see above). In spite of my present preoccupation, however, I would be very curious about any details of your envisioned camera. For example: Does it use the isochronous mode for streaming and the bulk mode for stills? Or not? In still mode, is it some kind of standard device, such as Mass Storage or PTP? Or will it use a proprietary or device-specific protocol? If so, it will clearly require a libgphoto2 driver. In video mode, will it use a proprietary or device-specific protocol, or will it be a standard USB video class device? If it is proprietary, then it will presumably need its own module, and if standard then in any event we have to figure out how to make the two different modes to coexist. If either of the still mode or the streaming video mode will use a proprietary protocol and especially if some unknown data compression algorithm is going to be in use, then clearly it is possible to get the support going much earlier if information is provided. Hoping that this will help you and thanking you for any additional information about the new camera. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Illuminators and status LED controls
On Tue, 7 Sep 2010, Hans Verkuil wrote:
On Tuesday, September 07, 2010 20:42:07 Hans Verkuil wrote:
On Tuesday, September 07, 2010 19:57:18 Jean-Francois Moine wrote:
On Tue, 7 Sep 2010 17:30:33 +0200
Hans Verkuil hverk...@xs4all.nl wrote:
enum v4l2_illuminator {
V4L2_ILLUMINATOR_OFF = 0,
V4L2_ILLUMINATOR_ON = 1,
};
#define V4L2_CID_ILLUMINATOR_0 (V4L2_CID_BASE+37)
#define V4L2_CID_ILLUMINATOR_1 (V4L2_CID_BASE+38)
enum v4l2_led {
V4L2_LED_AUTO = 0,
V4L2_LED_OFF = 1,
V4L2_LED_ON = 2,
};
#define V4L2_CID_LED_0 (V4L2_CID_BASE+39)
Simple and straightforward.
Hi,
Hans (de Goede), is this OK for you? I think that if we find more
illuminators or LEDs on some devices, we may add more V4L2_CID_xxx_n
controls.
Hans (Verkuil), may we have the same enum's for both light types?
Something like:
enum v4l2_light {
V4L2_LIGHT_OFF = 0,
V4L2_LIGHT_ON = 1,
V4L2_LIGHT_AUTO = 2,
V4L2_LIGHT_BLINK = 3,
};
I'm OK with that. Although 'blink' shouldn't be added yet unless we have a
driver that will actually make use of it.
I realized something else: while for us programmers it is perfectly natural
to start counting at 0, for the rest of the world it is probably more
understandable to start counting at 1. I know it goes against our religion,
but sometimes you just have to conform. :-)
Regards,
Hans
Sorry about the long silence from here, but there has been illness in the
family. I do keep trying to watch whatever is going on.
Hans, I agree with your general characterization of the public's
perception of 0 versus 1. But on this particular occasion I suspect that
the general public would see that 0 corresponds more naturally to off
than 1 does.
Hoping that all is well with you and others.
Cheers, and this is just my two cents on a trivial issue.
Theodore Kilgore
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Gspca-gl860 driver update
On Mon, 31 May 2010, Jean-Francois Moine wrote: On Mon, 31 May 2010 00:24:21 +0200 Olivier Lorin olori...@gmail.com wrote: - Change of rounded image resolutions to the real ones - Fix for an irrelevant OV9655 image resolution identifier name - Extra spaces to align some variable names and a defined value Hi Olivier, If I can anticipate, the changes are too different. You should split this patch. Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Congratulations. Nice. Theodore Kilgore
Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode
On Sun, 30 May 2010, Andy Walls wrote:
On Sun, 2010-05-30 at 20:13 +0200, Jean-Francois Moine wrote:
On Sun, 30 May 2010 19:55:22 +0200
Ondrej Zary li...@rainbow-software.org wrote:
That's bad...
The driver contains file sp5x_32.dll which is registered in
system.ini file as [drivers32]
VIDC.SP54=SP5X_32.DLL
Seems that the codec is called SP54 - hope that it's used to
decompress the data.
All I can do is to code the driver and let you or anyone find the
decompression function...
Maybe we can dump some data, create AVI file from that and try to
decode the file using that codec.
It is easy to get images from the usbsnoop files. I join an image
extracted from your file usbsnoop-video-capture-640x480.log. If you
want more images, they are in IsoPackets. The first 2 bytes of each isoc
packet mean:
- '02 80' or '02 81': first of intermediate part of the image ('0' or
'1' is the image sequence number)
- '02 82' or '02 83': last part of the image
Someone had an idea to try and guess the compression algorithm: do
usbsnoop's with full black and full white images. But this idea did not
work with the other webcam: the images were quite the same!
I have attached an image I constructed from the image data file you
provided, the MJPEG headers in the AVI file Ondrej provided, and the
Huffman table in the jpeg.h file in the gspca driver.
If you zoom in, there is an small pattern in the top left portion of the
scan.
I doesn't look quite like an whole image, but it does look like the
start of one.
Regards,
Andy
Downloaded it. And, hmmm. Here are the error messages on trying to look at
the output:
kilg...@khayyam:~$ display test1.jpg
display: Corrupt JPEG data: premature end of data segment `test1.jpg' @
warning/jpeg.c/EmitMessage/228.
display: Unsupported marker type 0x3a `test1.jpg' @
error/jpeg.c/EmitMessage/233.
kilg...@khayyam:~$
Quite possibly it _is_ going down strips or such. That is what the
JL2005C cameras are doing. Each vertical strip of 16 bytes from the
picture is in fact a separate JPEG image, and needs to be separately
processed, and then the results glued together into an image. This is even
seen in the raw data, once one is so wise that it is all figured out. The
data for each strip ends with FF D9. So one suggestion here would be to
see how many times the FF D9 is coming up in the data. There may be a
pattern to that.
Theodore Kilgore
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Invalid module format
On Sun, 7 Mar 2010, Mauro Carvalho Chehab wrote: Theodore Kilgore wrote: On Sat, 6 Mar 2010, Mauro Carvalho Chehab wrote: Randy Dunlap wrote: On 03/05/10 16:51, VDR User wrote: On Fri, Mar 5, 2010 at 4:39 PM, Theodore Kilgore kilg...@banach.math.auburn.edu wrote: This is to report the good news that none of the above suspicions have panned out. I still do not know the exact cause of the problem, but a local compile and install of the 2.6.33 kernel did solve the problem. Hence, it does seem that the most likely origin of the problem is somewhere in the Slackware-current tree and the solution does not otherwise concern anyone on this list and does not need to be pursued here. I experienced the same problem and posted a new thread about it with the subject Problem with v4l tree and kernel 2.6.33. I'm a debian user as well so apparently whatever is causing this is not specific to debian or slackware. Even though you've got it working now, the source of the problem should be investigated. -- It's been several years since I last saw this error and I don't recall what caused it then. The message Invalid module format comes from either of modprobe and/or insmod when the kernel returns ENOEXEC to a module (load) syscall. Sometimes the kernel produces more explanatory messages sometimes not. If there are no more explanatory messages, then kernel/module.c can be built with DEBUGP producing more output (and then that new kernel would have to be loaded). Can one of you provide a kernel config file for a kernel/modprobe combination that produces this message? Some of the CONFIG_MODULE* config symbols could have relevance here also. I suspect that it may be related to this: # Select 32 or 64 bit config 64BIT bool 64-bit kernel if ARCH = x86 default ARCH = x86_64 ---help--- Say yes to build a 64-bit kernel - formerly known as x86_64 Say no to build a 32-bit kernel - formerly known as i386 With 2.6.33, it is now possible to compile a 32 bits kernel on a 64 bits machine without needing to pass make ARCH=i386 or to use cross-compilation. Maybe you're running a 32bits kernel, and you've compiled the out-of-tree modules with 64bits or vice-versa. My suggestion is that you should try to force the compilation wit the proper ARCH with something like: make distclean make ARCH=`uname -i` make ARCH=`uname -i` install -- Cheers, Mauro Mauro, I do not know where this leads, but here is a second answer with another piece of information. I mentioned yesterday that I have at this point two kernels, called 2.6.33-smp and 2.6.33-my. The 2.6.33-smp is the stock Slackware-current kernel, and the 2.6.33-my is locally compiled, with somewhat different config parameters. Each of these has its module tree, independent of the other. By which I mean that I have a module tree lib/modules/2.6.33-smp associated with kernel 2.6.33-smp and another module tree lib/modules/2/6/33-my associated with kernel 2.6.33-my I started out, of course, by installing the gspca modules in lib/modules/2.6.33-smp and thereby I presumably over-wrote things in lib/modules/2.6.33-smp/kernel/drivers/media which were present in the 2.6.33-smp module package from the distro. Now, today I did a reinstallation of the 2.6.33-smp modules tree and booted with 2.6.33-smp. I did *not* do anything to change the what was there. For example, I did not install anything from any gspca mercurial tree. No, only what comes with the distro kernel's modules is there. Now, here is what happens under these circumstances: r...@khayyam:/lib/modules/2.6.33-smp/kernel# modprobe gspca_main WARNING: Error inserting v4l1_compat (/lib/modules/2.6.33-smp/kernel/drivers/media/video/v4l1-compat.ko): Invalid module format WARNING: Error inserting videodev (/lib/modules/2.6.33-smp/kernel/drivers/media/video/videodev.ko): Invalid module format FATAL: Error inserting gspca_main (/lib/modules/2.6.33-smp/kernel/drivers/media/video/gspca/gspca_main.ko): Invalid module format r...@khayyam:/lib/modules/2.6.33-smp/kernel# In other words, the same error message as yesterday. But this time the module I was trying to load up was not created by me, but instead it was the one obtained from the distro kernel's modules. Strangely, though, some of the other modules which came with the distro kernel _do_ work. Some of them are essential for running the machine, and they are doing just fine. Interesting. Are you sure you didn't mixed distro kernels with the ones you've compiled on your re-installation? Yes. In other words, had you removed the old /lib/modules/2.6.33-smp/ directory before re-installing it from your distro? Yes. If so, then it seems that distro is providing some broken modules. It appears so. Yes. However, in fairness to the distro, which I am not about to quit using, I am running the -current version, which is distributed with the explicit warning that stuff might occasionally be broken
Re: Invalid module format
On Sun, 7 Mar 2010, Randy Dunlap wrote: On 03/05/10 22:48, Theodore Kilgore wrote: On Sat, 6 Mar 2010, Mauro Carvalho Chehab wrote: Randy Dunlap wrote: On 03/05/10 16:51, VDR User wrote: On Fri, Mar 5, 2010 at 4:39 PM, Theodore Kilgore kilg...@banach.math.auburn.edu wrote: This is to report the good news that none of the above suspicions have panned out. I still do not know the exact cause of the problem, but a local compile and install of the 2.6.33 kernel did solve the problem. Hence, it does seem that the most likely origin of the problem is somewhere in the Slackware-current tree and the solution does not otherwise concern anyone on this list and does not need to be pursued here. I experienced the same problem and posted a new thread about it with the subject Problem with v4l tree and kernel 2.6.33. I'm a debian user as well so apparently whatever is causing this is not specific to debian or slackware. Even though you've got it working now, the source of the problem should be investigated. -- It's been several years since I last saw this error and I don't recall what caused it then. The message Invalid module format comes from either of modprobe and/or insmod when the kernel returns ENOEXEC to a module (load) syscall. Sometimes the kernel produces more explanatory messages sometimes not. If there are no more explanatory messages, then kernel/module.c can be built with DEBUGP producing more output (and then that new kernel would have to be loaded). Can one of you provide a kernel config file for a kernel/modprobe combination that produces this message? Some of the CONFIG_MODULE* config symbols could have relevance here also. I suspect that it may be related to this: # Select 32 or 64 bit config 64BIT bool 64-bit kernel if ARCH = x86 default ARCH = x86_64 ---help--- Say yes to build a 64-bit kernel - formerly known as x86_64 Say no to build a 32-bit kernel - formerly known as i386 With 2.6.33, it is now possible to compile a 32 bits kernel on a 64 bits machine without needing to pass make ARCH=i386 or to use cross-compilation. Maybe you're running a 32bits kernel, and you've compiled the out-of-tree modules with 64bits or vice-versa. My suggestion is that you should try to force the compilation wit the proper ARCH with something like: make distclean make ARCH=`uname -i` make ARCH=`uname -i` install -- Cheers, Mauro Mauro, After I did a re-compile of the kernel and modules, all the gspca stuff (at least, what I tested which is two or three cameras) all worked just fine. All I needed to do was make distclean and then make menuconfig again and the gspca setup saw my new kernel. I made sure to know this by putting up a slightly different name for it, using CONFIG_LOCALVERSION= option. So I guess to this extent I used force, but I did not need to do more than that. Now, seeing if I can help further in tracking this thing down, here are some more details. 1. As I said, the problem is fixed now, by a local re-compile of the kernel (I did change a few things in the configuration and also cleared out a lot of junk which has nothing to do with my hardware, of course). So there might be some things of interest in the two config files. Naturally, I can send them to anyone who would like to see them. But I think that I cover the important differences below. Additional comment: I probably could have taken the option of running Slackware64 if I wanted to do that, because I suspect that my hardware would support it. But I used regular Slackware. So the kernel, the modules, and everything else are 32-bit, or supposed to be, though the machine could run 64-bit. 2. According to what you are saying, here from my current config file is what might be relevant # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y CONFIG_OUTPUT_FORMAT=elf32-i386 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/i386_defconfig and also it might possibly be important, too, that the processor type I chose was CONFIG_MK8=y for the very good reason that this is what is in the machine. Also I cut the choice for support of parallel CPUs down to 2 CPUs from 8 CPUs, again because that is what is actually present. And furthermore my kernel config says CONFIG_LOCALVERSION=-my and the original one says CONFIG_LOCALVERSION=-smp so that I have two distinct sets of modules, 2.6.33-my and 2.6.33-smp and I can go back and boot from the Slackware kernel to a functioning machine, too. The kernel which I used from Slackware-current is one of the standard ones, the one called vmlinuz-huge-smp-2.6.33-smp which comes in the Slackware package called kernel-huge-smp-2.6.33_smp-i686-1.txz. Its config file is in the package, too, so here are the similar parts of it: # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y CONFIG_OUTPUT_FORMAT=elf32-i386 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/i386_defconfig The above looks
Re: Invalid module format
On Sun, 7 Mar 2010, VDR User wrote: On Fri, Mar 5, 2010 at 7:37 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: I suspect that it may be related to this: # Select 32 or 64 bit config 64BIT bool 64-bit kernel if ARCH = x86 default ARCH = x86_64 ---help--- Say yes to build a 64-bit kernel - formerly known as x86_64 Say no to build a 32-bit kernel - formerly known as i386 With 2.6.33, it is now possible to compile a 32 bits kernel on a 64 bits machine without needing to pass make ARCH=i386 or to use cross-compilation. Maybe you're running a 32bits kernel, and you've compiled the out-of-tree modules with 64bits or vice-versa. My suggestion is that you should try to force the compilation wit the proper ARCH with something like: make distclean make ARCH=`uname -i` make ARCH=`uname -i` install I had forgot to reply to this but while I do have a 64bit capable cpu, I compile use only 32bit. Same here. Let us hope it is the same problem, and it will be possible to track it down once and fix it. Theodore Kilgore
Re: Invalid module format
On Sun, 7 Mar 2010, VDR User wrote: On Fri, Mar 5, 2010 at 7:37 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: I suspect that it may be related to this: # Select 32 or 64 bit config 64BIT bool 64-bit kernel if ARCH = x86 default ARCH = x86_64 ---help--- Say yes to build a 64-bit kernel - formerly known as x86_64 Say no to build a 32-bit kernel - formerly known as i386 With 2.6.33, it is now possible to compile a 32 bits kernel on a 64 bits machine without needing to pass make ARCH=i386 or to use cross-compilation. Maybe you're running a 32bits kernel, and you've compiled the out-of-tree modules with 64bits or vice-versa. My suggestion is that you should try to force the compilation wit the proper ARCH with something like: make distclean make ARCH=`uname -i` make ARCH=`uname -i` install I had forgot to reply to this but while I do have a 64bit capable cpu, I compile use only 32bit. Hi, It seems that the problem is solved by a local re-compile of the kernel plus its modules, using the original distro .config settings in order to do this. What I suspect has happened is that there was a simultaneous minor upgrade of gcc at the same time, and it is possible that this interfered. I would further speculate that a similar problem happened with you, in your Debian installation. Hoping that we have finally tracked this down. Theodore Kilgore
Re: Invalid module format
On Sat, 6 Mar 2010, Mauro Carvalho Chehab wrote: Randy Dunlap wrote: On 03/05/10 16:51, VDR User wrote: On Fri, Mar 5, 2010 at 4:39 PM, Theodore Kilgore kilg...@banach.math.auburn.edu wrote: This is to report the good news that none of the above suspicions have panned out. I still do not know the exact cause of the problem, but a local compile and install of the 2.6.33 kernel did solve the problem. Hence, it does seem that the most likely origin of the problem is somewhere in the Slackware-current tree and the solution does not otherwise concern anyone on this list and does not need to be pursued here. I experienced the same problem and posted a new thread about it with the subject Problem with v4l tree and kernel 2.6.33. I'm a debian user as well so apparently whatever is causing this is not specific to debian or slackware. Even though you've got it working now, the source of the problem should be investigated. -- It's been several years since I last saw this error and I don't recall what caused it then. The message Invalid module format comes from either of modprobe and/or insmod when the kernel returns ENOEXEC to a module (load) syscall. Sometimes the kernel produces more explanatory messages sometimes not. If there are no more explanatory messages, then kernel/module.c can be built with DEBUGP producing more output (and then that new kernel would have to be loaded). Can one of you provide a kernel config file for a kernel/modprobe combination that produces this message? Some of the CONFIG_MODULE* config symbols could have relevance here also. I suspect that it may be related to this: # Select 32 or 64 bit config 64BIT bool 64-bit kernel if ARCH = x86 default ARCH = x86_64 ---help--- Say yes to build a 64-bit kernel - formerly known as x86_64 Say no to build a 32-bit kernel - formerly known as i386 With 2.6.33, it is now possible to compile a 32 bits kernel on a 64 bits machine without needing to pass make ARCH=i386 or to use cross-compilation. Maybe you're running a 32bits kernel, and you've compiled the out-of-tree modules with 64bits or vice-versa. My suggestion is that you should try to force the compilation wit the proper ARCH with something like: make distclean make ARCH=`uname -i` make ARCH=`uname -i` install -- Cheers, Mauro Mauro, I do not know where this leads, but here is a second answer with another piece of information. I mentioned yesterday that I have at this point two kernels, called 2.6.33-smp and 2.6.33-my. The 2.6.33-smp is the stock Slackware-current kernel, and the 2.6.33-my is locally compiled, with somewhat different config parameters. Each of these has its module tree, independent of the other. By which I mean that I have a module tree lib/modules/2.6.33-smp associated with kernel 2.6.33-smp and another module tree lib/modules/2/6/33-my associated with kernel 2.6.33-my I started out, of course, by installing the gspca modules in lib/modules/2.6.33-smp and thereby I presumably over-wrote things in lib/modules/2.6.33-smp/kernel/drivers/media which were present in the 2.6.33-smp module package from the distro. Now, today I did a reinstallation of the 2.6.33-smp modules tree and booted with 2.6.33-smp. I did *not* do anything to change the what was there. For example, I did not install anything from any gspca mercurial tree. No, only what comes with the distro kernel's modules is there. Now, here is what happens under these circumstances: r...@khayyam:/lib/modules/2.6.33-smp/kernel# modprobe gspca_main WARNING: Error inserting v4l1_compat (/lib/modules/2.6.33-smp/kernel/drivers/media/video/v4l1-compat.ko): Invalid module format WARNING: Error inserting videodev (/lib/modules/2.6.33-smp/kernel/drivers/media/video/videodev.ko): Invalid module format FATAL: Error inserting gspca_main (/lib/modules/2.6.33-smp/kernel/drivers/media/video/gspca/gspca_main.ko): Invalid module format r...@khayyam:/lib/modules/2.6.33-smp/kernel# In other words, the same error message as yesterday. But this time the module I was trying to load up was not created by me, but instead it was the one obtained from the distro kernel's modules. Strangely, though, some of the other modules which came with the distro kernel _do_ work. Some of them are essential for running the machine, and they are doing just fine. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Invalid module format
On Thu, 4 Mar 2010, Theodore Kilgore wrote: Hi, I just upgraded to the stock 2.6.33 kernel in Slackware-current. Also after having the troubles described below I cloned a completely new copy of the gspca tree from http://linuxtv.org/hg/~hgoede/gspca, intending to get some work done on a project recently started. I did make menuconfig (preceded on the first occasion by make distclean, of course) and chose my options. Then I did make and make install. When I plugged in a camera, nothing. So I tried modprobe gspca_main and here is what happens r...@khayyam:/home/kilgota/linux/gspca/gspca_hans_new3/gspca# modprobe gspca_main WARNING: Error inserting v4l1_compat (/lib/modules/2.6.33-smp/kernel/drivers/media/video/v4l1-compat.ko): Invalid module format WARNING: Error inserting videodev (/lib/modules/2.6.33-smp/kernel/drivers/media/video/videodev.ko): Invalid module format FATAL: Error inserting gspca_main (/lib/modules/2.6.33-smp/kernel/drivers/media/video/gspca/gspca_main.ko): Invalid module format r...@khayyam:/home/kilgota/linux/gspca/gspca_hans_new3/gspca# Any suggestions? Theodore Kilgore I posted about this problem on this list because I have been reading that there are recent problems with Mercurial trees, also supposing that one possible cause of the problem could lie in the compatibility layer which directs one to the right kernel, also in the reasonable suspicion that the problem could originate from the new kernel 2.6.33. This is to report the good news that none of the above suspicions have panned out. I still do not know the exact cause of the problem, but a local compile and install of the 2.6.33 kernel did solve the problem. Hence, it does seem that the most likely origin of the problem is somewhere in the Slackware-current tree and the solution does not otherwise concern anyone on this list and does not need to be pursued here. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Invalid module format
On Sat, 6 Mar 2010, Mauro Carvalho Chehab wrote: Randy Dunlap wrote: On 03/05/10 16:51, VDR User wrote: On Fri, Mar 5, 2010 at 4:39 PM, Theodore Kilgore kilg...@banach.math.auburn.edu wrote: This is to report the good news that none of the above suspicions have panned out. I still do not know the exact cause of the problem, but a local compile and install of the 2.6.33 kernel did solve the problem. Hence, it does seem that the most likely origin of the problem is somewhere in the Slackware-current tree and the solution does not otherwise concern anyone on this list and does not need to be pursued here. I experienced the same problem and posted a new thread about it with the subject Problem with v4l tree and kernel 2.6.33. I'm a debian user as well so apparently whatever is causing this is not specific to debian or slackware. Even though you've got it working now, the source of the problem should be investigated. -- It's been several years since I last saw this error and I don't recall what caused it then. The message Invalid module format comes from either of modprobe and/or insmod when the kernel returns ENOEXEC to a module (load) syscall. Sometimes the kernel produces more explanatory messages sometimes not. If there are no more explanatory messages, then kernel/module.c can be built with DEBUGP producing more output (and then that new kernel would have to be loaded). Can one of you provide a kernel config file for a kernel/modprobe combination that produces this message? Some of the CONFIG_MODULE* config symbols could have relevance here also. I suspect that it may be related to this: # Select 32 or 64 bit config 64BIT bool 64-bit kernel if ARCH = x86 default ARCH = x86_64 ---help--- Say yes to build a 64-bit kernel - formerly known as x86_64 Say no to build a 32-bit kernel - formerly known as i386 With 2.6.33, it is now possible to compile a 32 bits kernel on a 64 bits machine without needing to pass make ARCH=i386 or to use cross-compilation. Maybe you're running a 32bits kernel, and you've compiled the out-of-tree modules with 64bits or vice-versa. My suggestion is that you should try to force the compilation wit the proper ARCH with something like: make distclean make ARCH=`uname -i` make ARCH=`uname -i` install -- Cheers, Mauro Mauro, After I did a re-compile of the kernel and modules, all the gspca stuff (at least, what I tested which is two or three cameras) all worked just fine. All I needed to do was make distclean and then make menuconfig again and the gspca setup saw my new kernel. I made sure to know this by putting up a slightly different name for it, using CONFIG_LOCALVERSION= option. So I guess to this extent I used force, but I did not need to do more than that. Now, seeing if I can help further in tracking this thing down, here are some more details. 1. As I said, the problem is fixed now, by a local re-compile of the kernel (I did change a few things in the configuration and also cleared out a lot of junk which has nothing to do with my hardware, of course). So there might be some things of interest in the two config files. Naturally, I can send them to anyone who would like to see them. But I think that I cover the important differences below. Additional comment: I probably could have taken the option of running Slackware64 if I wanted to do that, because I suspect that my hardware would support it. But I used regular Slackware. So the kernel, the modules, and everything else are 32-bit, or supposed to be, though the machine could run 64-bit. 2. According to what you are saying, here from my current config file is what might be relevant # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y CONFIG_OUTPUT_FORMAT=elf32-i386 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/i386_defconfig and also it might possibly be important, too, that the processor type I chose was CONFIG_MK8=y for the very good reason that this is what is in the machine. Also I cut the choice for support of parallel CPUs down to 2 CPUs from 8 CPUs, again because that is what is actually present. And furthermore my kernel config says CONFIG_LOCALVERSION=-my and the original one says CONFIG_LOCALVERSION=-smp so that I have two distinct sets of modules, 2.6.33-my and 2.6.33-smp and I can go back and boot from the Slackware kernel to a functioning machine, too. The kernel which I used from Slackware-current is one of the standard ones, the one called vmlinuz-huge-smp-2.6.33-smp which comes in the Slackware package called kernel-huge-smp-2.6.33_smp-i686-1.txz. Its config file is in the package, too, so here are the similar parts of it: # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y CONFIG_OUTPUT_FORMAT=elf32-i386 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/i386_defconfig The above looks the same to me as my choices. But the CPU
Invalid module format
Hi, I just upgraded to the stock 2.6.33 kernel in Slackware-current. Also after having the troubles described below I cloned a completely new copy of the gspca tree from http://linuxtv.org/hg/~hgoede/gspca, intending to get some work done on a project recently started. I did make menuconfig (preceded on the first occasion by make distclean, of course) and chose my options. Then I did make and make install. When I plugged in a camera, nothing. So I tried modprobe gspca_main and here is what happens r...@khayyam:/home/kilgota/linux/gspca/gspca_hans_new3/gspca# modprobe gspca_main WARNING: Error inserting v4l1_compat (/lib/modules/2.6.33-smp/kernel/drivers/media/video/v4l1-compat.ko): Invalid module format WARNING: Error inserting videodev (/lib/modules/2.6.33-smp/kernel/drivers/media/video/videodev.ko): Invalid module format FATAL: Error inserting gspca_main (/lib/modules/2.6.33-smp/kernel/drivers/media/video/gspca/gspca_main.ko): Invalid module format r...@khayyam:/home/kilgota/linux/gspca/gspca_hans_new3/gspca# Any suggestions? Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 0979:0280 :-) (fwd)
This is the first of two mails I am sending. The problem is about a jeilinj camera which is not working. The second mail indicates that the problem seems to have been in a certain external USB hub, through which the camera was connected. So, one might say the problem is fixed but in case there is need to dig more deeply I am reporting this. I do find the reported error to be very strange, namely (a typical specimen) Jan 28 17:56:18 linux kernel: [26920.452427] gspca: frame overflow 77885 77824 Please see the next mail, too. Theodore Kilgore -- Forwarded message -- Date: Fri, 29 Jan 2010 09:06:26 +0100 From: Matthias Huber matthias.hu...@wollishausen.de To: Theodore Kilgore kilg...@banach.math.auburn.edu Subject: Re: 0979:0280 :-) 29.01.2010 02:24, Theodore Kilgore : On Thu, 28 Jan 2010, Matthias Huber wrote: 28.01.2010 20:03, Theodore Kilgore : On Thu, 28 Jan 2010, Matthias Huber wrote: 28.01.2010 18:36, Theodore Kilgore : On Thu, 28 Jan 2010, Matthias Huber wrote: Well, I guess one needs some more information. If jlj_startup() is returning 0 then that is not exactly an error. What else is going on? Theodore Kilgore Now i have a few unsuccessful tries: (problem seems to be here the frame overflow) Jan 28 17:54:48 linux kernel: [26830.766387] jeilinj: deregistered Jan 28 17:54:56 linux kernel: [26838.306693] gspca: probing 0979:0280 Jan 28 17:54:56 linux kernel: [26838.306701] jeilinj: JEILINJ camera detected (vid/pid 0x0979:0x0280) Jan 28 17:54:56 linux kernel: [26838.306791] gspca: video1 created Jan 28 17:54:56 linux kernel: [26838.306808] usbcore: registered new interface driver jeilinj Jan 28 17:54:56 linux kernel: [26838.306812] jeilinj: registered Jan 28 17:55:14 linux matthias: first try Jan 28 17:55:28 linux kernel: [26870.892905] jeilinj: jlj_start retval is 0 Jan 28 17:55:55 linux matthias: result: try was unsuccessful, window stayed empty Jan 28 17:56:16 linux kernel: [26918.931515] jeilinj: jlj_start retval is 0 Jan 28 17:56:17 linux kernel: [26919.192148] gspca: frame overflow 77885 77824 Jan 28 17:56:17 linux kernel: [26919.332527] gspca: frame overflow 77885 77824 Jan 28 17:56:17 linux kernel: [26919.496030] gspca: frame overflow 77885 77824 Jan 28 17:56:17 linux kernel: [26919.657412] gspca: frame overflow 77885 77824 Jan 28 17:56:17 linux kernel: [26919.815662] gspca: frame overflow 77885 77824 Jan 28 17:56:17 linux kernel: [26919.975667] gspca: frame overflow 77885 77824 Jan 28 17:56:17 linux kernel: [26920.132793] gspca: frame overflow 77885 77824 Jan 28 17:56:18 linux kernel: [26920.293049] gspca: frame overflow 77885 77824 Jan 28 17:56:18 linux kernel: [26920.452427] gspca: frame overflow 77885 77824 Jan 28 17:56:18 linux kernel: [26920.612805] gspca: frame overflow 77885 77824 Jan 28 17:56:18 linux kernel: [26920.774057] gspca: frame overflow 77885 77824 Jan 28 17:56:24 linux matthias: result: second try was unsuccessful, window stayed empty Jan 28 17:56:35 linux matthias: try three Jan 28 17:56:37 linux kernel: [26939.307986] jeilinj: jlj_start retval is 0 Jan 28 17:56:45 linux matthias: result: try was unsuccessful, window stayed empty Jan 28 17:56:47 linux kernel: [26949.358593] jeilinj: jlj_start retval is 0 Jan 28 17:56:47 linux kernel: [26949.601474] gspca: frame overflow 77885 77824 Jan 28 17:56:47 linux kernel: [26949.739477] gspca: frame overflow 77885 77824 Jan 28 17:56:47 linux kernel: [26949.891633] gspca: frame overflow 77885 77824 Jan 28 17:56:47 linux kernel: [26950.048487] gspca: frame overflow 77885 77824 Jan 28 17:56:48 linux kernel: [26950.208738] gspca: frame overflow 77885 77824 Jan 28 17:56:48 linux kernel: [26950.368497] gspca: frame overflow 77885 77824 Jan 28 17:56:48 linux kernel: [26950.528500] gspca: frame overflow 77885 77824 Jan 28 17:56:50 linux matthias: result: try was unsuccessful, window stayed empty Jan 28 17:56:52 linux kernel: [26954.171578] jeilinj: jlj_start retval is 0 Jan 28 17:57:18 linux matthias: try from user matz Jan 28 17:57:24 linux kernel: [26987.147964] jeilinj: jlj_start retval is 0 Jan 28 17:57:25 linux kernel: [26987.374362] gspca: frame overflow 77885 77824 Jan 28 17:57:25 linux kernel: [26987.512100] gspca: frame overflow 77885 77824 Jan 28 17:57:25 linux kernel: [26987.650728] gspca: frame overflow 77885 77824 Jan 28 17:57:25 linux kernel: [26987.803980] gspca: frame overflow 77885 77824 Jan 28 17:57:25 linux kernel: [26987.965110] gspca: frame overflow 77885 77824 Jan 28 17:57:25 linux kernel: [26988.123614] gspca: frame overflow 77885 77824 Jan 28 17:57:26 linux kernel: [26988.284368] gspca: frame overflow 77885 77824 Jan 28 17:57:26 linux kernel: [26988.443495] gspca: frame overflow 77885 77824 Jan 28 17:57:26 linux kernel: [26988.607500] gspca: frame overflow 77885 77824 Jan 28 17:58:44 linux kernel: [27066.439232] usbcore: deregistering interface driver jeilinj Jan 28 17:58:44 linux
Re: solved // more debug from 979:280 (fwd)
For further background see my previous message. This message explains that the problem with device 0x0979:0x0280 which Matthias was having appears to be related to running the camera through his USB 2.0 hub (details below). I should also mention that I have a similar camera myself (same ID) and so does Andy Walls. I never had any such problems with my camera, but I do not even own any external USB hub. Theodore Kilgore -- Forwarded message -- Date: Fri, 29 Jan 2010 17:49:39 +0100 From: Matthias Huber matthias.hu...@wollishausen.de To: Theodore Kilgore kilg...@banach.math.auburn.edu Cc: Andy Walls awa...@radix.net Subject: Re: solved // more debug from 979:280 29.01.2010 17:32, Theodore Kilgore : Andy, Matthias found the solution, but it seems to me that the problems involved might possibly need more attention from some quarter, not necessarily from linux-media, but possibly from linux-usb: Briefly, Matthias is saying that the problem arises when he plugs the camera in on his USB 2.0 port. and now i can say that it is this special usb2.0 hub. on the market the vendor calles itself digitus, but i think this is a german vendor. i tried another super-cheap hub of a cube with time, temperature, and changing colors and holder for pens, and this hub works ok with the camera. because of that it seems, that the problem is hub-specific. the working hub calls: Bus 003 Device 010: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize064 idVendor 0x05e3 Genesys Logic, Inc. idProduct 0x0608 USB-2.0 4-Port HUB bcdDevice9.01 iManufacturer 0 iProduct1 USB2.0 Hub iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 255 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 4 wHubCharacteristic 0x00e0 Ganged power switching Ganged overcurrent protection Port indicators bPwrOn2PwrGood 50 * 2 milli seconds bHubContrCurrent100 milli Ampere DeviceRemovable0x00 PortPwrCtrlMask0xff Hub Port Status: Port 1: .0100 power Port 2: .0100 power Port 3: .0103 power enable connect Port 4: .0100 power Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 1 Single TT bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x0001 Self Powered My impression is that, at least in theory, there is not supposed to be any problem, even so. Of course, the problem could be one which was present in 2.6.28 and has been fixed now that we have 2.6.32. What do you think? Theodore Kilgore On Fri, 29 Jan 2010, Matthias Huber wrote: Good Morning (?) Theodore, today i made some tries again with the camera: the first resulted in a big crash (system hung). i tried magic sysrq, but only with partial success. the error on the first try was: it created video0, which is my dvb-card in the second try, one sees the misunderstanding between jeilinj and gspca_main about the buffer size. another successful try shows correct parameters for frame size. and the solution was: (i remembered from our last communicaiton about the camera) *** not to use my usb-2.0 hub, which seems to work buggy. or at least the camera on it works buggy. (maybe a timing problem ?) this hub often has the problem, that after some connects / disconnects, one has to power off and on for enumerating again plugged devices on it. so i don't know, if this is a general problem in gspca-timing or not. the usb-hub with the problem is: m...@linux:~$ lsusb -v Bus 001 Device
Re: PAC7302 short datasheet from PixArt
On Sat, 30 Jan 2010, Németh Márton wrote: Hi, if anyone interested there is a brief overview datasheet about PixArt PAC7301/PAC7302 at http://www.pixart.com.tw/upload/PAC7301_7302%20%20Spec%20V1_20091228174030.pdf Márton, First, I am glad that mouse-copying reproduces the accent in your name. If you can help explain how to reproduce such things by typing while using apine over an ssh connection, using a standard US keyboard, I would be glad of the explanation. My wife is Hungarian, and I am thus very sensitized to the importance of the question, how to do the accents required for writing Hungarian properly. Now, as to the substance of the mail above, thanks a lot. I had a bunch of the PixArt datasheets already, but I had missed that one. I would have a question, though: This datasheet gives a lot of information about pinouts on the sensor chip and such good stuff which might be useful if one were constructing a circuit board on which to put the chip. What it does not give, very unfortunately, is any information about the command set which needs to be sent across the USB connection, which in turn actuates the circuits which in turn sends something to the sensor across one of those pins. For example, to set green gain one has to do something on connector X. But how does one send a command from the computer which does something on connector X? Some other datasheets from some other companies (Omnivision, for example) do seem occasionally to provide such information. Thus, a question for you or for anyone else who reads it: Has anyone figured out any shortcuts for matching up the missing pieces of information? Probably the answer is no but I think this is the kind of question which is worth asking again on some periodic basis. Theodore Kilgore
Re: Problems with cx18
On Mon, 25 Jan 2010, Mauro Carvalho Chehab wrote: Hi Devin/Andy/Jean, snip The sq905c has a warning. snip drivers/media/video/gspca/sq905c.c: In function ?sd_config?: drivers/media/video/gspca/sq905c.c:207: warning: unused variable ?i? snip Please fix. Cheers, Mauro. This one has been fixed, already. A more recent version of sq905c.c is in the pipeline somewhere. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sq905c: remove unused variable and other topics
On Sun, 24 Jan 2010, Jean-Francois Moine wrote:
On Sat, 23 Jan 2010 19:44:06 -0600 (CST)
Theodore Kilgore kilg...@banach.math.auburn.edu wrote:
If everyone else is agreeable, I would propose that the recent
changes to sq905c.c should simply be pulled, and that is the best
solution to the problem.
A pull request for this change has been sent last sunday.
Jean-Francois,
Thanks.
I would also like to address three other items.
1. For a long time I was not getting the mail from this list. I could
not figure out what was the matter, but I finally remember what happened:
I went on a two week vacation last summer, and I unsubscribed before I
left home, since I did not want to deal with what seemed like several
hundred messages a day piling up unread in my inbox. Then when I got back
I was too busy trying to catch up with work to remember to resubscribe.
Fixed, now.
2. I hope that when you got the sq905c changes that you also pulled the
changes for mr97310a.c. Several things have been done there recently.
First, there was a patch to the initialization for one of the types of
supported cameras. Without that patch the camera will work only on a host
machine with OHCI USB support and will fail to stream when hooked to a
host machine with a UHCI controller. There was a desperate, last minute
attempt to get this patch into 2.6.32, the urgency of which apparently
failed to convince the higher-ups and it did not get in. The only excuse
for the bad timing is the obvious one, that who could imagine that such a
problem could occur until actually confronted with it? It is just too
weird. I do not know the current status of this patch.
Second, other cleanups have been done to mr97310a.c
Third, another camera with yet another init sequence and control
capabilities has been discovered, and it is added to mr97310a.c
I would say that the most recent version of the mr97310a driver is the
best and most bug-free of the versions, and I hope it gets used.
3. The sn9c2028 driver. It runs the three sn9c2028 cameras that I have on
hand and does so pretty well.
I would characterize the driver as unfinished, though. For, there are at
least two cameras supported there which I do not and never did personally
own, and therefore I cannot test them. I do have init sequences which are
based upon snoops previously done, and I put those in the driver.
Unfortunately, I have been unable to get anyone else to test those two
cameras, either. Apparently, the only way to get them tested is to send
the driver mainstream. After that, perhaps I will get reports whether they
work, or not!
The two cameras in question which are untested or are incompletely tested
are (quoting from sn9c2028.c)
{USB_DEVICE(0x0458, 0x7005)}, /* Genius Smart 300, version 2 */
/* The Genius Smart is untested. I can't find an owner ! */
and
{USB_DEVICE(0x0c45, 0x8008)}, /* Mini-Shotz ms-350 */
where the owner tells me that the code I sent him works, but he can not do
more testing right now because he is too busy (wife is having first
child). The Mini-Shotz has obvious redundancies and bactrackings in the
init sequence which is used in the OEM driver. I would very much like to
be able to clean out all the crud which is in the OEM init sequence, but I
have no way to know exactly what is needed, without testing.
Thus, if anyone who reads this has either of the above sn9c2028 cameras or
any other one which is not currently supported at all, please contact me.
There is a lot of unfinished business with the sn9c2028 driver. I would
very much like for it to get done. But said work depends upon finding
owners and testers.
Theodore Kilgore
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sq905c: remove unused variable
On Sat, 23 Jan 2010, Douglas Schilling Landgraf wrote:
Removed unused variable.
Signed-off-by: Douglas Schilling Landgraf dougsl...@redhat.com
Thanks,
Douglas
Douglas,
Thanks for your sharp eyes.
However, I _think_ that this particular problem may have already been
fixed, recently if not some time before. In particular, recent changes
have been done in the version of sq905c.c which lives in the gspca tree of
Hans de Goede. I am working off his tree these days because we have been
doing a number of things together, and thus the changes there to sq905c.c
have been done by a patch from here.
These changes were done in order to add a couple of new cameras and to
change the way to decide whether the camera is a VGA or a CIF camera. The
determination of this by USB Product number does not always work, and one
needs to read an ID string from the camera in order to learn it better.
Who bought the camera which has the wrong resolution setting associated
with its USB Product number? Hans de Goede.
It appears to me that this patch is not relevant to that most recent
version of sq905c.c. At least, it does not fit here, which is where it
appears it is supposed to fit:
/* This function is called at probe time just before sd_init */
static int sd_config(struct gspca_dev *gspca_dev,
const struct usb_device_id *id)
{
struct cam *cam = gspca_dev-cam;
struct sd *dev = (struct sd *) gspca_dev;
int ret;
PDEBUG(D_PROBE,
SQ9050 camera detected
If everyone else is agreeable, I would propose that the recent changes to
sq905c.c should simply be pulled, and that is the best solution to the
problem.
Hans, can you confirm all of this?
Theodore Kilgore
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] which fixes works on OHCI and fails on UHCI problem for mr97310a cameras
Hans,
If you read the mail to Oliver Neukum on the linux-usb list, then you know
that I found a cure for the mysterious problem that the MR97310a CIF
type 1 cameras have been freezing up and refusing to stream if hooked
up to a machine with a UHCI controller.
Namely, the cure is that if the camera is an mr97310a CIF type 1 camera,
you have to send it 0xa0, 0x00. Somehow, this is a timing reset command,
or such. It un-blocks whatever was previously stopping the CIF type 1
cameras from working on the UHCI-based machines.
I have made a patch from your tree, which is below. I think that you
should use all efforts to get your version of mr97310a.c with this patch
applied to it, into upstream immediately. For, it fixes the
rather nasty problem that the CIF type 1 cameras refuse to stream on a
machine with a UHCI-based controller.
Fixing that problem is on top of the fact that the code which is at
present in 2.6.32-rc6 uses the old detection scheme for the sensor type of
the camera and is inferior in several other aspects, too. Therefore, I
strongly support the idea of replacing the file gspca/mr97310a.c in
2.6.32-rc6 with the patched version of the file from your tree.
As I said, the patch is based upon the code in your tree, not upon the
version which is in 2.6.32-rc6. But the resulting version of mr97310a.c
has been tested here on several machines, including one running
2.6.32-rc6 which has a UHCI controller inside. And it works nicely on all
of them.
Theodore Kilgore
Signed off by: Theodore Kilgore kilg...@auburn.edu
-
diff -r 577440e8b8df linux/drivers/media/video/gspca/mr97310a.c
--- a/linux/drivers/media/video/gspca/mr97310a.cSun Nov 01
17:09:15 2009 +0100
+++ b/linux/drivers/media/video/gspca/mr97310a.cSat Nov 14
16:32:18 2009 -0600
@@ -697,6 +697,11 @@
{0x13, 0x00, {0x01}, 1},
{0, 0, {0}, 0}
};
+ /* Without this command the cam won't work with USB-UHCI
*/
+ gspca_dev-usb_buf[0] = 0x0a;
+ gspca_dev-usb_buf[1] = 0x00;
+ if (mr_write(gspca_dev, 2) 0)
+ PDEBUG(D_ERR, start_cif_cam fails);
err_code = sensor_write_regs(gspca_dev,
cif_sensor1_init_data,
ARRAY_SIZE(cif_sensor1_init_data));
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] gspca pac7302/pac7311: simplify pac_find_sof
On Mon, 2 Nov 2009, Németh Márton wrote:
Theodore Kilgore wrote:
On Sun, 1 Nov 2009, Németh Márton wrote:
Remove struct sd dependency from pac_find_sof() function implementation.
This step prepares separation of pac7302 and pac7311 specific parts of
struct sd.
[...]
But here is the point. The sn9c2028 cameras have a structure which seems
similar to the mr97310a cameras. They use a similar decompression
algorithm. They have a similar frame header. Specifically, the sn9c2028
frame header starts with the five bytes
0xff, 0xff, 0x00, 0xc4, 0xc4
whereas the pac_common frame header starts with the five bytes
0xff, 0xff, 0x00, 0xff, 0x96
Right now, for my own use, I have written a file sn9c2028.h which
essentially duplicates the functionality of pac_common.h and contains a
function which searches for the sn9c2028 SOF marker instead of searching
for the pac SOF marker. Is this necessarily the good, permanent solution?
I am not so sure about that.
I think the pac_find_sof() is a special case. To find a SOF sequence in
a bigger buffer in general needs to first analyze the SOF sequence for
repeated bytes. If there are repeated bytes the search have to be
continued in a different way, see the state machine currently in the
pac_common.h. To find the sn9c2028 frame header a different state machine
is needed. It might be possible to implement a search function which
can find any SOF sequence but I am afraid that this algorithm would be
too complicated because of the search string analysis.
Well, I do not really know enough about this to be able to say something
authoritative, but:
1. There is an obvious limitation on the length of the SOF marker. If it
is agreed upon that the SOF marker is 5 bytes or less, then it ought not
to be so terrible a thing to do. Namely, your state machine should accept
an input, consisting of a pointer to the proper SOF marker and use that
one instead of what is hard wired in your code. So, for example,
switch (sd-sof_read) {
case 0:
if (m[i] == 0xff)
sd-sof_read = 1;
break;
case 1:
if (m[i] == 0xff)
sd-sof_read = 2;
else
sd-sof_read = 0;
break;
(and so on)
could read instead as
switch (sd-sof_read) {
case 0:
if (m[i] == sof_marker[0])
sd-sof_read = 1;
break;
case 1:
if (m[i] == sof_marker[1])
sd-sof_read = 2;
else
sd-sof_read = 0;
break;
(and so on)
The problem would come if the SOF marker were six bytes long instead. The
way to solve that would be to figure out what is the longest SOF marker
that one wants to deal with, beforehand. I am not sure what is the
prevailing number of bytes in such an SOF marker, or the maximum number.
But it would be possible to prescribe some reasonable maximum number
and take that into account, I think.
2. Although it seems to me it would not be a terribly big deal to code the
above, there is the question whether it would significantly slow the
algorithm down to be required to go and read the variable sof_marker[]. My
instinct is that it would cost practically nothing to do that, but I am
not the expert on such matters, which is why I put the disclaimer at the
top. If somebody who knows what he is talking about says this idea causes
a speed or timing problem, then forget about it. In that case it is better
to have another function for every camera.
Theodore Kilgore
Re: [PATCH 1/3] gspca pac7302/pac7311: simplify pac_find_sof
On Mon, 2 Nov 2009, Németh Márton wrote:
Theodore Kilgore írta:
On Mon, 2 Nov 2009, Németh Márton wrote:
Theodore Kilgore wrote:
On Sun, 1 Nov 2009, Németh Márton wrote:
Remove struct sd dependency from pac_find_sof() function implementation.
This step prepares separation of pac7302 and pac7311 specific parts of
struct sd.
[...]
But here is the point. The sn9c2028 cameras have a structure which seems
similar to the mr97310a cameras. They use a similar decompression
algorithm. They have a similar frame header. Specifically, the sn9c2028
frame header starts with the five bytes
0xff, 0xff, 0x00, 0xc4, 0xc4
whereas the pac_common frame header starts with the five bytes
0xff, 0xff, 0x00, 0xff, 0x96
Right now, for my own use, I have written a file sn9c2028.h which
essentially duplicates the functionality of pac_common.h and contains a
function which searches for the sn9c2028 SOF marker instead of searching
for the pac SOF marker. Is this necessarily the good, permanent solution?
I am not so sure about that.
I think the pac_find_sof() is a special case. To find a SOF sequence in
a bigger buffer in general needs to first analyze the SOF sequence for
repeated bytes. If there are repeated bytes the search have to be
continued in a different way, see the state machine currently in the
pac_common.h. To find the sn9c2028 frame header a different state machine
is needed. It might be possible to implement a search function which
can find any SOF sequence but I am afraid that this algorithm would be
too complicated because of the search string analysis.
Well, I do not really know enough about this to be able to say something
authoritative, but:
1. There is an obvious limitation on the length of the SOF marker. If it
is agreed upon that the SOF marker is 5 bytes or less, then it ought not
to be so terrible a thing to do. Namely, your state machine should accept
an input, consisting of a pointer to the proper SOF marker and use that
one instead of what is hard wired in your code. So, for example,
switch (sd-sof_read) {
case 0:
if (m[i] == 0xff)
sd-sof_read = 1;
break;
case 1:
if (m[i] == 0xff)
sd-sof_read = 2;
else
sd-sof_read = 0;
break;
(and so on)
could read instead as
switch (sd-sof_read) {
case 0:
if (m[i] == sof_marker[0])
sd-sof_read = 1;
break;
case 1:
if (m[i] == sof_marker[1])
sd-sof_read = 2;
else
sd-sof_read = 0;
break;
(and so on)
The problem would come if the SOF marker were six bytes long instead. The
way to solve that would be to figure out what is the longest SOF marker
that one wants to deal with, beforehand. I am not sure what is the
prevailing number of bytes in such an SOF marker, or the maximum number.
But it would be possible to prescribe some reasonable maximum number
and take that into account, I think.
I am afraid you missed an important point: the state machine depends on the
*contents* of the SOF marker:
From pac_common.h:
The following state machine finds the SOF marker sequence
0xff, 0xff, 0x00, 0xff, 0x96 in a byte stream.
+--+
| 0: START |---\
+--+-\ |
| \---/otherwise|
v 0xff|
+--+ otherwise |
| 1|---*
| |^
+--+|
| |
v 0xff|
+--+-\0xff |
/-| |--/ |
| | 2|---*
| | | otherwise ^
| +--+|
|| |
|v 0x00|
| +--+|
| | 3||
| | |---*
| +--+ otherwise ^
|| |
0xff |v 0xff|
| +--+|
\--| 4||
| |/
+--+ otherwise
|
v 0x96
+--+
| FOUND |
+--+
Please have a closer look of the transients 2-2 and
4-2. They heavily depend on the 0xff bytes found in the
SOF marker.
Yes, on second look I see
Re: [PATCH 1/3] gspca pac7302/pac7311: simplify pac_find_sof
On Sun, 1 Nov 2009, Németh Márton wrote: From: Márton Németh nm...@freemail.hu Remove struct sd dependency from pac_find_sof() function implementation. This step prepares separation of pac7302 and pac7311 specific parts of struct sd. Signed-off-by: Márton Németh nm...@freemail.hu Cc: Thomas Kaiser tho...@kaiser-linux.li Cc: Theodore Kilgore kilg...@auburn.edu Cc: Kyle Guinn ely...@gmail.com snip Szia Marton, As long as these things work, I would not mind at all. But perhaps this is a good occasion to bring up an issue which seems to me very much related. It is the following: Along with the (it seems to be never-ending) work on the mr97310a driver, I have been working on a driver for the sn9c2028 cameras. The driver at this point functions, and seems to function quite well. But it also seems to me that the code needs quite a bit of polishing before it is publicized. Since I have been very much preoccupied with finishing the mr97310a driver (why does the last 5% of a job sometimes take the most time?) this final polishing of the sn9c2028 driver has not yet occurred, sorry to say. But here is the point. The sn9c2028 cameras have a structure which seems similar to the mr97310a cameras. They use a similar decompression algorithm. They have a similar frame header. Specifically, the sn9c2028 frame header starts with the five bytes 0xff, 0xff, 0x00, 0xc4, 0xc4 whereas the pac_common frame header starts with the five bytes 0xff, 0xff, 0x00, 0xff, 0x96 Right now, for my own use, I have written a file sn9c2028.h which essentially duplicates the functionality of pac_common.h and contains a function which searches for the sn9c2028 SOF marker instead of searching for the pac SOF marker. Is this necessarily the good, permanent solution? I am not so sure about that. Perhaps when making changes it is a good time to think over the idea of combining things which are in fact not very much different. After all, another set of cameras might come along, too, which essentially requires yet another minor variation on the same basic algorithm. Then we are supposed to have three .h files with three functions which have the same code and just search for slightly different strings? I am well aware that you started out to do something different, but how does this strike you? Theodore Kilgore
Re: [PATCH] to add support for certain Jeilin dual-mode cameras.
On Mon, 3 Aug 2009, Jean-Francois Moine wrote:
On Sun, 2 Aug 2009 14:12:28 -0500 (CDT)
Theodore Kilgore kilg...@banach.math.auburn.edu wrote:
[snip]
- as there is only one vend:prod, one line is enough in gspca.txt.
This is a question about which I have been curious for quite some
time, and I think that now is a good time to ask it.
Just what policy do we have about this? The information which links
brand and model to driver ought to be presented somewhere. If it does
not go into gspca.txt then where exactly is the appropriate place to
put said information?
[snip]
Hi Theodore,
gspca.txt has been defined only to know which subdriver has to be
generated for a webcam that a user already owns.
The trade name of the webcams are often not clear enough (look at all
the Creative varieties). So, the user has just to plug her webcam and
with the vend:prod ID, she will know which driver she has to generate
So, from this the general advice to users is
1. Buy a camera
2. Plug it in to see if it has a driver?
(you may say that there are already tools which do the job, as easycam,
but I do not think they are often used).
The problem is, the USB ID (and hence the driver) are not publicized by
anyone connected to the manufacturer or the retailer. So the result is
that there is a lot of hardware out there which is is currently unusable
and nobody knows that, and also lots of hardware out there which is
perfectly usable because we already supported it, but again nobody knows
that. The corollary is that the trade names you refer to ought to be
listed _somewhere_ as completely, clearly, and precisely as possible. To
me, and obviously good place to start with that would be to list somewhere
in the kernel documentation the devices supported by a given driver or
module.
The device list of the other drivers (CARDLIST.xx) are not sorted and
their format (numbered list) does not facilitate this job. So, I
prefered a list sorted by vend:prod.
In gspca.txt, the 3rd column contains the webcam names. As you can see,
it is a comma separated list, so, you may put here all the names you may
know. But, is it useful?
I would certainly hope so. Otherwise, why bother to put any names in there
at all?
I think that the webcam names should be only
in the file usb.ids which comes with the usbutils.
That file is hopelessly out of date, by definition, and occasionally
seems to me inaccurate in such details as ownership of USB ID X by
company Y, for which, for example, see the association of 0x2770 (SQ
Technologies) to the Japanese camera and electronics packager and
retailer NHL.
More relevant to the present discussion, though, is that even if the
usb.ids file were completely up to date it serves an entirely different
purpose from what we are discussing here. My understanding is that the
usb.ids file is supposed to be nothing but an inventory of the devices
that we know about. It was never intended as a list of supported devices
and by its nature can not serve that purpose simultaneously. Also, a lot
of USB devices come under the category of who cares what the Vendor and
Product number are? such as standard mass storage pocket flash drives. So
I suspect that no one is conscientious about listing them.
To go further, there should be a general file which should contain all
the usb (and pci) devices and their associated drivers. This
information exists in /lib/modules/`uname -r`/modules.usbmap when all
drivers are generated. So, we just need a tool (and a guy!) to maintain
this general file...
Hmm. Yes. The guy. Well, it is better to figure out a way to make
things like that happen automatically, and then one does not need to worry
so much about the guy. I will mention how Gphoto handles this problem,
for comparison. It might not be so easy to carry out here, because what
finally comes is the command option gphoto2 --list-cameras. That command
will print out a (very long) list of all the currently nsupported cameras,
by name. At this point, the list has over 1000 entries. It is up to the
writer of the camera library to list the cameras which are supported by
that particular piece of software. So the entry instead of just looking
like this
/* Table of supported USB devices */
static const __devinitdata struct usb_device_id device_table[] = {
{USB_DEVICE(0x2770, 0x905c)},
{USB_DEVICE(0x2770, 0x9050)},
{USB_DEVICE(0x2770, 0x913d)},
{}
};
must contain two other additional fields, describing the name in
human-readable form (intended to identify the camera to the extent that
one can probably pick it out from others on the shelf) and the current
status of the support for the camera. Like this:
{Sakar Micro Digital 2428x, GP_DRIVER_STATUS_EXPERIMENTAL, 0x2770, 0x905c},
{Jazz JDC9, GP_DRIVER_STATUS_EXPERIMENTAL, 0x2770, 0x905c},
{Disney pix micro,GP_DRIVER_STATUS_EXPERIMENTAL, 0x2770, 0x9050},
{Disney
Re: [PATCH] to add support for certain Jeilin dual-mode cameras.
On Mon, 3 Aug 2009, Mauro Carvalho Chehab wrote:
On Mon, 3 Aug 2009, Theodore Kilgore wrote:
snip
static const __devinitdata struct usb_device_id device_table[] = {
{USB_DEVICE(0x2770, 0x905c), .driver_info =
SAKAR_MICRO_DIGITAL_2428X},
{USB_DEVICE(0x2770, 0x9050), .driver_info = DISNEY_PIX_MICRO},
{USB_DEVICE(0x2770, 0x9052), .driver_info = DISNEY_PIX_MICRO2},
{USB_DEVICE(0x2770, 0x913d), .driver_info =
SUPREMA_DIGITAL_KEYCHAIN_CAMERA},
{}
};
Incidentally, the above was only a small snippet from the list given in
libgphoto2/camlibs/digigr8/library.c. The entire list is quite a bit
longer. As I mentioned in a post yesterday, there are seventeen entries in
all. That seventeen is a sample of the numbers that one often has to deal
with. The reason I say that the entire list ought to be available and
publicized somehow is that people simply would not know that these
seventeen cameras are all supported in webcam mode (and by the same driver
module, too!) unless someone informs them.
OK, so here was your first suggestion:
struct camera_description {
char *name;
unsigned int flags;
};
static struct camera_description cameras[] = {
[SAKAR_MICRO_DIGITAL_2428X] = {
.name = Sakar Micro Digital 2428x/Jazz JDC9,
.flags = GP_DRIVER_STATUS_EXPERIMENTAL,
},
[DISNEY_PIX_MICRO] = {
.name = Disney pix micro,
.flags = GP_DRIVER_STATUS_EXPERIMENTAL,
},
[DISNEY_PIX_MICRO2] = {
.name = Disney pix micro 2,
.flags = GP_DRIVER_STATUS_EXPERIMENTAL,
},
[SUPREMA_DIGITAL_KEYCHAIN_CAMERA] = {
.name = Suprema Digital Keychain Camera,
.flags = GP_DRIVER_STATUS_EXPERIMENTAL,
},
};
The association between the two tables can easily be done at the .config
ops:
/* this function is called at probe time */
static int sd_config(struct gspca_dev *gspca_dev,
const struct usb_device_id *id)
{
...
int board_nr = id-driver_info;
printf(KERN_WARN Detected camera %s\n, cameras[board_nr]);
Incidentally, if two cameras have the same USB ID _and_ are otherwise
functionally identical (these are not necessarily the same thing) then I
think the physical camera will not always be the same as the detected
camera. So, while it is always nice to have debug messages, that is not
otherwise solving very much.
...
}
A small change at cx88.pl will be enough to auto-generate gspca.txt.
Mauro, this is impressive. First, you point out that Gphoto could have done
the job more efficiently, and it seems to me that you are right. Then you
point out that to make such a change would break compatibility with the
Linux kernel's struct usb_device_id so it cannot be done that way. Then you
provide a workaround. It is very clever.
This kind of trick is used already on several other drivers: cx88, bttv,
em28xx, usbvision, saa7134, ...
However, another side of me says that all of this workaround would have to
get compiled into the code for every gspca driver, making the code for each
driver, and the resulting binary output, too, in turn longer and more
complicated.
Longer: yes. It will generate a longer data segment with the names of all
supported webcams.
Could it be that some people who are writing code for RTS systems and
small single-purpose systems might scream about unnecessary bloat?
However, This won't increase the complextiy of the driver. As I showed, you
can know what device you have by just looking at id.driver_info. Also, as
this standard on other drivers, you aren't adding any uncommon weird
behavior.
Yet, this change would be a big patch, since several drivers already use
device_info for something else. The patch would be trivial though, since we
just need to move the current driver_info information to something inside the
webcam struct.
This looks to me like an excellent opportunity to get everyone tied in
knots at the same time. Gee. That sounds like fun. Perhaps we could get
the guy to do it :) ?
Therefore, the excursion ends up convincing me that in the first place the
documentation about which devices are supported, listed by trade name as
well as USB ID, really ought to be in some kind of place like gspca.txt. It
is after all much easier to edit a text file than it is to write code, and
the contents of the text file do not contribute to the growth of size of
the resulting binary. And it would be at least as easy, at least from this
point forward, to place the responsibility on the author/maintainer of a
gspca_* module to provide such a list as part of the procedure for
submitting code and patches. Then a perl script could, for example, parse
that one file and put the entries into alphabetical order, or any other
reasonable and desired order.
This will only work fine if there are some sanity check script to validate if
all USB ID's are present at gspca.txt. Otherwise, we'll always have the risk
of not having it properly updated
Re: [PATCH] to add support for certain Jeilin dual-mode cameras.
On Sun, 2 Aug 2009, Jean-Francois Moine wrote: On Sat, 1 Aug 2009 16:56:06 -0500 (CDT) Theodore Kilgore kilg...@banach.math.auburn.edu wrote: Several cameras are supported here, which all share the same USB Vendor:Product number when started up in streaming mode. All of these cameras use bulk transport for streaming, and all of them produce frames in JPEG format. Hi Theodore, Your patch seems ok, but: - there is no kfree(sd-jpeg_hdr). Should be in stop0(). OK. Will do, and resend, as asked. But before I do that, there is the second item. It seems to raise questions of policy. I think it is appropriate to raise that question for general discussion. - as there is only one vend:prod, one line is enough in gspca.txt. This is a question about which I have been curious for quite some time, and I think that now is a good time to ask it. Just what policy do we have about this? The information which links brand and model to driver ought to be presented somewhere. If it does not go into gspca.txt then where exactly is the appropriate place to put said information? As to these three particular cameras, perhaps one should take into account here the fact that what we actually have here is three different cameras, put on the market by three different vendors, and in at least two different parts of the world. The Sakar camera and the Cobra camera are for sale in the US. The FlyOne camera is for sale in Germany and perhaps in some other parts of Europe. Furthermore, in stillcam mode they are all three of them standard mass storage devices, but they have different IDs from what is listed here (good for them about that!) and the stillcam IDs are distinct, too. So in other words they are not the same camera, at all, in spite of the fact that they all use the same ID when set up in webcam mode. A more general consideration is that the buyer of a camera is not helped at all by knowing that a particular chipset combination is supported. No. The buyer can only go by the make and model which are printed on the outside of the plastic bubble pack. So what exactly are we, the developers, to do in order to make the relevant information available to the public? There is some wiki, of course. But it seems to me the wiki itself ought to refer to the gspca.txt file, among other things. I do think that one of the easy ways to address the above issue of helping the camera purchaser would be to agree that gspca.txt ought to contain the information for each individual camera which is supported. This would make the file longer, but it is in my opinion a small price to pay, when the goal is to have complete information, put in a central place. In going over the gspca.txt file, I also see that the jeilinj entries are the only place where there is a duplicate entry, so that I am at this time in non-conformity. But, on checking, I also see that the SQ905 cameras (2770:9120) and the SQ905C cameras (2770:905c) are not listed at all in gspca.txt. This could be claimed as an example of my ignorance that I am supposed to put something there. But it is also related to the fact that -- there are twenty-five (25) cameras listed in libgphoto2/camlibs/sq905/library.c, which were reported to me as working with that particular stillcam driver. This list does not include several other cameras that I only heard about vaguely, or that I do not even know about at all because nobody ever reported them to me. So if I am supposed to pick just one of these, then which one do I list in gspca.txt, when as far as I know they all ought to work with the gspca sq905 driver? and, as for the SQ905C cameras -- there are seventeen (17) cameras listed in libgphoto2/camlibs/digigr8/library.c, which were reported to me as working with that particular stillcam driver. This list does not include several other cameras that I only heard about vaguely, or that I do not even know about at all because nobody ever reported them to me. If I am supposed to pick just one of these, then which one do I list in gspca.txt, when as far as I know they all ought to work with the gspca sq905c driver? For the above reasons, I have up to this point not listed any of these cameras in gspca.txt at all, as supported. Probably that is not the right thing to do, either? Now, in addition to the above, there is another problem which will hit very soon, probably soon after the time that Thomas Kaiser gets back from his vacation and starts to work again. This is the matter of the mr97310a driver, which is almost finished now. What we have there is a list of cameras which are all functionally identical as still cameras, but as webcams the functionality differs in minor details. Here is what happens: 08ca:0111 Aiptek Pencam VGA+ (supported, listed in gspca.txt) 093a:010f several cameras, some functionally identical to the Aiptek camera, and some which as webcams require a different init procedure and use
Re: [PATCH] to add support for certain Jeilin dual-mode cameras. (resubmit)
On Sun, 2 Aug 2009, Jean-Francois Moine wrote: On Sat, 1 Aug 2009 16:56:06 -0500 (CDT) Theodore Kilgore kilg...@banach.math.auburn.edu wrote: Several cameras are supported here, which all share the same USB Vendor:Product number when started up in streaming mode. All of these cameras use bulk transport for streaming, and all of them produce frames in JPEG format. Hi Theodore, Your patch seems ok, but: - there is no kfree(sd-jpeg_hdr). Should be in stop0(). - as there is only one vend:prod, one line is enough in gspca.txt. May you fix this and resend? Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Jean-Francois, The version below should meet your objections. The memory for the header is freed, and I keep only one entry for the USB ID in gspca.txt. After some deliberation, I decided to keep the entry for the Sakar camera (belongs to Andy Walls), as that seems to be the one which was most recently purchased. At the same time, I hope very much that the points which I have raised in my previous response in regard to documentation can be seriously discussed. As I see it, there is a problem about documentation. Theodore Kilgore Patch follows. Signed-off-by: Theodore Kilgore kilg...@auburn.edu diff -r d189fb4be712 linux/Documentation/video4linux/gspca.txt --- a/linux/Documentation/video4linux/gspca.txt Wed Jul 29 10:01:54 2009 +0200 +++ b/linux/Documentation/video4linux/gspca.txt Sun Aug 02 14:12:25 2009 -0500 @@ -239,6 +239,7 @@ pac7311093a:2629 Genious iSlim 300 pac7311093a:262a Webcam 300k pac7311093a:262c Philips SPC 230 NC +jeilinj0979:0280 Sakar 57379 zc3xx 0ac8:0302 Z-star Vimicro zc0302 vc032x 0ac8:0321 Vimicro generic vc0321 vc032x 0ac8:0323 Vimicro Vc0323 diff -r d189fb4be712 linux/drivers/media/video/gspca/Kconfig --- a/linux/drivers/media/video/gspca/Kconfig Wed Jul 29 10:01:54 2009 +0200 +++ b/linux/drivers/media/video/gspca/Kconfig Sun Aug 02 14:12:25 2009 -0500 @@ -47,6 +47,15 @@ To compile this driver as a module, choose M here: the module will be called gspca_finepix. +config USB_GSPCA_JEILINJ + tristate Jeilin JPEG USB V4L2 driver + depends on VIDEO_V4L2 USB_GSPCA + help + Say Y here if you want support for cameras based on this Jeilin chip. + + To compile this driver as a module, choose M here: the + module will be called gspca_jeilinj. + config USB_GSPCA_MARS tristate Mars USB Camera Driver depends on VIDEO_V4L2 USB_GSPCA diff -r d189fb4be712 linux/drivers/media/video/gspca/Makefile --- a/linux/drivers/media/video/gspca/Makefile Wed Jul 29 10:01:54 2009 +0200 +++ b/linux/drivers/media/video/gspca/Makefile Sun Aug 02 14:12:25 2009 -0500 @@ -2,6 +2,7 @@ obj-$(CONFIG_USB_GSPCA_CONEX)+= gspca_conex.o obj-$(CONFIG_USB_GSPCA_ETOMS)+= gspca_etoms.o obj-$(CONFIG_USB_GSPCA_FINEPIX) += gspca_finepix.o +obj-$(CONFIG_USB_GSPCA_JEILINJ) += gspca_jeilinj.o obj-$(CONFIG_USB_GSPCA_MARS) += gspca_mars.o obj-$(CONFIG_USB_GSPCA_MR97310A) += gspca_mr97310a.o obj-$(CONFIG_USB_GSPCA_OV519)+= gspca_ov519.o @@ -30,6 +31,7 @@ gspca_conex-objs:= conex.o gspca_etoms-objs:= etoms.o gspca_finepix-objs := finepix.o +gspca_jeilinj-objs := jeilinj.o gspca_mars-objs := mars.o gspca_mr97310a-objs := mr97310a.o gspca_ov519-objs:= ov519.o diff -r d189fb4be712 linux/drivers/media/video/gspca/jeilinj.c --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/linux/drivers/media/video/gspca/jeilinj.c Sun Aug 02 14:12:25 2009 -0500 @@ -0,0 +1,388 @@ +/* + * Jeilinj subdriver + * + * Supports some Jeilin dual-mode cameras which use bulk transport and + * download raw JPEG data. + * + * Copyright (C) 2009 Theodore Kilgore + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#define MODULE_NAME jeilinj + +#include linux/workqueue.h +#include gspca.h +#include jpeg.h + +MODULE_AUTHOR(Theodore Kilgore kilg
Re: Sakar 57379 USB Digital Video Camera...
On Tue, 23 Jun 2009, Andy Walls wrote: On Mon, 2009-06-22 at 10:51 -0500, Theodore Kilgore wrote: On Mon, 22 Jun 2009, Andy Walls wrote: On Sun, 2009-06-21 at 22:39 -0500, Theodore Kilgore wrote: Andy, You are right. Your camera is emitting JPEG while streaming. I just succeeded in creating an image which resembles your test picture by extracting the frame data for one frame, tacking on a header, and running hex2bin on the combined file. I did not get the thing quite right, because your header is from your JPEG photo (640x480) and your stream is probably 320x240. But I got something out which is obviously recognizable. Excellent. Going from It may never work to something recognizable in one weekend is good progress. Well, sometimes the easy and obvious just works, and one is lucky. If only they were all that easy. I'd contend most would be easy and obvious, as anything created by people is usually easy to understand. People are generally lazy and want to avoid what they perceive as extra effort. If you couple that with management pressure on engineers to keep costs down and maintain project schedules, you often end up with very simple solutions. There is some truth to this, yes. The data encoding used by the camera is indicative of that. For this camera, the engineers decided to simply drop the (M)JPEG headers to save USB communications bandwidth instead of using a different, better compression algorithm; or a imlementing new USB 2.0 interface. Besides, as we well know, this list is a place where geniuses hang out. So perhaps some of the pixie dust has rubbed off on us. I thought genius was inspiration and perspiration. Pixie dust - I knew Edison wasn't telling the whole truth. ;) Therefore with a little bit of further tweaking it will presumably come out exactly so. Namely, I have to remember where to stick the two dimensions into the header. Found that, as I said yesterday evening. Yes, as far as I'm concerned the problem is solved. The details are left as an exercise for the reader. ;) I will try to get on it. There is nothing left but details, but there are lots of those. Yes, I agree. Getting those right is no small task. The first one is to get the header exactly right. Well, given that the Windows driver has the AVI video stream FourCC 'vids' appearing four or five times, I suspect there is more than 1 header template that the Windows driver can tack on to the incoming stream. I'm guessing that which one is used, depends on how the camera stream is initialized. Sort of, yes. At least that is the way it looks over here. The sequence of button-push steps for initializing my camera to do streaming is just about the same as that for inducing it to shoot an AVI, and then the question is whether you turned on capturing from the computer or not. If you did, then you get a stream. If you didn't then it seems the camera makes an AVI. There are probably all sorts of header permutations that will yield viewable but suboptimal reconstruction. :( Then again it's a cheap webcam, so by definition any image is probably suboptimal. Well, interestingly, your header and mine, when affixed to my one frame, are doing about equally well. But the two headers seem to differ from each other. snip I'm not up to speed on Linux webcam kernel to userspace API details. However, might I suggest going forward for testing at least, that when one starts the webcam streaming, the driver emit the stream in the form of an AVI. You'd need an AVI header declaring only an MJPEG 'vids' stream - no 'auds' nor 'idx' - and a 'movi' section with RIFF/AVI chunks that have MJPEG headers and the webcam payload. For all I know, it might be just a matter of following down a standard path. Perhaps this is all handled already in libv4lconvert, and it is merely a matter of plugging into that. I haven't checked yet, but that is more or less what I expect right now. Ah, OK. Revision: It seems that some other drivers are providing the jpeg header. There is a file gspca/jpeg.h from which to get it. So perhaps libv4lconvert is not much involved after all. As I said, I have not yet looked seriously into this. I spent yesterday evening trying to write a module, with which I tried to grab a raw frame (no header, no nothing) and it did not succeed. Clearly, my efforts need to be refined. I haven't seen evidence that audio comes from the webcam when it is streaming, but I haven't looked very much either. Same. Actually, my impression is that these cameras can not walk and chew gum at the same time. I would suspect that the audio is an either/or kind of thing. Either on, and it can record audio but not stream it, or off. I would be very surprised if an el cheapo like the one I have could do more. I could be wrong, of course. Perhaps both of us ought to check closely. I know it can simultaneously record audio and video to an AVI file in it's local storage. I'm
Re: Sakar 57379 USB Digital Video Camera...
On Mon, 22 Jun 2009, Andy Walls wrote: On Sun, 2009-06-21 at 22:39 -0500, Theodore Kilgore wrote: Andy, You are right. Your camera is emitting JPEG while streaming. I just succeeded in creating an image which resembles your test picture by extracting the frame data for one frame, tacking on a header, and running hex2bin on the combined file. I did not get the thing quite right, because your header is from your JPEG photo (640x480) and your stream is probably 320x240. But I got something out which is obviously recognizable. Excellent. Going from It may never work to something recognizable in one weekend is good progress. Well, sometimes the easy and obvious just works, and one is lucky. If only they were all that easy. Besides, as we well know, this list is a place where geniuses hang out. So perhaps some of the pixie dust has rubbed off on us. Therefore with a little bit of further tweaking it will presumably come out exactly so. Namely, I have to remember where to stick the two dimensions into the header. Yes, as far as I'm concerned the problem is solved. The details are left as an exercise for the reader. ;) I will try to get on it. There is nothing left but details, but there are lots of those. The first one is to get the header exactly right. Then there is the question, what is _my_ camera doing? I did not check that yet. And so on. So it is an algorithm now, but many steps remain to be completed. I'm not up to speed on Linux webcam kernel to userspace API details. However, might I suggest going forward for testing at least, that when one starts the webcam streaming, the driver emit the stream in the form of an AVI. You'd need an AVI header declaring only an MJPEG 'vids' stream - no 'auds' nor 'idx' - and a 'movi' section with RIFF/AVI chunks that have MJPEG headers and the webcam payload. For all I know, it might be just a matter of following down a standard path. Perhaps this is all handled already in libv4lconvert, and it is merely a matter of plugging into that. I haven't checked yet, but that is more or less what I expect right now. I haven't seen evidence that audio comes from the webcam when it is streaming, but I haven't looked very much either. Same. Actually, my impression is that these cameras can not walk and chew gum at the same time. I would suspect that the audio is an either/or kind of thing. Either on, and it can record audio but not stream it, or off. I would be very surprised if an el cheapo like the one I have could do more. I could be wrong, of course. Perhaps both of us ought to check closely. As my students in courses like calculus say, Sir, it has been a long time since I studied that. Whereupon I reply, With my white hair, I wonder how far I could get with that excuse? :) I will send you a copy of the results for your amusement. It is obviously the first attempt, so do not laugh at the fact that you get two copies of 3 x6 -- side by side, please. In retrospect, I should have used the 6x7 (or 6x9) flash card, so the answer would have been 42. :) Well, then there would be no mysteries left, would there? We couldn't have that. This is Monday, and I have to go off to the salt mine. I may be able to get back to this after coming home from the class. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: lsmod path hardcoded in v4l/Makefile
On Mon, 22 Jun 2009, Andy Walls wrote: On Mon, 2009-06-22 at 16:36 +0200, Matthias Schwarzott wrote: Hi list! It seems the path to lsmod tool is hardcoded in the Makefile for out-of-tree building of v4l-dvb. Now at least gentoo has moved lsmod from /sbin to /bin. Sorry, but is it considered impertinent to ask why that lsmod should be moved from /sbin (system binaries, and lsmod certainly is one of those) and stick it into /bin instead? Is there any cogent reason for doing a thing like that, which may have escaped my attention? Unless one is making some very small distro for some very small hardware and (say) one of /bin and /sbin is symlinked to the other, I find a change like that to be extremely puzzling. So, really. Why? Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sakar 57379 USB Digital Video Camera...
On Sun, 21 Jun 2009, Andy Walls wrote: On Sat, 2009-06-20 at 20:04 -0500, Theodore Kilgore wrote: Sure looks that way. I took a closer look at the lines starting with ff ff ff ff strings, and I found a couple more things. Here are several lines from an extract from that snoop, consisting of what appear to be consecutive SOF lines. : ff ff ff ff 00 00 1c 70 3c 00 0f 01 00 00 00 00 : ff ff ff ff 00 00 34 59 1e 00 1b 06 00 00 00 00 : ff ff ff ff 00 00 36 89 1e 00 1c 07 00 00 00 00 : ff ff ff ff 00 00 35 fc 1e 00 1b 08 00 00 00 00 : ff ff ff ff 00 00 35 84 1e 00 1b 09 00 00 00 00 The last non-zero byte is a frame counter. Presumably, the gap between the 01 and the 06 occurs because the camera was just then starting up and things were a bit chaotic. The rest of the lines in the file are completely consistent, counting consecutively from 09 to 49 (hex, of course) at which point I killed the stream. The byte previous to that one (reading downwards 0f 1b 1c 1b 1b ...) gives the number of 0x200-byte blocks in that frame, before the next marker comes along. So if we start from the frame labeled 06 then from there on the frames are approximately the same size, but not identical. For example the size of frame 06 is 0x1b*0x200. That is, 27*512 bytes. Here's the init for my camera: : 71 81 : 70 05 : 95 70 : 00 : 71 81 : 70 04 : 95 70 : 00 : 71 00 : 70 08 : 95 70 : 00 : 94 02 : de 24 : 94 02 : dd f0 : 94 02 : e3 22 --- different : 94 02 : e4 00 : 94 02 : e5 00 --- not repeated like in the sequence above : 94 02 : e6 22 --- different : 94 03 : aa 01 --- different : 71 1e : 70 06 : 71 80 : 70 07 And here's the terminal sequence: : 71 00 : 70 09 : 71 80 : 70 05 They look amazingly similar to yours. Here are the buffers with the supposed SOF marker: : ff ff ff ff 00 00 18 43 1e 00 0d fa 00 00 00 00 : ff ff ff ff 00 00 18 26 1e 00 0d 00 00 00 00 00 : ff ff ff ff 00 00 17 fa 1e 00 0c 01 00 00 00 00 : ff ff ff ff 00 00 18 4e 1e 00 0d 02 00 00 00 00 : ff ff ff ff 00 00 18 91 1e 00 0d 03 00 00 00 00 : ff ff ff ff 00 00 18 90 1e 00 0d 04 00 00 00 00 : ff ff ff ff 00 00 18 4b 1e 00 0d 05 00 00 00 00 : ff ff ff ff 00 00 18 8a 1e 00 0d 06 00 00 00 00 Again very similar. I had the camera pointed at a mostly white test target with some large blue numbers printed on it, so the sammler buffers probably just indicate how simple the test target was. The frames from my camera were coming at 100 ms intervals instead of 130 ms intervals. So maybe some scaling constant has changed with my supposed frame presentation frequency field that contains 0x1e00. This looks quite similar. The differences in the init sequence may be significant, but more likely I would speculate that they are insubstantial. Probably the little differences are due to who actually wrote the camera driver. Those guys over there also put their pants on one leg at a time just like the rest of us, after all. I think they do things like hiring students to write their drivers. If so, they might possibly get the same kind of results that could be expected over here from similar arrangements. Agree. The more I dig into this, the more I think (hope or wish?) the stuff in the usb snoop logs looks MJPEG. I started looking at an AVI file that I recorded with the camera. It looks like a DV AVI Type-2 file. In the AVI file header, my camera reports: 0d0: 7374 7264 ac00 4a65 696c strdJeil 0e0: 696e 2020 5465 6368 6e6f 6c6f 6779 2043 in Technology C 0f0: 6f2e 2c20 4c74 642e 4a4c 3230 3038 5632 o., Ltd.JL2008V2 100: 4330 3037 3030 3130 2020 2020 2020 2020 C0070010 So looking up the JL2008A datasheet, my camera's capabilities match the data sheet very well. http://jeilin.com.tw/eng/product_detail.php?p_id=5 http://jeilin.com.tw/mana_php/Download/File/JL2008A%20v1.3.pdf The only video compression that is mentioned on the webpage and in the datasheet is JPEG. Trying to learn about DV AVI Type 2 files I've found roughly how individual chunk headers look. They each have a stream fourcc that starts 'nnxx' in ASCII, where nn is the stream number and xx is db - uncompressed video frame dc - compressed video frame wb - audio data $ xxd 4.avi | grep -E ' 303[0-2] ((646)|(776))' 1f0: 14fe 0c00 6d6f 7669 3031 7762 401f movi0...@... -- audio 0002140: 3032 6462 0041 ffe2 55aa 0500 02db.AU. -- video 0006250: 3032 6462 0041 ffe2 55aa 0500 0001 02db.AU. -- video 000a360: 3032 6462 0041 ffe2 55aa 0500 0002 02db.AU. -- video 000e470: 3032 6462 0041 ffe2 55aa 0500 0003 02db.AU. -- video 0012580: 3032 6462 0041 ffe2 55aa 0500 0004 02db.AU. -- video 0016690: 3030 6463 281c ffd8 ffe0 0016 4156
Re: Sakar 57379 USB Digital Video Camera...
Andy, You are right. Your camera is emitting JPEG while streaming. I just succeeded in creating an image which resembles your test picture by extracting the frame data for one frame, tacking on a header, and running hex2bin on the combined file. I did not get the thing quite right, because your header is from your JPEG photo (640x480) and your stream is probably 320x240. But I got something out which is obviously recognizable. Therefore with a little bit of further tweaking it will presumably come out exactly so. Namely, I have to remember where to stick the two dimensions into the header. As my students in courses like calculus say, Sir, it has been a long time since I studied that. Whereupon I reply, With my white hair, I wonder how far I could get with that excuse? I will send you a copy of the results for your amusement. It is obviously the first attempt, so do not laugh at the fact that you get two copies of 3 x6 -- side by side, please. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sakar 57379 USB Digital Video Camera...
On Sat, 20 Jun 2009, Andy Walls wrote: On Fri, 2009-06-19 at 23:38 -0500, Theodore Kilgore wrote: Now it is using the other pair of endpoints, 0x03 and 0x84. H. I wonder if we can use them anyway, without being connected in webcam mode. Nope. That was the previously mentioned bug in the Linux mass storage driver. Namely the spec calls for using the first pair of endpoints encountered. The bug consisted of the mass storage driver looking for the last pair of endpoints encountered, instead. This was back around kernel 2.6.18 or so when the problem got fixed. The second pair of endpoints appears to be very much disconnected in mass storage mode. The attempt to use them will result only in a string of error messages. How well I remember. As to whether the first pair can be used in webcam mode, I clearly have not tried to use them, but I would have strong doubts whether it is even worth trying. Even if they would work, what on earth would they be good for? Just not having to disconnect the cam to get at the files on it. It'll probably be too much for the cheap device to deal with though. Well, I do not see any way around that. If you want to use it as a webcam, it needs a webcam support module. If you want to use it as a still cam, then it needs the mass storage module. Even if it were possible for the hardware to come up set in the webcam mode and use those two endpoints for something or other, then just how would it be possible to do the mass storage stuff? Actually, the producers of the camera were being very good citizens about that. They have the camera come up with two different Product numbers and two different Class-subclass-protocol IDs, depending on the way the camera has been set. One cannot ask for more. And the devices which do not act thus are a real pain in the neck. This brings up another topic, not immediately relevant to the question of supporting your/my camera, but extremely relevant for this list: Think about a camera which needs, say, libgphoto2 for stillcam support but needs a module in order to emit a stream. Then there is the issue of a userspace program to access the camera through libusb, and a kernel module to access it for streaming. Until something recently was done for a partial solution of this problem, then this implied the kernel module must be blacklisted, else the camera could never be used as a still camera. The current solution to this userspace-kernelspace conundrum is only a halfway solution. Nowadays, libusb disables the kernel module if called, and if you want to use the camera as a webcam after that, you must replug. This causes problems, too, because of some distros which have the too-bright idea of associating the camera, through libusb, to HAL and fixing it so that a program pops up immediately for the purpose of downloading the pictures on it. Those distros want to make things easy for their users. But then, what happens? Well, as soon as the camera is plugged in, its module gets loaded automatically, so that it can stream. Then immediately the module has been disabled, because the camera is automatically accessed from userspace. If the user wants to stream instead of downloading pictures from it, then the user is screwed. To replug the camera is no solution, because then the cycle merely gets repeated. Therefore, I submit that this problem is still not solved. The great difficulty is, of course, that the problem raises some very difficult issues, which strike at the heart of the Linux security model. A better solution needs to be sought. Returning to the issue on the table, I would say simply to be glad that the camera comes up as two different devices, depending on its switch settings, and does not use the same pair of endpoints for its two different functionalities, either. It is interesting to note that the transfer logic of the the device seems to be oriented around a 512 byte block size - the defacto disk block size. Yes, but in view of the mass-storage nature of the camera's alter ego, that seems to me natural. Also, all the other Jeilin cameras I know of, both supported and unsupported, count the allocation for the photos in blocks. Some of them use a smaller blocksize, but many of their purely proprietary cameras do also use this standard blocksize. In other words, this approach seems to me to be somewhat standard for Jeilin. snip Sure looks that way. I took a closer look at the lines starting with ff ff ff ff strings, and I found a couple more things. Here are several lines from an extract from that snoop, consisting of what appear to be consecutive SOF lines. : ff ff ff ff 00 00 1c 70 3c 00 0f 01 00 00 00 00 : ff ff ff ff 00 00 34 59 1e 00 1b 06 00 00 00 00 : ff ff ff ff 00 00 36 89 1e 00 1c 07 00 00 00 00 : ff ff ff ff 00 00 35 fc 1e 00 1b 08 00 00 00 00 : ff ff ff ff 00 00 35 84 1e 00 1b 09 00 00 00 00
Re: Sakar 57379 USB Digital Video Camera...
On Sat, 20 Jun 2009, Andy Walls wrote: On Sat, 2009-06-20 at 15:23 -0400, Andy Walls wrote: On Fri, 2009-06-19 at 23:38 -0500, Theodore Kilgore wrote: Now it is using the other pair of endpoints, 0x03 and 0x84. H. I wonder if we can use them anyway, without being connected in webcam mode. Nope. That was the previously mentioned bug in the Linux mass storage driver. Namely the spec calls for using the first pair of endpoints encountered. The bug consisted of the mass storage driver looking for the last pair of endpoints encountered, instead. This was back around kernel 2.6.18 or so when the problem got fixed. The second pair of endpoints appears to be very much disconnected in mass storage mode. The attempt to use them will result only in a string of error messages. How well I remember. As to whether the first pair can be used in webcam mode, I clearly have not tried to use them, but I would have strong doubts whether it is even worth trying. Even if they would work, what on earth would they be good for? Just not having to disconnect the cam to get at the files on it. It'll probably be too much for the cheap device to deal with though. It is interesting to note that the transfer logic of the the device seems to be oriented around a 512 byte block size - the defacto disk block size. There is a sequence of init commands : 71 81 : 70 05 : 95 70 : 00 (all the 00 are responses) : 71 81 : 70 04 : 95 70 : 00 : 71 00 : 70 08 : 95 70 : 00 : 94 02 : de 24 : 94 02 : dd f0 : 94 02 : e3 2c : 94 02 : e4 00 : 94 02 : e5 00 : e5 00 : 94 02 : e6 2c : 94 03 : aa 00 : 71 1e : 70 06 : 71 80 : 70 07 and then it starts to stream. The stream downloads 0x200 (512) bytes at a time. It appears that there is an SOF marker consisting of ff ff ff ff followed by at least two zeroes. These seem to occur only at the beginnings of some of the downloaded 0x200-sized blocks. Given that the AVI file is 320x240 @ 20 fps Motion JPEG, maybe the streaming mode uses something similar. Assuming 6 bit RGB values at 320x240 @ 20 fps: (320*240) * 24 bpp * 20 fps = 36.864 Mbps Since this USB 1.1, I'm guessing the stream has to be compressed. Sure looks that way. I took a closer look at the lines starting with ff ff ff ff strings, and I found a couple more things. Here are several lines from an extract from that snoop, consisting of what appear to be consecutive SOF lines. : ff ff ff ff 00 00 1c 70 3c 00 0f 01 00 00 00 00 : ff ff ff ff 00 00 34 59 1e 00 1b 06 00 00 00 00 : ff ff ff ff 00 00 36 89 1e 00 1c 07 00 00 00 00 : ff ff ff ff 00 00 35 fc 1e 00 1b 08 00 00 00 00 : ff ff ff ff 00 00 35 84 1e 00 1b 09 00 00 00 00 The last non-zero byte is a frame counter. Presumably, the gap between the 01 and the 06 occurs because the camera was just then starting up and things were a bit chaotic. The rest of the lines in the file are completely consistent, counting consecutively from 09 to 49 (hex, of course) at which point I killed the stream. The byte previous to that one (reading downwards 0f 1b 1c 1b 1b ...) gives the number of 0x200-byte blocks in that frame, before the next marker comes along. So if we start from the frame labeled 06 then from there on the frames are approximately the same size, but not identical. For example the size of frame 06 is 0x1b*0x200. That is, 27*512 bytes. I am not sure what the other numbers mean. Perhaps you have better guesses than I do. The first few become easy given your observations. They are the actaul payload size: ceil(0x1c70/0x200) = ceil(0x0e.380) = 0x0f ceil(0x3549/0x200) = ceil(0x1a.a48) = 0x1b ceil(0x3689/0x200) = ceil(0x1b.448) = 0x1c ceil(0x35fc/0x200) = ceil(0x1a.fe0) = 0x1b ceil(0x3584/0x200) = ceil(0x1a.c20) = 0x1b The lone 0x3c and the 0x1e's are not so easy: 0x3c = 60 0x1e = 30 Maybe an inidcation of frame rate? I'll try and think about them a little more. For your camera, these numbers appear to indicate a frequency and can be decoded into a time period like this: 1000/0x1e00 = 130 ms 1000/0x3c00 = 65 ms I'm assuming it's some sort of presentation frame rate. : 71 00 : 70 09 : 71 80 : 70 05 It would be interesting to see your log file and to compare. I could also send you this one if you are curious, but it is 5,760,902 bytes so I should ask that if you want to see it then how to send it? Me, I suspect that if you have one of similar size and bz2 it and send it to me as an attachment, then it is not any problem. You
Re: Sakar 57379 USB Digital Video Camera...
On Fri, 19 Jun 2009, Andy Walls wrote: On Thu, 2009-06-18 at 21:43 -0500, Theodore Kilgore wrote: On Thu, 18 Jun 2009, Andy Walls wrote: Interesting. To answer your question, I have no idea off the top of my head. I do have what seems to be a similar camera. It is Bus 005 Device 006: ID 0979:0371 Jeilin Technology Corp., Ltd and the rest of the lsusb output looks quite similar. I do not know, though, if it has any chance of working as a webcam. Somehow, the thought never occurred to me back when I got the thing. I would have to hunt some stuff down even to know if it is claimed to work as a webcam. The packaging that mine came in claims 3-in-1: digital video camcorder (with microphone) digital camera web cam You did say that it comes up as a different USB device when it is a webcam? You mean, a different product ID or so? Yes Look for this in the original lsusb output I provided : Webcam mode: Bus 003 Device 005: ID 0979:0280 Jeilin Technology Corp., Ltd Device Descriptor: Oops, right you are. Blame it on my old eyes. They are the same age as the rest of me, but sometimes they feel older. Another thing I could not see in front of me when I looked at my Jeilin Mass Storage camera, was what is written on it. It says there it is a Cobra DMC300, and it says Digital Video Camera I never paid any attention to that before, because for years my priorities were still cameras. But now, just in case I have lost the driver CD, I went out to Google and found what claims to be a driver for it. I hope that, with such a long idleness just sitting on a back corner of the desk, the battery has not died in the camera. If I get some time in the next few days to try to fight Windows, I will make some logs of my own. Then we can compare notes and see if the two cameras are similar, or not. What I am hoping for, obviously, is that both cameras are downloading JPEG frames, and use similar methods to do that. If that is true (we don't know that, of course) then the only problem I can imagine is that both of them are reported, even in webcam mode, as Mass Storage Bulk Transport devices. If so, then the camera(s) would need to be blacklisted by mass-storage when set up as webcams. Now that I got the supposed driver, I should go out on the web and get the supposed manual for my camera. Then perhaps I can know how it is supposed to be used as a webcam and get the needed sniffs. Meanwhile, I hope that you will do the same. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sakar 57379 USB Digital Video Camera...
On Fri, 19 Jun 2009, Andy Walls wrote: On Fri, 2009-06-19 at 12:47 -0500, Theodore Kilgore wrote: On Fri, 19 Jun 2009, Andy Walls wrote: On Thu, 2009-06-18 at 21:43 -0500, Theodore Kilgore wrote: On Thu, 18 Jun 2009, Andy Walls wrote: Interesting. To answer your question, I have no idea off the top of my head. I do have what seems to be a similar camera. It is Bus 005 Device 006: ID 0979:0371 Jeilin Technology Corp., Ltd and the rest of the lsusb output looks quite similar. I do not know, though, if it has any chance of working as a webcam. Somehow, the thought never occurred to me back when I got the thing. I would have to hunt some stuff down even to know if it is claimed to work as a webcam. The packaging that mine came in claims 3-in-1: digital video camcorder (with microphone) digital camera web cam You did say that it comes up as a different USB device when it is a webcam? You mean, a different product ID or so? Yes Look for this in the original lsusb output I provided : Webcam mode: Bus 003 Device 005: ID 0979:0280 Jeilin Technology Corp., Ltd Device Descriptor: Oops, right you are. Blame it on my old eyes. They are the same age as the rest of me, but sometimes they feel older. Another thing I could not see in front of me when I looked at my Jeilin Mass Storage camera, was what is written on it. It says there it is a Cobra DMC300, and it says Digital Video Camera I never paid any attention to that before, because for years my priorities were still cameras. But now, just in case I have lost the driver CD, I went out to Google and found what claims to be a driver for it. I hope that, with such a long idleness just sitting on a back corner of the desk, the battery has not died in the camera. If I get some time in the next few days to try to fight Windows, I will make some logs of my own. Then we can compare notes and see if the two cameras are similar, or not. What I am hoping for, obviously, is that both cameras are downloading JPEG frames, and use similar methods to do that. If that is true (we don't know that, of course) then the only problem I can imagine is that both of them are reported, even in webcam mode, as Mass Storage Bulk Transport devices. If so, then the camera(s) would need to be blacklisted by mass-storage when set up as webcams. Now that I got the supposed driver, I should go out on the web and get the supposed manual for my camera. Then perhaps I can know how it is supposed to be used as a webcam and get the needed sniffs. Meanwhile, I hope that you will do the same. OK. I have two steps to take: 1. Installing the driver and software on my sole remaining Windows machine. It already has snoopy. Great. 2. Getting the camera away from my daughter for more than 2 minutes. It's like the thing is glued to her hand. :) Oops. Not so good. Luck to you with that. But I hope that your daughter is suitably impressed with the idea of making things work in Linux, and suitably impressed with her father's skills about that kind of thing. I should mention. Mine has a microphone, too. Let us hope that the two are essentially identical except for things like packaging. And let us hope that the webcam functionality is not using some kind of weird compression algorithm. But yours, like mine, is using JPEG in still mode, right? So if it is using some weirdo scheme in webcam mode that will be both unpleasant and surprising. The only other things which might interfere are the following: 1. I am teaching in summer school. I just gave a test and I have to grade it over the weekend. The final exam is next Friday, so I will be similarly engaged. 2. We are going on vacation on July 7 and returning on July 23. My wife says that we will spend our spare time this weekend in planning. Because of this and because of item 1, I do not know whether or not I will be able to do the OEM install over here, or not, before next week. 3. Still working to finish expanding the mr97310a driver to support all known cameras with that chip in them. Believe it or not, some of those which have the chip and share a common Vendor:Product number work differently. So, ad-hoc methods needed to be figured out to classify them. This has been done, and all known cameras now work. There are four different initialization sequences to be taken into account. They all work. What is left to do now is to figure out how to apply the needed control sequences for things like brightness, gamma, white balance, and so forth and so on. So I am busy, but at the same time I am very much interested in taking this project on, too, because it involves something I have worked on in the past, myself. So let us see how it appears to come out. If I can get your log file, it will probably give a good start. Theodore Kilgore -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http
Re: Sakar 57379 USB Digital Video Camera...
On Fri, 19 Jun 2009, Andy Walls wrote: On Fri, 2009-06-19 at 12:47 -0500, Theodore Kilgore wrote: On Fri, 19 Jun 2009, Andy Walls wrote: On Thu, 2009-06-18 at 21:43 -0500, Theodore Kilgore wrote: On Thu, 18 Jun 2009, Andy Walls wrote: Interesting. To answer your question, I have no idea off the top of my head. I do have what seems to be a similar camera. It is Bus 005 Device 006: ID 0979:0371 Jeilin Technology Corp., Ltd and the rest of the lsusb output looks quite similar. I do not know, though, if it has any chance of working as a webcam. Somehow, the thought never occurred to me back when I got the thing. I would have to hunt some stuff down even to know if it is claimed to work as a webcam. The packaging that mine came in claims 3-in-1: digital video camcorder (with microphone) digital camera web cam You did say that it comes up as a different USB device when it is a webcam? You mean, a different product ID or so? Yes Look for this in the original lsusb output I provided : Webcam mode: Bus 003 Device 005: ID 0979:0280 Jeilin Technology Corp., Ltd Device Descriptor: Oops, right you are. Blame it on my old eyes. They are the same age as the rest of me, but sometimes they feel older. And the upshot is that we may have the same camera, at least as a webcam, perhaps with a different name. I finally made mine to work in webcam mode. On mine, one has to press down a button labelled DV at the same time as pressing down the button with the picture of a camera beside it, to turn on the webcam mode. As opposed to just pressing the camera button to turn on the camera to shoot a picture. OK. I have two steps to take: 1. Installing the driver and software on my sole remaining Windows machine. It already has snoopy. 2. Getting the camera away from my daughter for more than 2 minutes. It's like the thing is glued to her hand. :) I hope that you can still manage to do these things. I did get a snoop log of my own, but it would be nice to have some confirmation, too, that the cameras really are acting the same way. That may look like a stupid thing to say until one realizes that things which have the same USB Vendor:Product number do _not_ necessarily act the same way. Well, here are some of the things I learned: As a stillcam, it is confirmed that my cam is a standard mass storage device, transparent SCSI, bulk. It uses outep 0x01 and inep 0x82 (the first pair of endpoints). Here it is as a mass storage device. T: Bus=05 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0979 ProdID=0371 Rev= 1.00 S: Manufacturer=Jeilin S: Product=USB 1.1 Device S: SerialNumber=09790 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 4 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 8 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 8 Ivl=0ms and here it is as a webcam. T: Bus=05 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 16 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0979 ProdID=0280 Rev= 1.00 S: Manufacturer=Jeilin S: Product=USB 1.1 Device C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 4 Cls=00(ifc ) Sub=00 Prot=00 Driver=(none) E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 8 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 8 Ivl=0ms Now it is using the other pair of endpoints, 0x03 and 0x84. There is a sequence of init commands : 71 81 : 70 05 : 95 70 : 00(all the 00 are responses) : 71 81 : 70 04 : 95 70 : 00 : 71 00 : 70 08 : 95 70 : 00 : 94 02 : de 24 : 94 02 : dd f0 : 94 02 : e3 2c : 94 02 : e4 00 : 94 02 : e5 00 : e5 00 : 94 02 : e6 2c : 94 03 : aa 00 : 71 1e : 70 06 : 71 80 : 70 07 and then it starts to stream. The stream downloads 0x200 (512) bytes at a time. It appears that there is an SOF marker consisting of ff ff ff ff followed by at least two zeroes. These seem to occur only at the beginnings of some of the downloaded 0x200-sized blocks. There is a closing sequence at the end which is similar to the init sequence : 71 00 : 70 09 : 71 80 : 70 05 It would be interesting to see your log file and to compare. I could also send you this one if you are curious, but it is 5,760,902 bytes so I should ask that if you want to see it then how to send it? Me, I suspect that if you have one of similar size
Re: Sakar 57379 USB Digital Video Camera...
On Fri, 19 Jun 2009, Andy Walls wrote: On Fri, 2009-06-19 at 19:26 -0500, Theodore Kilgore wrote: On Fri, 19 Jun 2009, Andy Walls wrote: On Fri, 2009-06-19 at 12:47 -0500, Theodore Kilgore wrote: On Fri, 19 Jun 2009, Andy Walls wrote: On Thu, 2009-06-18 at 21:43 -0500, Theodore Kilgore wrote: On Thu, 18 Jun 2009, Andy Walls wrote: Interesting. To answer your question, I have no idea off the top of my head. I do have what seems to be a similar camera. It is Bus 005 Device 006: ID 0979:0371 Jeilin Technology Corp., Ltd and the rest of the lsusb output looks quite similar. I do not know, though, if it has any chance of working as a webcam. Somehow, the thought never occurred to me back when I got the thing. I would have to hunt some stuff down even to know if it is claimed to work as a webcam. The packaging that mine came in claims 3-in-1: digital video camcorder (with microphone) digital camera web cam You did say that it comes up as a different USB device when it is a webcam? You mean, a different product ID or so? Yes Look for this in the original lsusb output I provided : Webcam mode: Bus 003 Device 005: ID 0979:0280 Jeilin Technology Corp., Ltd Device Descriptor: Oops, right you are. Blame it on my old eyes. They are the same age as the rest of me, but sometimes they feel older. And the upshot is that we may have the same camera, at least as a webcam, perhaps with a different name. I finally made mine to work in webcam mode. On mine, one has to press down a button labelled DV at the same time as pressing down the button with the picture of a camera beside it, to turn on the webcam mode. As opposed to just pressing the camera button to turn on the camera to shoot a picture. Ah, very nice. The secret handshake that only the manual (usually lost) can tell you. There is no longer any manual out there on the web. I looked. OK. I have two steps to take: 1. Installing the driver and software on my sole remaining Windows machine. It already has snoopy. 2. Getting the camera away from my daughter for more than 2 minutes. It's like the thing is glued to her hand. :) I hope that you can still manage to do these things. I did get a snoop log of my own, but it would be nice to have some confirmation, too, that the cameras really are acting the same way. That may look like a stupid thing to say until one realizes that things which have the same USB Vendor:Product number do _not_ necessarily act the same way. Yes. I might need a little time. This weekend is Father's day, and I got to go see family tomorrow and will be hosting more family on Saturday evening and Sunday. I doubt I'll have time to look at this before Sunday night (and by then I suspect I'll be drinking beer. :)) I did let gThumb import some files from my daughter's camera (Ireally should have pulled them over myself from the mass storage drive). Easily done. No problem with that at all. Here's how they ended up: $ file * 1.jpg: JPEG image data, EXIF standard 2.2 2.jpg: JPEG image data, EXIF standard 2.2 3.jpg: JPEG image data, EXIF standard 2.2 4.avi: RIFF (little-endian) data, AVI, 320 x 240, 20.00 fps, video: Motion JPEG, audio: uncompressed PCM (mono, 8000 Hz) 5.jpg: JPEG image data, EXIF standard 2.2 6.jpg: JPEG image data, EXIF standard 2.2 7.jpg: JPEG image data, EXIF standard 2.2 8.jpg: JPEG image data, EXIF standard 2.2 9.jpg: JPEG image data, EXIF standard 2.2 00010.jpg: JPEG image data, EXIF standard 2.2 All the photos were JPEGs and the movie was playable. Totem/gstreamer did a much better job of playing back the audio in the movie than mplayer. Surprising to me, but 8 ksps mono is just awful anyway. Yes. The camera works perfectly in stilcam mode, as a mass storage device. Just mount it and treat it like a thumb drive. I tried the sound today, too, and the sound file is a .wav file. As far as my cam is concerned, I already knew all of this, but the camera has been gathering dust since 2005. Oh, it is convenient to take on a trip. So that has happened a couple of times. But otherwise it was not a very interesting camera. There is no challenge in a mass storage camera so I more or less forgot about it. Well, here are some of the things I learned: As a stillcam, it is confirmed that my cam is a standard mass storage device, transparent SCSI, bulk. It uses outep 0x01 and inep 0x82 (the first pair of endpoints). As I said, I was aware of this but did not remember the details, so this was all double-checking in order to clear up foggy memories. Here it is as a mass storage device. T: Bus=05 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0979 ProdID=0371 Rev= 1.00 S: Manufacturer=Jeilin S: Product=USB 1.1 Device S: SerialNumber=09790 ^ So much for a unique serial number. I haven't checked mine yet, but I bet it's
