Project
Journal: A description of the actions taken on a daily basis,
describing the progress made, the difficulties encountered, and
discovered facts.
Monday: June 5, 2006
Time: 9:00 AM
Picked
the frame grabber project since the Logitech Web Cam and the MSI Tv
Tuner/Capture card were projects in which there was no manufacture
support.
Time 4:00 PM
We came to lab after knowing what needed to be done.
We
took the frame project knowing that after eight authors this would not
be an easy task. We printed all 3300 lines of code and began to do
static analysis of the code. We got the card from Dr. Gopalan around
7PM (thanks Dr. Gopalan) and installed them on our machine. The code
will compile but the module would not load since we needed to load
video 4 linux common module and videodevs module. After doing this the
module would not load would cause a series of oops messages that would
require the machine to be restarted. The error was in hrt_isa_init. We
commented this function out to keep on with out testing. We could only
detect one device and this device would not load. The module would load
but it is not registered. The major number of 82 is hard coded into the
driver but cat /proc/devices shows that the device is not there. We
also get an message from the videodev module error that the driver need
to be fixed to have sysfs support. Around 11 PM we called it a day.
Tuesday: June 6, 2006
Time 3:30 PM
After
class we came to lab with Dr. Baker so he would gives us a hand with
the problems we where having. His first response was for us to fix the
hrt_isa_init method so it would run but no throw oops messages. After a
2 hours of following the calls the code makes and putting print
statements in the execution path a reference to a pci_dev->device in
hrt_init was causing the problem. This reference is part of series of
debug messages that are enclosed with ifdef so prevent unwanted
execution but this variable is not defined anywhere else in the code.
We commented this small block of nonfunctional code. After this the
second device is also detected. It turns out that both devices are
grayscale cards. Both give the sysfs support needed error. The problems
that we have encountered is that the device do not register and when
you call unload and then try to reboot or shutdown they give recursive
fault error. We moved the cards around, borrowed Lucy’s cards and still
no luck with the error. We also discovered that the driver is sensitive
to the slot where the card is inserted. We continue to investigate why.
Around 10 PM we called it a day.
Wednesday June 7, 2006
Time: 3:30 PM
Came
down to the lab to get some more work done. Made this small web page,
got the color card from Dr. Baker and installed it and it is detected
as a color card by the driver. We began a close analysis of the code
and the code seems solid. The use of and, or, and complements makes the
code hard to follow but the flow is correct. We caught a little bug
with ISA_MODE since the driver was always in ISA_MODE. Even with pci
cards it would report them as ISA cards but the pci addresses would be
used. Around 12:00 PM we discovered that the register_video_device put
the device in /proc and not in /proc/devices. The awk command to get
the major number fails. We need to find out whey the video device is
being registered in the wrong location. We will continue in the next
work day. When we where leaving we spoke to Cory and Dragon about the
issue and in their machine the same thing happens. It seems to be
something in the 2.6.16.14 kernels that we all have that changed some
semantic of the driver. We are moving forward, slow but progress is
progress.
Thursday June 8, 2006
Time: 3:45 PM
Went
to the lab after class. The help of Dr. Baker helped us arrive the
conclusion that the driver does work. We made some small additions to
keep the state of the probing in check. The grey scale device works but
the color has some bugs that don’t allow it to display well. We called
it day around 4:45 since we have to study for the quiz since we both
need good grades in the quizzes. The way the driver works is completely
different than what we are used to with the scull and lifo devices so
we were caught be surprise. We hope to get the color card working
again. We might try it on the fedora box since instead of the
scientific linux to try the behavior in a different distribution.
Friday June 9, 2006
Time: 4:00 PM
Got
to the lab at 4 PM and began to try to get the testing programs to work
correctly. After some tweaking we got the grayscale to work well. The
I/O is very CPU intensive due to the design of the frame grabber. The
card out put is about 16 frames per second so there is ghosting. The
color card would not even work but after some adjusting we go the color
card to display. The display is not correct, we believe that there is
problem with the bits that represent the pixels like Dr. Baker
described. The image is in color but the image is distorted due to some
skewing of the pixels. We have made good progress to get the cards to
work very stable. Load and unload are now robust, these operations work
with out crashing the kernel. The display options can not be changed on
the fly since it will cause a kernel oups message. The next step is to
get color to display correctly. Once we get this fixed we are going to
tackle the probing and try to get rid of slot dependencies. Then we are
going to start testing of ISA probing since both cards are PCI mode.
Saturday June 10, 2006
Time 4 PM
We
started in the labs at 4pm and worked till 12pm. We aimed our goals in
trying to get the more recent testing program hrtview to illustrate
both the color and the grayscale. Earlier we mentioned that we got the
grayscale to show properly, however we were unable to get the color to
display. In an effort to get the color to work we needed to download an
additional library called SDL (Simple DirectMedia Layer). However, once
we compiled the testing program hrtview and ran the executable, it
still wouldn’t run. We discovered after a few hours of tracing the
error through the SDL library code and the hrtview testing program code
that for some reason when the user input any bit depth the SDL function
SDL_SetVideoMode() would return an error. We tried several work arounds
for a couple hours more including, recompiling the kernel with more
video and frame buffer options, however, none of our options worked.
Later, after doing some more research, on SDL we discovered that the
Fedora distro of Linux carries int natively and thinking that if we
missed installing some library files on the Scientific Linux distro we
might get lucky with Fedora. We ported the code over to the Fedora
distro and tried again. After, some small modifications to the
hrtview-testing program we were able to get the color video to work as
well as the grayscale. The color video however, is of poor quality and
low frame rate. We suspect, its an issue with how the rasters are being
captured and read. At 12pm we called it a night.
Sunday 11, 2006
Time: 1:00 PM
We
began the work day around 2PM. Our focus at this time is to get a more
robust driver. We got the PCI card detection fixed since PCI mode cards
will be detected no matter what position. They are remove well. The
next thing was to tackle the ISA mode card detection and removable. The
ISA cards insert well but panic the kernel when they are removed. The
problem found consists of this: When a ISA card is detected you probe
it, if it is there you call ISA_cleanup that calls cleanup ( a generic
clean up function for ISA and PCI), and if the card is found the
register_video_device function is called. In the case of PCI cards you
must register a PCI device first, if not found in the probing done by
kernel then PCI clean up is called that calls the generic cleanup. If
the card is found then register_video_device is called. To sum this up
it means that PCI cards need a two stage registration while ISA cards
only have one registration.
The
problem described above has this effect: The ISA device is not removed
from the /dev directory. When you try to reboot or shutdown the kernel
tries to remove the device but all the memory for the device is gone so
you cause a page fault that causes a recursive fault. The kernel that
this time is broken and force reboot must be done. The cause of this
when clean up is called is does not remove the ISA device since only
disable pci device is called. We used video_unregister_device to undo
the registration done in init. This function is dangerous since if you
try to unregister a device that is not there you panic and break the
kernel. Our solution was to put let cleanup know the context of the
call made to him. We have determined that the cleanup function is has
3 contexts, ISA probe, PCI probe, and remove. The video unregistration
function should only be called in the remove context if the device is
ISA. We put some code that does this and the ISA removal is now
robust. We also added some codes to make registration work. At this
detection and registration is robust.
The
other problem we want to fix the color pixel bit remapping. The pixels
are 16 bits but the bits are separated into different memory address.
The reordering of bits in the current code does not work, we get fuzzy
color image and the cause is that the code is stuck in only case and is
not doing all the step to fix the bits that the user app is getting. We
put some test statements but the solution will explored tomorrow.
Monday June 12, 2006
Time 4:30
We
began to analyze the color portion of the driver to fix the distorted
image. This was a tuff cookie since it took 6 hours just to understand
what the code was doing. We put a series of print statements to see how
the flow of the code was and there seemed to be a logic error in the
grab_field function. The function had these series of test and no
matter what options where set the test had no effect the option of
capturing a subwindow did not work. We removed that code since there
logic was hard to follow and began to code it ourselves. We had by 1PM
a color image that was 649 by 480 and was crystal clear and crisp. The
next stage is to add the subwindow feature back in.