* Advice wanted on producing an in kernel sq905 driver @ 2008-11-17 22:53 Adam Baker 2008-11-18 10:00 ` Hans de Goede 0 siblings, 1 reply; 8+ messages in thread From: Adam Baker @ 2008-11-17 22:53 UTC (permalink / raw) To: video4linux-list; +Cc: sqcam-devel Hi V4L readers, There currently exists an out of kernel driver for the SQ technologies sq905 USB webcam chipset used by a number of low cost webcams. This driver has a number of issues which would count against it being included in kernel as is but I'm considering trying to create something that could be suitable. I have a number of questions on how best to proceed. Note that this refers only to the sq905, USB ID 0x2770:0x9120 the sq905c is a substantially different chip. (If anyone wants to check out the current driver it is at http://sqcam.cvs.sourceforge.net/viewvc/sqcam/sqcam26/ ) First off some thoughts on how I'd like to proceed. The chip exposes the Bayer sensor output directly to the driver so the current driver uses code borrowed from libgphoto2 to do the Bayer decode in kernel. Obviously this is wrong and now we have libv4l it should use that instead. I don't have masses of time to work on this so I need an approach that isn't going to require writing loads of code. Considering the mess the current driver is in it is probably going to be better to make it a sub driver of gspca rather than try to re-use the existing code (which should also make life easier from a long term maintenance PoV). Now my questions 1) What kernel should I base any patches I produce on? The obvious choice would seem to be git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git but it seems as if Linus's 2.6 tree is more up to date for gspca. 2) The existing driver needed to perform a gamma adjustment after performing the Bayer decode. I couldn't find anything in libv4l that obviously did that so I'm guessing it isn't needed for existing devices - should that be added to libv4l if needed and if so how should the driver indicate it is needed - could it be indicated with a new value for v4l2_colorspace? 3) The current driver needs to do some up/down and left/right flips of the data to get it in the right order to do the Bayer decode that depend on the version info the camera returns to its init sequence. Should that code remain in the driver and if not how should the driver communicate what is needed. 4) The current driver doesn't support streaming mode for V4L2 (only V4L1) and libv4l doesn't support cameras that don't support streaming so is there an easy way to test out if the camera output will work well with libv4l before starting work? 5) Is there anything else I should know before starting. Adam Baker -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Advice wanted on producing an in kernel sq905 driver 2008-11-17 22:53 Advice wanted on producing an in kernel sq905 driver Adam Baker @ 2008-11-18 10:00 ` Hans de Goede 2008-11-18 10:00 ` Erik Andrén 0 siblings, 1 reply; 8+ messages in thread From: Hans de Goede @ 2008-11-18 10:00 UTC (permalink / raw) To: Adam Baker; +Cc: video4linux-list, sqcam-devel <note resend with different From address for the video4linux-list> Adam Baker wrote: > Hi V4L readers, > Hi Adam, Nice to meet you. > There currently exists an out of kernel driver for the SQ technologies sq905 > USB webcam chipset used by a number of low cost webcams. This driver has a > number of issues which would count against it being included in kernel as is > but I'm considering trying to create something that could be suitable. Great, thats very good news! > I have > a number of questions on how best to proceed. > Good, keep asking asking questions! > Note that this refers only to the sq905, USB ID 0x2770:0x9120 the sq905c is a > substantially different chip. > > (If anyone wants to check out the current driver it is at > http://sqcam.cvs.sourceforge.net/viewvc/sqcam/sqcam26/ ) > > First off some thoughts on how I'd like to proceed. > > The chip exposes the Bayer sensor output directly to the driver so the current > driver uses code borrowed from libgphoto2 to do the Bayer decode in kernel. > Obviously this is wrong and now we have libv4l it should use that instead. > Correct, there is nothing special you need to do for that, just pass frames with the raw bayer data to userspace and set the pixelformat to one of: V4L2_PIX_FMT_SBGGR8 /* v4l2_fourcc('B', 'A', '8', '1'), 8 bit BGBG.. GRGR.. */ V4L2_PIX_FMT_SGBRG8 /* v4l2_fourcc('G', 'B', 'R', 'G'), 8 bit GBGB.. RGRG.. */ V4L2_PIX_FMT_SGRBG8 /* v4l2_fourcc('G','R','B','G'), 8 bit GRGR.. BGBG.. */ V4L2_PIX_FMT_SRGGB8 /* v4l2_fourcc('R','G','G','B'), 8 bit RGRG.. GBGB.. */ Note the last 2 currently are only defined internally in libv4l and not in linux/videodev2.h as no drivers use them yet, but if you need one of them adding it to linux/videodev2.h is fine. And then make sure your applications are either patched to use libv4l, or use the LD_PRELOAD libc wrapper (see libv4l docs). > I don't have masses of time to work on this so I need an approach that isn't > going to require writing loads of code. Actually, the plan is to remove lots of code :) > Considering the mess the current > driver is in it is probably going to be better to make it a sub driver of > gspca rather than try to re-use the existing code (which should also make > life easier from a long term maintenance PoV). > Yes please make it a subdriver of gspca, then all you need to lift from the current driver are the chip specific initalization sequences, and the isoc frame parsing for detecting the beginning and ending of frames. > Now my questions > > 1) What kernel should I base any patches I produce on? The obvious choice > would seem to be > git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git but it > seems as if Linus's 2.6 tree is more up to date for gspca. Please use: http://linuxtv.org/hg/~jfrancois/gspca/ Note that like al v4l-dvb trees this is a standalone tree, not a complete kernel, assuming you've got the headers installed for your current kernel you can just do make menuconfig, make, make install from this tree (from the main dir, not from the linux subdir) to update your current kernels video4linux modules to the latest, then add your own driver and rince repeat :) > 2) The existing driver needed to perform a gamma adjustment after performing > the Bayer decode. I couldn't find anything in libv4l that obviously did that > so I'm guessing it isn't needed for existing devices - should that be added > to libv4l if needed and if so how should the driver indicate it is needed - > could it be indicated with a new value for v4l2_colorspace? Hmm interesting for now lets ignore this and first get it up and running without this, and the revisit this. I'm asking for this because gamma correction might be interesting for other cams too, so I would like to see a generic solution for this, which will take some design work, etc. > 3) The current driver needs to do some up/down and left/right flips of the > data to get it in the right order to do the Bayer decode that depend on the > version info the camera returns to its init sequence. Should that code remain > in the driver and if not how should the driver communicate what is needed. > It should communicate what is needed all possible bayer orders are covered by the 4 formats I gave above, and libv4l knows how to handle all 4 of them, for the defines of the last 2 see libv4lconvert/libv4lconvert-priv.h > 4) The current driver doesn't support streaming mode for V4L2 (only V4L1) and > libv4l doesn't support cameras that don't support streaming so is there an > easy way to test out if the camera output will work well with libv4l before > starting work? This should not be a problem. gspca now can work with both bulk and isochronyous usb transfers using cams, although your cam most likely is an isoc one (bulk mode cams are rare). > 5) Is there anything else I should know before starting. Not that I know, go for it! Regards, Hans p.s. In case it isn't clear I'm the author of libv4l and a contributer to gspca, as said before: go for it and keep asking questions! -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Advice wanted on producing an in kernel sq905 driver 2008-11-18 10:00 ` Hans de Goede @ 2008-11-18 10:00 ` Erik Andrén 2008-11-18 11:03 ` Hans de Goede 0 siblings, 1 reply; 8+ messages in thread From: Erik Andrén @ 2008-11-18 10:00 UTC (permalink / raw) To: Hans de Goede; +Cc: video4linux-list, sqcam-devel 2008/11/18 Hans de Goede <j.w.r.degoede@hhs.nl>: > <note resend with different From address for the video4linux-list> > > Adam Baker wrote: >> >> Hi V4L readers, >> > > Hi Adam, > > Nice to meet you. > >> There currently exists an out of kernel driver for the SQ technologies >> sq905 USB webcam chipset used by a number of low cost webcams. This driver >> has a number of issues which would count against it being included in kernel >> as is but I'm considering trying to create something that could be suitable. > > Great, thats very good news! > >> I have a number of questions on how best to proceed. >> > > Good, keep asking asking questions! > >> Note that this refers only to the sq905, USB ID 0x2770:0x9120 the sq905c >> is a substantially different chip. >> >> (If anyone wants to check out the current driver it is at >> http://sqcam.cvs.sourceforge.net/viewvc/sqcam/sqcam26/ ) >> >> First off some thoughts on how I'd like to proceed. >> >> The chip exposes the Bayer sensor output directly to the driver so the >> current driver uses code borrowed from libgphoto2 to do the Bayer decode in >> kernel. Obviously this is wrong and now we have libv4l it should use that >> instead. >> > > Correct, there is nothing special you need to do for that, just pass frames > with the raw bayer data to userspace and set the pixelformat to one of: > V4L2_PIX_FMT_SBGGR8 /* v4l2_fourcc('B', 'A', '8', '1'), 8 bit BGBG.. GRGR.. > */ > V4L2_PIX_FMT_SGBRG8 /* v4l2_fourcc('G', 'B', 'R', 'G'), 8 bit GBGB.. RGRG.. > */ > V4L2_PIX_FMT_SGRBG8 /* v4l2_fourcc('G','R','B','G'), 8 bit GRGR.. BGBG.. */ > V4L2_PIX_FMT_SRGGB8 /* v4l2_fourcc('R','G','G','B'), 8 bit RGRG.. GBGB.. */ > > Note the last 2 currently are only defined internally in libv4l and not in > linux/videodev2.h as no drivers use them yet, but if you need one of them > adding it to linux/videodev2.h is fine. I'm currently developing a driver where I need the two lower ones in order to get a correct bayer decoding. Would it possible to add them into the linux/videodev2.h? I can send a patch tonight if required. Thanks, Erik > > And then make sure your applications are either patched to use libv4l, or > use > the LD_PRELOAD libc wrapper (see libv4l docs). > >> I don't have masses of time to work on this so I need an approach that >> isn't going to require writing loads of code. > > Actually, the plan is to remove lots of code :) > >> Considering the mess the current >> driver is in it is probably going to be better to make it a sub driver of >> gspca rather than try to re-use the existing code (which should also make >> life easier from a long term maintenance PoV). >> > > Yes please make it a subdriver of gspca, then all you need to lift from the > current driver are the chip specific initalization sequences, and the isoc > frame parsing for detecting the beginning and ending of frames. > >> Now my questions >> >> 1) What kernel should I base any patches I produce on? The obvious choice >> would seem to be >> git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git but it >> seems as if Linus's 2.6 tree is more up to date for gspca. > > Please use: > http://linuxtv.org/hg/~jfrancois/gspca/ > > Note that like al v4l-dvb trees this is a standalone tree, not a complete > kernel, assuming you've got the headers installed for your current kernel > you > can just do make menuconfig, make, make install from this tree (from the > main > dir, not from the linux subdir) to update your current kernels video4linux > modules to the latest, then add your own driver and rince repeat :) > >> 2) The existing driver needed to perform a gamma adjustment after >> performing the Bayer decode. I couldn't find anything in libv4l that >> obviously did that so I'm guessing it isn't needed for existing devices - >> should that be added to libv4l if needed and if so how should the driver >> indicate it is needed - could it be indicated with a new value for >> v4l2_colorspace? > > Hmm interesting for now lets ignore this and first get it up and running > without this, and the revisit this. I'm asking for this because gamma > correction might be interesting for other cams too, so I would like to see a > generic solution for this, which will take some design work, etc. > >> 3) The current driver needs to do some up/down and left/right flips of the >> data to get it in the right order to do the Bayer decode that depend on the >> version info the camera returns to its init sequence. Should that code >> remain in the driver and if not how should the driver communicate what is >> needed. >> > > It should communicate what is needed all possible bayer orders are covered > by > the 4 formats I gave above, and libv4l knows how to handle all 4 of them, > for > the defines of the last 2 see libv4lconvert/libv4lconvert-priv.h > >> 4) The current driver doesn't support streaming mode for V4L2 (only V4L1) >> and libv4l doesn't support cameras that don't support streaming so is there >> an easy way to test out if the camera output will work well with libv4l >> before starting work? > > This should not be a problem. gspca now can work with both bulk and > isochronyous usb transfers using cams, although your cam most likely is an > isoc > one (bulk mode cams are rare). > >> 5) Is there anything else I should know before starting. > > Not that I know, go for it! > > Regards, > > Hans > > > p.s. > > In case it isn't clear I'm the author of libv4l and a contributer to gspca, > as > said before: go for it and keep asking questions! > > -- > video4linux-list mailing list > Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe > https://www.redhat.com/mailman/listinfo/video4linux-list > -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Advice wanted on producing an in kernel sq905 driver 2008-11-18 10:00 ` Erik Andrén @ 2008-11-18 11:03 ` Hans de Goede 2008-11-18 11:38 ` Erik Andrén 0 siblings, 1 reply; 8+ messages in thread From: Hans de Goede @ 2008-11-18 11:03 UTC (permalink / raw) To: Erik Andrén; +Cc: video4linux-list, sqcam-devel Erik Andrén wrote: <snip> >> Correct, there is nothing special you need to do for that, just pass frames >> with the raw bayer data to userspace and set the pixelformat to one of: >> V4L2_PIX_FMT_SBGGR8 /* v4l2_fourcc('B', 'A', '8', '1'), 8 bit BGBG.. GRGR.. >> */ >> V4L2_PIX_FMT_SGBRG8 /* v4l2_fourcc('G', 'B', 'R', 'G'), 8 bit GBGB.. RGRG.. >> */ >> V4L2_PIX_FMT_SGRBG8 /* v4l2_fourcc('G','R','B','G'), 8 bit GRGR.. BGBG.. */ >> V4L2_PIX_FMT_SRGGB8 /* v4l2_fourcc('R','G','G','B'), 8 bit RGRG.. GBGB.. */ >> >> Note the last 2 currently are only defined internally in libv4l and not in >> linux/videodev2.h as no drivers use them yet, but if you need one of them >> adding it to linux/videodev2.h is fine. > > I'm currently developing a driver where I need the two lower ones in > order to get a correct bayer decoding. > Would it possible to add them into the linux/videodev2.h? > > I can send a patch tonight if required. > It is usual for such patches to be submitted together with the driver using the new defines. Just be sure you define V4L2_PIX_FMT_SGRBG8 as v4l2_fourcc('G','R','B','G') and V4L2_PIX_FMT_SRGGB8 as v4l2_fourcc('R','G','G','B') You can try sending a patch to Mauro as preperation for your driver, but I'm not sure he will take such a patch, he did not accept it from me in the past as no drivers were using them, maybe with a driver on the horizon he will accept such a patch. Regards, Hans -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Advice wanted on producing an in kernel sq905 driver 2008-11-18 11:03 ` Hans de Goede @ 2008-11-18 11:38 ` Erik Andrén 2008-11-18 12:52 ` Hans de Goede 0 siblings, 1 reply; 8+ messages in thread From: Erik Andrén @ 2008-11-18 11:38 UTC (permalink / raw) To: Hans de Goede; +Cc: video4linux-list, sqcam-devel 2008/11/18 Hans de Goede <j.w.r.degoede@hhs.nl>: > Erik Andrén wrote: > > <snip> > >>> Correct, there is nothing special you need to do for that, just pass >>> frames >>> with the raw bayer data to userspace and set the pixelformat to one of: >>> V4L2_PIX_FMT_SBGGR8 /* v4l2_fourcc('B', 'A', '8', '1'), 8 bit BGBG.. >>> GRGR.. >>> */ >>> V4L2_PIX_FMT_SGBRG8 /* v4l2_fourcc('G', 'B', 'R', 'G'), 8 bit GBGB.. >>> RGRG.. >>> */ >>> V4L2_PIX_FMT_SGRBG8 /* v4l2_fourcc('G','R','B','G'), 8 bit GRGR.. BGBG.. >>> */ >>> V4L2_PIX_FMT_SRGGB8 /* v4l2_fourcc('R','G','G','B'), 8 bit RGRG.. GBGB.. >>> */ >>> >>> Note the last 2 currently are only defined internally in libv4l and not >>> in >>> linux/videodev2.h as no drivers use them yet, but if you need one of them >>> adding it to linux/videodev2.h is fine. >> >> I'm currently developing a driver where I need the two lower ones in >> order to get a correct bayer decoding. >> Would it possible to add them into the linux/videodev2.h? >> >> I can send a patch tonight if required. >> > > It is usual for such patches to be submitted together with the driver using > the new defines. Just be sure you define > V4L2_PIX_FMT_SGRBG8 as v4l2_fourcc('G','R','B','G') > and > V4L2_PIX_FMT_SRGGB8 as v4l2_fourcc('R','G','G','B') > > You can try sending a patch to Mauro as preperation for your driver, but I'm > not sure he will take such a patch, he did not accept it from me in the past > as no drivers were using them, maybe with a driver on the horizon he will > accept such a patch. > I'm currently in the process of porting the old quickcam driver [1] to the gspca framework sofar I have working video using the vv6410 sensor. Next step is to get the hdcs and pb0100 sensors up to speed. The driver will be tracked in http://linuxtv.org/hg/~eandren/gspca-stv06xx/ (nothing pushed yet) [1] http://qce-ga.sourceforge.net/ I'll let Jean-Francoise and Mauro know when it's ready for mainline submission. Regards, Erik > Regards, > > Hans > -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Advice wanted on producing an in kernel sq905 driver 2008-11-18 11:38 ` Erik Andrén @ 2008-11-18 12:52 ` Hans de Goede 2008-11-18 13:08 ` Erik Andrén 2008-11-18 14:12 ` Antonio Ospite 0 siblings, 2 replies; 8+ messages in thread From: Hans de Goede @ 2008-11-18 12:52 UTC (permalink / raw) To: Erik Andrén; +Cc: video4linux-list, sqcam-devel Erik Andrén wrote: > 2008/11/18 Hans de Goede <j.w.r.degoede@hhs.nl>: >> Erik Andrén wrote: >> >> <snip> >> >>>> Correct, there is nothing special you need to do for that, just pass >>>> frames >>>> with the raw bayer data to userspace and set the pixelformat to one of: >>>> V4L2_PIX_FMT_SBGGR8 /* v4l2_fourcc('B', 'A', '8', '1'), 8 bit BGBG.. >>>> GRGR.. >>>> */ >>>> V4L2_PIX_FMT_SGBRG8 /* v4l2_fourcc('G', 'B', 'R', 'G'), 8 bit GBGB.. >>>> RGRG.. >>>> */ >>>> V4L2_PIX_FMT_SGRBG8 /* v4l2_fourcc('G','R','B','G'), 8 bit GRGR.. BGBG.. >>>> */ >>>> V4L2_PIX_FMT_SRGGB8 /* v4l2_fourcc('R','G','G','B'), 8 bit RGRG.. GBGB.. >>>> */ >>>> >>>> Note the last 2 currently are only defined internally in libv4l and not >>>> in >>>> linux/videodev2.h as no drivers use them yet, but if you need one of them >>>> adding it to linux/videodev2.h is fine. >>> I'm currently developing a driver where I need the two lower ones in >>> order to get a correct bayer decoding. >>> Would it possible to add them into the linux/videodev2.h? >>> >>> I can send a patch tonight if required. >>> >> It is usual for such patches to be submitted together with the driver using >> the new defines. Just be sure you define >> V4L2_PIX_FMT_SGRBG8 as v4l2_fourcc('G','R','B','G') >> and >> V4L2_PIX_FMT_SRGGB8 as v4l2_fourcc('R','G','G','B') >> >> You can try sending a patch to Mauro as preperation for your driver, but I'm >> not sure he will take such a patch, he did not accept it from me in the past >> as no drivers were using them, maybe with a driver on the horizon he will >> accept such a patch. >> > > I'm currently in the process of porting the old quickcam driver [1] to > the gspca framework sofar I have working video using the vv6410 > sensor. Next step is to get the hdcs and pb0100 sensors up to speed. > The driver will be tracked in > http://linuxtv.org/hg/~eandren/gspca-stv06xx/ (nothing pushed yet) > Good! and <ugh> I've been working on the same, I'm nowhere near as far as you though, can you please put a tarbal or whatever somewhere, then I can see if there is anything in my version worth salvaging to improve your driver in some points. I've access to an pb0100 using cam. Regards, Hans -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Advice wanted on producing an in kernel sq905 driver 2008-11-18 12:52 ` Hans de Goede @ 2008-11-18 13:08 ` Erik Andrén 2008-11-18 14:12 ` Antonio Ospite 1 sibling, 0 replies; 8+ messages in thread From: Erik Andrén @ 2008-11-18 13:08 UTC (permalink / raw) To: Hans de Goede; +Cc: video4linux-list, sqcam-devel 2008/11/18 Hans de Goede <j.w.r.degoede@hhs.nl>: > Erik Andrén wrote: >> >> 2008/11/18 Hans de Goede <j.w.r.degoede@hhs.nl>: >>> >>> Erik Andrén wrote: >>> >>> <snip> >>> >>>>> Correct, there is nothing special you need to do for that, just pass >>>>> frames >>>>> with the raw bayer data to userspace and set the pixelformat to one of: >>>>> V4L2_PIX_FMT_SBGGR8 /* v4l2_fourcc('B', 'A', '8', '1'), 8 bit BGBG.. >>>>> GRGR.. >>>>> */ >>>>> V4L2_PIX_FMT_SGBRG8 /* v4l2_fourcc('G', 'B', 'R', 'G'), 8 bit GBGB.. >>>>> RGRG.. >>>>> */ >>>>> V4L2_PIX_FMT_SGRBG8 /* v4l2_fourcc('G','R','B','G'), 8 bit GRGR.. >>>>> BGBG.. >>>>> */ >>>>> V4L2_PIX_FMT_SRGGB8 /* v4l2_fourcc('R','G','G','B'), 8 bit RGRG.. >>>>> GBGB.. >>>>> */ >>>>> >>>>> Note the last 2 currently are only defined internally in libv4l and not >>>>> in >>>>> linux/videodev2.h as no drivers use them yet, but if you need one of >>>>> them >>>>> adding it to linux/videodev2.h is fine. >>>> >>>> I'm currently developing a driver where I need the two lower ones in >>>> order to get a correct bayer decoding. >>>> Would it possible to add them into the linux/videodev2.h? >>>> >>>> I can send a patch tonight if required. >>>> >>> It is usual for such patches to be submitted together with the driver >>> using >>> the new defines. Just be sure you define >>> V4L2_PIX_FMT_SGRBG8 as v4l2_fourcc('G','R','B','G') >>> and >>> V4L2_PIX_FMT_SRGGB8 as v4l2_fourcc('R','G','G','B') >>> >>> You can try sending a patch to Mauro as preperation for your driver, but >>> I'm >>> not sure he will take such a patch, he did not accept it from me in the >>> past >>> as no drivers were using them, maybe with a driver on the horizon he will >>> accept such a patch. >>> >> >> I'm currently in the process of porting the old quickcam driver [1] to >> the gspca framework sofar I have working video using the vv6410 >> sensor. Next step is to get the hdcs and pb0100 sensors up to speed. >> The driver will be tracked in >> http://linuxtv.org/hg/~eandren/gspca-stv06xx/ (nothing pushed yet) >> > > Good! and <ugh> I've been working on the same, I should have announced my work earlier. I'm nowhere near as far as > you though, can you please put a tarbal or whatever somewhere, then I can > see if there is anything in my version worth salvaging to improve your > driver in some points. I'll push what I've got tonight. > > I've access to an pb0100 using cam. > Great, I've sofar been unable to locate anyone with this sensor. The original projected is dead and it's mailinglists are infested with spam. Regards, Erik > Regards, > > Hans > -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Advice wanted on producing an in kernel sq905 driver 2008-11-18 12:52 ` Hans de Goede 2008-11-18 13:08 ` Erik Andrén @ 2008-11-18 14:12 ` Antonio Ospite 1 sibling, 0 replies; 8+ messages in thread From: Antonio Ospite @ 2008-11-18 14:12 UTC (permalink / raw) To: Hans de Goede; +Cc: video4linux-list, sqcam-devel [-- Attachment #1.1: Type: text/plain, Size: 1228 bytes --] On Tue, 18 Nov 2008 13:52:13 +0100 Hans de Goede <j.w.r.degoede@hhs.nl> wrote: > Erik Andrén wrote: > > > > > I'm currently in the process of porting the old quickcam driver [1] to > > the gspca framework sofar I have working video using the vv6410 > > sensor. Next step is to get the hdcs and pb0100 sensors up to speed. > > The driver will be tracked in > > http://linuxtv.org/hg/~eandren/gspca-stv06xx/ (nothing pushed yet) > > > > Good! and <ugh> I've been working on the same, I'm nowhere near as far as you > though, can you please put a tarbal or whatever somewhere, then I can see if > there is anything in my version worth salvaging to improve your driver in some > points. > :) I also planned to work on this after the ov534 driver, I can do some testing if needed. > I've access to an pb0100 using cam. > Me too, eager to have it working in mainline. Regards, Antonio Ospite -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Web site: http://www.studenti.unina.it/~ospite Public key: http://www.studenti.unina.it/~ospite/aopubkey.asc [-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --] [-- Attachment #2: Type: text/plain, Size: 164 bytes --] -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2008-11-18 14:12 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-11-17 22:53 Advice wanted on producing an in kernel sq905 driver Adam Baker 2008-11-18 10:00 ` Hans de Goede 2008-11-18 10:00 ` Erik Andrén 2008-11-18 11:03 ` Hans de Goede 2008-11-18 11:38 ` Erik Andrén 2008-11-18 12:52 ` Hans de Goede 2008-11-18 13:08 ` Erik Andrén 2008-11-18 14:12 ` Antonio Ospite
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.