I wrote two device drivers for a dt2803 and EPIX-svm frame
grabbers. I did all the orginal testing by using cat as follows
cat /dev/grabber-name.pgm >image.pgm
I then tried to move to X11 programming and opened the device driver for repetitive reads using res = read(fd, &image.pixels, sizeof(image.pixels)); and the device driver did not return more than 4096 bytes. The image.pixels array has 61440 unsigned bytes of data. If I open then read and then close the device driver then it returns the entire sizeof(image.pixels) image corectly as though closing the file forced the remaining 4096 byte block read(fd, &image.pixels, 4096); requests. I want to avoid repetitive open and closes since this takes a long time. What does closing a device driver file do to force the remaining reads till sizeof(image.pixels) has been recieved? How do I force read(fd,&image,sizeof(image)); to continue reading the device driver till it has gotten sizeof(image) bytes without closing the device driver each time? I found the problem is cat asks for data in 4096 byte chunks and continues to ask for data by repeated reads from the device driver till it has the entire image. This fooled me to think all read requests would be done (through some sort of key hole buffer) in 4096 byte block requests. The X11 open asks the device driver to send the entire sizeof(image) all at once and only gets back 4096 bytes since the device driver was written specifically for repetitive 4096 byte size read requests. Where did this 4096 byte block size come from? I will be rewriting the device drivers so they are not dependent on the request for data in 4096 byte blocks. Now I am thinking since I took my driver template from some device drivers I found on sunsite (cortex cx100), I suppose others have -or will- stumble into this issue and were-are also confused by this sort of behavior. Can anyone add some words of wisdom or historical enlightenment so that others will not stumble into this as I have?
|