/*
* filename : project4.jnl
* created : 2005.06.04
* modified : 2005.06.16
* author 1 : Sean Toh, seantoh [at] gmail [dot] com
* author 2 : Atulya Mahajan, mahajan [at] cs [dot] fsu [dot] edu
*
* desc
* ----
* Journal for programming assignment #4 : A device driver for a video frame grabber
*/
2005.06.04
----------
1. Copied the bare-bone driver and the demo program provided by Dr. Baker.
2. Created a CVS repository for this project.
3. Test and understand the source code.
Author 1's machine is configured with a black & white frame grabber device while author 2's machine has a colored device.
This will actually benifit the testing phase as updates for the driver can be tested on each machines.
Also, author 1's machine is running 2.6.10 kernel while author 2's machine is running on 2.6.11.
We will also benifit from such setup as we can make sure the updates for the driver will work
on different kernel versions.
4. Identified the project task. Decided on how we should approach the problem.
Basically we will have a checklist of task required in the project description. This checklist will be as such:
Task Black/White Colored
---------------------------------------------------------------------------
1. read functionality
2. real-time streaming & config
3. Probing PCI/ ISA
4. Interrupt
5. ...
Observing the layout above, we will exercised an incremental development approach,
starting from the top of the list and test each task as they are completed for both the black & white and colored devices.
2005.06.05
----------
1. Spent the entire day trying to solve one bug: subsequent read falls into a blocking read state.
Attempts to remove module result in a lock up on the system.
Solution:
---------
a. The problem was identified.
Tasklets that are disabled was not re-enabled whenever the "hrt_timer_activate()" was executed again.
We introduced "dev->tasklet_active" variable inside struct hrt_dev structure.
We re-enable the tasklet by checking against this variable.
2. After implementing the solution above, we were able to run the hrttest demo program multiple times and
unload the hrt module without any problems.
3. Author 1 could not run the hrttest demo program on his machine.
There was an error initializing the SDL video device.
Further investigation is necessary.
4. Currently, even though we have solve problem highlighted in (1),
the hrttest program displays distorted video output (i.e. kind of similar to video feed on a mammogram).
We believe that this has to to with speed of transfer from kernel space to user space.
Further investigation is necessary.
2005.06.06
----------
1. On 2005.06.05, we mentioned that in (3) that author 1's machine could not run hrttest demo program.
We discovered that SDL library requires that the "X Development Package" be installed on the system.
Author 1 has to re-install the entire operating system as there is no way to get the "X Development Package" installed.
2. After re-installing the OS, the hrttest program was able to run without problems.
Another observation was made. The black & white device on author 1's machine displays everything just fine.
Unlike item (4) on 2006.06.05, no video distortions were experienced.
3. We have also added "hrt_load" and "hrt_unload" script to ease the process of module loading and unloading.
4. In the afternoon, we continued to work on the driver.
We discovered a couple of bugs in the bare bone source code. Fortunately, Dr. Baker was around to provide us
with the necessary help to iron out these bugs.
2005.06.07
----------
1. We implemented the code for the color frame grabber device.
There were a couple of changes necessary.
a) we had to modify the bare bone driver source code provided to support color display.
b) we had to modify the "hrttest" test program to support color display.
All that was really necessary was to set the depth to 16 for color instead of 8.
2005.06.08
----------
1. We did a comparison between the frame rate that our current driver produces and the frame rate from the driver written
by Veena and Arthi (from previous semesters, TEAM BGA).
We notice that their frame rate are higher that ours by 2-3 folds.
We then decided to improve our existing driver code to produce much higher frame rate.
2. Added code to determine separate execution of code for color and grayscale devices. The code logic for color
devices is different from the code logic of grayscale devices.
3. Added code to determine separate execution of code for dual vs. single ported devices. The code logic for dual
ported devices is different from the code logic of single ported devices. Basically, single ported devices requires
freezing and unfreezing frames, while the dual ported devices does not.
4. We currently have achieve a frame rate comparable to TEAM BGA's driver.
However, the are still some minor issues that we will futher address.
5. There is another bug in the original bare bone driver. Somehow, the interrupt detection
code detected that one of the color card has interrupt support.
This is not expected as Dr. Baker said that there are only two cards with interrupt support and both
are grayscale cards. Further confirmation is needed.
2005.06.09
----------
1. We resume to resolve the issues we had with the color cards. This is regarding the distorted video that is
output to screen.
Dr. Baker advised us on how to correctly capture the frames in order to output the correct video feed.
(Note: Suppose we neglect the distortion on the video feed, we were able to achieve a higher frame rate.)
2. Understanding the instructions from Dr. Baker in (1), we have decided to re-evaluate our driver code to properly
handle proper video feed.
3. Dr. Baker confirmed with us that if the interrupt is detected on the card, we can safely assume that the card
does in fact support interrupt.
(Note: This is in response to the point highlighted on 2005.06.08 in (5)).
4. Currently we have another flaw in the driver, in that if we enable the interrupt code to install the interrupt,
the entire OS will halt upon module initialization. This has yet to be resolved.
2005.06.10
----------
1. The issue with color cards has been resolved. However, this is only for the read functionality.
The frame rate on the greyscale card was good, but poor on the color cards.
Also, this lack in performance has to do with the fact that color cards are not dual ported.
2. We reviewed the video for linux 2 implementation.
3. Code documentation.
2005.06.11
----------
1. We implemented the video for linux specification in our module.
2. We tested the reading functionality and our driver works for both color and greyscale card, with the video for linux
in place. The test program was adapted from TEAM BGA. The original test program only supported greyscale testing.
Our modification to the test program incorporated color testing.
3. We proceed to implemented streaming functionality.
4. Code documentation.
2005.06.12
----------
1. To date, our implementation supports streaming only on greyscale cards.
2. There is still some design issues with streaming on color cards. This has to do with the fact that
colors cards are not dual ported.
3. We made additional modification to the test program adapted from TEAM BGA to support sub window display.
4. Code documentation.
2005.06.13
----------
1. Code documentation.
2. Review items that have yet been achieve.
2005.06.14
----------
1. Modified the user test program to further support toggle between, color & greyscale,
and invert.
2. We implemented the invert inside our module via an ioctl command call. Though working, the quality of
video output after invert degrade. We think that this is just a matter of our invert algorithm.
We will return to solve this matter after we completed other major requirements.
3. Started to investigate on persistent system hang after streaming is turned on.
We believe that this has to do with the call to mmap.
4. Code documentation.
2005.06.15
----------
1. Continued on our investigation on persistent system hang.
2. We have resolved the issue with interrupt highlighted on 2005.06.09 item (4).
Our code iniated the tasklet even before the the module is fully initialized.
We implemented code to fix the problem.
3. We have also implemented code to support for interrupt if it is detected.
Basically, if there is interrupt present, we will use it. We use timer otherwise.
Also, since interrupt that is generated represents field changes, we copy the
field on every field change. However, we only send to users buffer after 2 counts of
field changes. We say a dramatic improvement in performance especially in color
cards, since color cards does not have DUAL PORT support.
4. We began performing some regression test on our module. We ran the user test program
for 2 hours both on color card and greyscale card. Both ran without problems.
5. Code documentation.
2005.06.16
----------
1. Preparation of presentation.
Capture still images output and video output for use in presentation.
2. Code documentation and other form of documentations.
3. Prepared README files for module and test application.
4. Prepared known bugs/ issues report.