Name: Cory Fox
Email: last_name AT cs DOT fsu DOT edu
Office 105E LOV
Name: Dragan Lojpur
Email: last_name AT cs DOT fsu DOT edu
Office 105A LOV
|Preliminary:||Our first task was to choose a project. After hearing suggestions in the class, such as video device driver, finger print scanner and few more, we decided that it would be best if we started our own kernel project. Our initial thoughts were to build a RFID driver. We tried finding one, but they were pretty expensive. We were informed by some students that Dr. De Medeiros is already doing some research on it, so we decided to contact him. He was very usefull, he pointed us to a hobby engineering website where we could buy cheap RFID reader. We presented this device and project to Kartik, and he suggested that this project could be too easy. Afterwards, we looked through the same website and found out few more interesting devices. Again, we talked to Kartik and he approved of UltraSonic Range Finder because it had I2C interface and we had to read and write to it. Even though we were not all too familiar with I2C we were hopping that it would be relatively easy connecting it to the computer. This was not the case, we had to look at alternative options.|
|June 06, 2006:||
Most of the time we spent figuring out how can we connect our UltraSonic Range Finder, that uses I2C, to the computer. After calling the company that we order the product from, we found out that this is mainly intended for robotics. We also found a $150.00 kit that we could use to build our own connector. However, even though that would have been interensting project it is risky and might not be doable in a given time frame.
|June 07, 2006:||
After UltraSonic Range Finder was no longer an option, we had to look into
another project. Dr. Baker suggested two projects, one option was
ATI All-In-Wonder x600 video card and the second option was to improve
one of the existing drivers. At the beginning, we decided to go with the
first option. We spent that afternoon researching and trying to find an open
source driver that we could use. However, the only thing that we found was
proprietary driver made by ATI. It had no video capture capabilities but we
could not improve on it since there was no source code. We had no other
choice then to go with second option: gray scale driver. We tried compiling
existing code, but id did not compile. We found that
couple debugging statements
that referred to v4l2 ioctl functions were
causing the problems. We re-compiled the
kernel with video4linux support, but that
didn't work either. Finally, we commented
out the code that was causing compilation
errors and then the code compiled. For now
we could not get it to run the application,
but just to compile.
|June 08, 2006:||
Much of today was spent getting the Sean and Atyula's driver to work
with the 2.6.16 kernel. There were a few changes from a previous
version of the kernel where the devices was placed in a different
place in the /dev/ folder. Also the device entry in the /proc/ folder
wasn't being handled correctly. We fixed these problems and updated
the installation scripts and the driver worked correctly for a single
Next we tried to make the driver work with 2 cards, one as an ISA
device and one as a PCI device. This didn't work at first becuase it
would crash when it detected it as an ISA device. We found that the
code was dereferencing a null pointer that expected a pci device. A
simple if statement protecting this dereference solved this problem.
After this fix the device worked correctly with 2 gray scale card, one
ISA and one PCI.
Currently we are trying to get the driver to work with an application
that uses V4L2. We chose to use xawtv a tv tuner application for X.
We are still trying to get this program up and running on our system.
|June 09, 2006:||
To get xawtv to work we had to do three things: configure it, make it,
and make install it. First thing first, we tried configuring it, but it didn't
work, it complained it needs some libraries, which we installed. Then
we were able to configure it, make it and install it. However, even though
this was done without any fatal error, it did not produce xawtv executable,
but it did produce radio, record, streamer and webcam executable.
We looked back into configuration and realized that it did not find X,
but it found X11. We found out that we need X Software Development
on our machine so we ran: yum groupinstall "X Software Development".
This fixed the problem. At this point we had xawtv executable, it executed
but it did not work. xawtv stalled while waiting for the free buffer. The message was:
/dev/video0 [v4l2]: no overlay support
v4l-conf had some trouble, trying to continue anyway
Warning: Cannot convert string "-*-ledfixed-medium-r-*--39-*-*-*-c-*-*-*" to typ e FontStruct
v4l2: waiting for a free buffer
We also found that once driver is loaded it works okay, however, if it is unloaded and then loaded again it would not work, not just for axwtv, but also for demo program. We might do some work later on today, but most likely we will tackle these problems tomorrow.
|June 10, 2006:||
We started work today at 1:00pm.
Our first goal was to find the reason behind the "v4l2: waiting
for a free buffer" message.
We found that printing this message is the last thing the program
does before it goes into pthread_cond_wait() statment and never comes
out, causing the program to hang.
To investigate the cause of this error we searched the xawtv source code
for the original error and found it in xawtv/libng/plugins/drv0-v4l2.
We then traced the function calls as back as far as we could and observed
the flow of the program from inserting printfs into the code.
We understood the path the code took to get to the error.
However, we did not understand the meanings of several of the variables
For example there are many references to the v4l2_handle structure, however
there is no documentation for it.
When we tried to trace the function calls back to their source we were never
able to go any higher than the ng_vid_driver structure which xawtv seems to
use as an interface to the v4l2 device. We then tried to use strace
to trace the code further but this gave no more information than our printfs
and reading the code. We called it a night at 8:30pm
|June 11, 2006:||
Today we started at 1pm again. We're still unable to follow the code
errors to any useful conclusions about what steps we should take to
get the xawtv program to work. We've searched the code and googled
the error messages. We found a link to
suggested they had some success by removing the checks for reference
count in the Xawtv driver. We tried this but decided it was unwise to
follow this path since we don't know exactly what removing these
checks will do.
Since we didn't know where to go from here we played around with the
hrtdemo program and found the program crashed when you tried using the
streaming video option. After discovering this we decided to try to
fix the streaming option. We're still unsure if the problem lies in
the hrtdemo application or the driver. To help solve this problem we
downloaded the source for hrtdemo and attempted to compile it but
found our system lacked many, many, many librarires required for
compilation. Our yum installation program wasn't working and we ran
into dependencies problems. After 3 hours of no progress and
discussion with other groups that were in a similar position we
decided to install a fedora core installation that Danny and Ryans
group was using. This installation allowed them to compile the test
programs without error. Now we've regressed to project 1.
|June 12, 2006:||After installing Fedora Core
5 and compiling 2.6.16 kernel, we were hoping we will be able to
compile the test program that Sean used and another v4l2 application
that did not work earlier. This was the case and we were able to
successfully compile and run their test program. Now, unlike when we
used pre-compiled executable, the streaming worked, so there was
nothing to do there. Next, we wanted to install xawtv again, but could
not because of FSlib.h from X11R8 was missing. At this time Dr. Baker
helped us by looking at xawtv code and pointed out how they misused
threads, locking and freeing and that could possibly be the reason it
doesn't work. We wanted to try installing another v4l2 application,
that could not be installed under Scientific Linux. We installed
Cyclops and were able to run it in FC5. Since it successfully ran, it
proved that video4linux is also correctly implemented and working in
the existing code. Since, streaming and v4l2, was no longer an option,
we discussed few other options, such us, creating a fake device,
something like scull, where we could demonstrate our understanding of
concepts taught in the class. We also tried contacting an electrical
engineering student to see if someone could help us to connect our
UltraSonic Range Finder to the computer. Our project idea was to get
streaming and v4l2 interface working, but since it is correctly
implemented by Sean's team, we have nothing to do in these areas. We
are trying to see if we can get our initial idea, UltraSonic Range