Hi all,
I would like to propose to your attention a driver for the
dt3155 frame grabber I am using in my experiments since
the time of 2.6.17 kernel.
It is realized as a character device (not as a v4l device)
and is currently able to capture video frames in real time
to HDD and display them simultaneously in the application window.
I will really appreciate your comments, suggestions, criticism.
As far as there is another driver already merged in linux-next
for the same hardware is it worth to consider this one for
merging too?
The driver code could be found here:
http://lfb.issp.bas.bg/~mitov/linux/dt3155pci/
Best regards,
Marin Mitov
Hi Marin,
> dt3155 frame grabber I am using in my experiments since
> the time of 2.6.17 kernel.
Whoah!
> I will really appreciate your comments, suggestions, criticism.
I haven't tried your driver but the code looks much neater than
our driver. Still, I am wondering why you chose to implement a
device driver from scratch, rather than use an existing one?
http://sourceforge.net/projects/dt3155a/
I'll leave decisions about whether to merge or discard (either
driver) to Greg. My 2 cents is that there should only be 1 DT3155
driver for users to choose from.
Scott. :)
On Wed, Jan 13, 2010 at 10:52:21AM +1100, Scott Smedley wrote:
> Hi Marin,
>
> > dt3155 frame grabber I am using in my experiments since
> > the time of 2.6.17 kernel.
>
> Whoah!
>
> > I will really appreciate your comments, suggestions, criticism.
>
> I haven't tried your driver but the code looks much neater than
> our driver. Still, I am wondering why you chose to implement a
> device driver from scratch, rather than use an existing one?
>
> http://sourceforge.net/projects/dt3155a/
>
> I'll leave decisions about whether to merge or discard (either
> driver) to Greg. My 2 cents is that there should only be 1 DT3155
> driver for users to choose from.
I agree, we only need one of them.
Scott, any comparison between the two of them as to which one actually
works better?
thanks,
greg k-h
On Wednesday 13 January 2010 02:17:24 am Greg KH wrote:
> On Wed, Jan 13, 2010 at 10:52:21AM +1100, Scott Smedley wrote:
> > Hi Marin,
> >
> > > dt3155 frame grabber I am using in my experiments since
> > > the time of 2.6.17 kernel.
> >
> > Whoah!
> >
> > > I will really appreciate your comments, suggestions, criticism.
> >
> > I haven't tried your driver but the code looks much neater than
> > our driver. Still, I am wondering why you chose to implement a
> > device driver from scratch, rather than use an existing one?
> >
> > http://sourceforge.net/projects/dt3155a/
In fact I used this one before switching to 2.6.17 kernel (see
http://lfb.issp.bas.bg/~mitov/linux/dt3155pci/00README
for details) and it was working well for single image acquisition.
(except for the problems with having too much HIGHMEM).
For real time acquisition (25 frames per sec), display and write
on HDD I needed heavy buffering, otherwise frames are skipped.
Another minor reason was I had already written an OS2 driver
for the same hardware and liked to try the same on linux :-).
Scott,
if you have 2 or more boards, could you check if
my driver is working with more than one board? I have only one
and cannot do this check. I could send you a multi-threaded
program for the test if you need it.
Marin Mitov
> >
> > I'll leave decisions about whether to merge or discard (either
> > driver) to Greg. My 2 cents is that there should only be 1 DT3155
> > driver for users to choose from.
>
> I agree, we only need one of them.
>
> Scott, any comparison between the two of them as to which one actually
> works better?
>
> thanks,
>
> greg k-h
>
Hi Greg & Marin,
> > Scott, any comparison between the two of them as to which one actually
> > works better?
I'd be interested in Marin's opinion as he appears to have used both
drivers extensively.
I'd like a userspace program to actually try out Marin's driver, but
I can still make some general comments:
Things I like about Marin's driver:
- It is only ~1/3rd the size. (by counting new lines)
- The code is much neater.
- It can acquire frames at 25 fps (real-time), according to Marin.
- At least 1 person with intimate knowledge of the code seems keen to
maintain it.
Things I like about the sourceforge (SF) driver:
- It works in CCIR mode (768x576) or 640x480 mode.
- It is well tested.
- It works with most kernel versions. ie. 2.2, 2.4, & 2.6. (mostly)
- It works with multiple boards.
- The code is moderately well commented.
- It includes simple (user space) example programs.
Clearly each driver has strengths over the other.
It would probably be easier to upgrade Marin's driver to match the
strengths of the SF driver than the other way around. The only
difficulty might be in making Marin's driver work with older kernel
versions. IMO, that's probably an acceptable sacrifice to make. (For
users of legacy systems, we could point them to the (unmaintained)
driver on SF.)
> if you have 2 or more boards, could you check if
> my driver is working with more than one board?
Sorry, I only have 1 board available to test with.
Marin, if you are considering upgrading your driver, I propose
we send an email to the DT3155 SF mailing list & ask for help
testing. (I already know of 1 other person who is happy to help
test.) I recommend making userspace programs (like examples/acquire
& examples/Xview in the SF driver) available first. Ideally, these
example programs & user space libraries would become the major
component of the evolved DT3155 SF project.
What do you think?
Scott. :)
On Thu, Jan 14, 2010 at 12:03:36PM +1100, Scott Smedley wrote:
> Hi Greg & Marin,
>
> > > Scott, any comparison between the two of them as to which one actually
> > > works better?
>
> I'd be interested in Marin's opinion as he appears to have used both
> drivers extensively.
>
> I'd like a userspace program to actually try out Marin's driver, but
> I can still make some general comments:
>
> Things I like about Marin's driver:
> - It is only ~1/3rd the size. (by counting new lines)
> - The code is much neater.
> - It can acquire frames at 25 fps (real-time), according to Marin.
> - At least 1 person with intimate knowledge of the code seems keen to
> maintain it.
>
> Things I like about the sourceforge (SF) driver:
> - It works in CCIR mode (768x576) or 640x480 mode.
> - It is well tested.
> - It works with most kernel versions. ie. 2.2, 2.4, & 2.6. (mostly)
> - It works with multiple boards.
> - The code is moderately well commented.
> - It includes simple (user space) example programs.
>
>
> Clearly each driver has strengths over the other.
>
> It would probably be easier to upgrade Marin's driver to match the
> strengths of the SF driver than the other way around. The only
> difficulty might be in making Marin's driver work with older kernel
> versions. IMO, that's probably an acceptable sacrifice to make. (For
> users of legacy systems, we could point them to the (unmaintained)
> driver on SF.)
We don't need to worry about older kernel versions from here on out.
That will make the one in the staging tree smaller as well, as the
compatibility code will soon be deleted.
So that leaves the functionality issues. Is the only difference that
one can capture faster than the other? They should be using the v4l
apis so userspace shouldn't be a difference either, right?
thanks,
greg k-h
Hi Greg,
> We don't need to worry about older kernel versions from here on out.
Ok.
> So that leaves the functionality issues. Is the only difference that
> one can capture faster than the other?
As mentioned, Marin's driver only supports CCIR mode & it
hasn't been tested with multiple boards.
> They should be using the v4l
> apis so userspace shouldn't be a difference either, right?
No. They are both standalone drivers. If we want V4L2 compatibility
we would have to modify (either) driver significantly.
Scott. :)
On Thu, Jan 14, 2010 at 02:13:45PM +1100, Scott Smedley wrote:
> Hi Greg,
>
> > We don't need to worry about older kernel versions from here on out.
>
> Ok.
>
> > So that leaves the functionality issues. Is the only difference that
> > one can capture faster than the other?
>
> As mentioned, Marin's driver only supports CCIR mode & it
> hasn't been tested with multiple boards.
Ah, ok.
> > They should be using the v4l
> > apis so userspace shouldn't be a difference either, right?
>
> No. They are both standalone drivers. If we want V4L2 compatibility
> we would have to modify (either) driver significantly.
Well, that will be the requirement to get it merged into the main
portion of the kernel tree. No special interfaces are allowed, sorry.
Anyway, I suggest the two of you decide on a plan forward.
thanks,
greg k-h
Hi Greg,
> >
> > No. They are both standalone drivers. If we want V4L2 compatibility
> > we would have to modify (either) driver significantly.
Both are character drivers. My one uses open, read, mmap, ioctl, close.
Mainly tested on read. mmap works, but not yet extensively tested.
ioctl is used to start/stop acquisition, get info about buffer length,
and some error statistics collected during acquisitions.
see:
http://lfb.issp.bas.bg/~mitov/linux/dt3155pci/00README
for more detailed description.
>
> Well, that will be the requirement to get it merged into the main
> portion of the kernel tree. No special interfaces are allowed, sorry.
I do not quite understand V4L2 lib in particular how can I get a
contiguous buffer in physical memory which do not cross 4MB
boundary (hardware requirement).
Thanks,
Marin Mitov
Hi Scot & Greg,
>
> I'd be interested in Marin's opinion as he appears to have used both
> drivers extensively.
I have successfully used SourceForge(SF) driver since 2003 on 2.4.xx
kernels till the time of 2.6.17 kernel when I switched to 2.6.17 as described in
http://lfb.issp.bas.bg/~mitov/linux/dt3155pci/00README
At this time I needed 1 fps, so the SF driver was OK for me.
>
> I'd like a userspace program to actually try out Marin's driver
I have one using KDE 3.5 libraries. If you use KDE 3.5 I could send it to you.
> , but
> I can still make some general comments:
>
> Things I like about Marin's driver:
> - It is only ~1/3rd the size. (by counting new lines)
> - The code is much neater.
> - It can acquire frames at 25 fps (real-time), according to Marin.
Since today it could do 30 fps as well :-). Updated.
> - At least 1 person with intimate knowledge of the code seems keen to
> maintain it.
>
> Things I like about the sourceforge (SF) driver:
> - It works in CCIR mode (768x576) or 640x480 mode.
Since today - here also.
> - It is well tested.
> - It works with most kernel versions. ie. 2.2, 2.4, & 2.6. (mostly)
Production tested/used (every day use) on 2.6.27.43-i686.
Compile tested on 2.6.33.-rc4-x86_64 :-)
> - It works with multiple boards.
Here in principal - also, but not tested.
> - The code is moderately well commented.
> - It includes simple (user space) example programs.
>
>
> Clearly each driver has strengths over the other.
>
> It would probably be easier to upgrade Marin's driver to match the
> strengths of the SF driver than the other way around. The only
> difficulty might be in making Marin's driver work with older kernel
> versions. IMO, that's probably an acceptable sacrifice to make. (For
> users of legacy systems, we could point them to the (unmaintained)
> driver on SF.)
>
> Marin, if you are considering upgrading your driver, I propose
> we send an email to the DT3155 SF mailing list & ask for help
> testing.
OK. I agree. Which kind of upgrade you mean?
If CCIR/RS-170 - it is already done (but not tested on RS-170,
I have no such camera).
I would ask your help for contacting "the DT3155 SF mailing list & ask for help"
> (I already know of 1 other person who is happy to help
> test.) I recommend making userspace programs (like examples/acquire
> & examples/Xview in the SF driver) available first. Ideally, these
> example programs & user space libraries would become the major
> component of the evolved DT3155 SF project.
Here I could propose a KDE program, but it needs KDE, I am not familiar
with GNOME programing.
Marin Mitov
On Thu, Jan 14, 2010 at 09:39:26PM +0200, Marin Mitov wrote:
> Hi Greg,
> > >
> > > No. They are both standalone drivers. If we want V4L2 compatibility
> > > we would have to modify (either) driver significantly.
>
> Both are character drivers. My one uses open, read, mmap, ioctl, close.
> Mainly tested on read. mmap works, but not yet extensively tested.
> ioctl is used to start/stop acquisition, get info about buffer length,
> and some error statistics collected during acquisitions.
>
> see:
>
> http://lfb.issp.bas.bg/~mitov/linux/dt3155pci/00README
>
> for more detailed description.
Thanks, but the code needs to use the v4l interface, as it is a video
device.
> > Well, that will be the requirement to get it merged into the main
> > portion of the kernel tree. No special interfaces are allowed, sorry.
>
> I do not quite understand V4L2 lib in particular how can I get a
> contiguous buffer in physical memory which do not cross 4MB
> boundary (hardware requirement).
Try asking on the linux-media mailing list, I don't think this is a big
deal, as you have already done it in the driver, so that would not have
to be reworked.
thanks,
greg k-h