Index of /~baker/devices/projects/ryadan

[ICO]NameLast modifiedSizeDescription

[DIR]Parent Directory  -
[DIR]FRAME_GRABBER/17-Jun-2006 22:45 -
[DIR]Files/19-Jun-2006 16:43 -
[   ]Walega_Beech_Project4.tar.gz19-Jun-2006 16:33 59K
[   ]mail19-Jun-2006 16:20 82K

Kernel Device Driver
 
 
KERNEL DEVICE DRIVER PROJECT PAGE
 
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.
 
 
 
TEAM MEMBERS

Daniel Beech
Ryan Walega


HRT FRAME GRABBER

Goals: 1. Port the frame grabber to work on the 2.6.16.14 kernel.
                    The current driver will not work with the 2.6.16.14 kernel. The device driver
                          will finish the init functions but will not register the device. No major 
                          number shows up after the module is loaded. The process of making the
                          node does not occur due to the lack of major number. The major 
                          number used to load the device is hard coded to be 82. The driver also
                          needs sysfs support. 

            2. Improve the driver’s stability in the 2.6.16.14 kernel.
                    The current driver will cleanup with no warnings or errors but will but
                          cause a page fault when shutdown is called. This throws a recursive fault
                          that the kernel can not recover from.

            3. Remove the slot dependencies with driver.
                    Currently the detection process will vary depending on the which the slot the card is       
                            placed.