Index of /~baker/devices/projects/dracor

	Name	Last modified	Size	Description

	Parent Directory		-

COP 5641 - Linux Kernel & Device Driver Programming

COP 5641 - Linux Kernel & Device Driver Programming
Final Project

Team Info:

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

Project Objective:

To get the driver fully operational under the stable Linux 2.6.16 kernel using a standard Video4Linux application as a test.

Daily Reports:

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 grayscale device. 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 and structures. 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 http://www.cs.fsu.edu/~baker/devices/lxr/http/source/pixelsmart which 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 Finder, working.

Links: