public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: xie <yili.xie@gmail.com>
To: "Dongsoo, Nathaniel Kim" <dongsoo.kim@gmail.com>
Cc: v4l2_linux <linux-media@vger.kernel.org>
Subject: Re: About the VIDIOC_DQBUF
Date: Mon, 08 Jun 2009 16:02:56 +0800	[thread overview]
Message-ID: <1244448176.15110.0.camel@xie> (raw)
In-Reply-To: <5e9665e10906072356l686f4301v2546460c86bdf721@mail.gmail.com>

Hi Dongsoo, Nathaniel ~
You must be expert on V4l2 ~ Thanks very much for your help and advice
~!~
I used the MXC camera interface driver from Fressscale ,I readed the
driver interface just now ,and have fouded that the driver not modified
the buf.lenth but buf.byteused . You are very right , I will use the
buf.byteused instead of buf.length ~

There is also a problem I want to consult to you ~ Can i get a full
frame with the below method if the driver have no problem ?

memcpy((mCameraProwave->getPreviewHeap())->base(),
v4l2Buffer[buf.index].start, buf.byteused) ;

Because I just need to implement a hal for getting the frame data and
post it to top layer , so I used the memcpy simply . Am I right ~ ? Or
what about your advice ? 

Thanks a lot ~~ 



在 2009-06-08一的 15:56 +0900,Dongsoo, Nathaniel Kim写道: 
> Hello Xie,
> 
> I'm not sure which camera interface driver you are using, but it seems
> to be camera interface driver's problem. Let me guess, are you using
> pxa camera interface driver from Marvell?(proprietary but not in up
> stream kernel)
> It just looks like that camera interface driver is not returning
> proper data in dqbuf.
> 
> And one more thing. I prefer to use byteused rather than length in
> buf. because as far as I know the size of preview data from camera is
> in byte unit which we need to copy to memory. But it should be
> possible to use length, I guess..
> Cheers,
> 
> Nate
> 
> On Mon, Jun 8, 2009 at 11:05 AM, xie<yili.xie@gmail.com> wrote:
> > Dear all ~~
> >
> > I have met a issue when I used the mmap method for previewing . I just
> > used the standard code as spec to get the image data :
> > status_t CameraHardwareProwave::V4l2Camera::v4l2CaptureMainloop()
> > {
> >        LOG_FUNCTION_NAME
> >        int rt  ;
> >        unsigned int i ;
> >        fd_set fds ;
> >        struct timeval tv ;
> >        struct v4l2_buffer buf ;
> >
> >        for(;;){
> >                FD_ZERO(&fds) ;
> >                FD_SET(v4l2Fd, &fds) ;
> >                //now the time is long ,just for debug
> >                tv.tv_sec = 2 ;
> >                tv.tv_usec = 0 ;
> >
> >                rt = select(v4l2Fd + 1, &fds, NULL, NULL, &tv) ;
> >                LOGD("The value of select return : %d\n", rt) ;
> >
> >                /********** for debug
> >                if(V4L2_NOERROR != v4l2ReadFrame()){
> >                        LOGE("READ ERROR") ;
> >                }
> >                ***********/
> >
> >                if(-1 == rt){
> >                        LOGE("there is something wrong in select function(select)") ;
> >                        //no defined error manage
> >                        return V4L2_IOCTL_ERROR ;
> >                }
> >                if(0 == rt){
> >                        LOGE("wait for data timeout in select") ;
> >                        return V4L2_TIMEOUT ;
> >                }
> >
> >                memset(&buf, 0, sizeof(buf)) ;
> >                buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE ;
> >                buf.memory = V4L2_MEMORY_MMAP ;
> >                if(-1 == ioctl(v4l2Fd, VIDIOC_DQBUF, &buf)){
> >                    LOGE("there is something wrong in dequeue buffer(VIDIOC_DQBUF)") ;
> >                        return V4L2_IOCTL_ERROR ;
> >                }
> >
> >                assert(i < n_buf) ;
> >                LOGE("buf.index  0buf.length = %d %d \n", buf.index , buf.length) ;
> >        memcpy((mCameraProwave->getPreviewHeap())->base(),
> > v4l2Buffer[buf.index].start, buf.length) ;
> >                if(-1 == ioctl(v4l2Fd, VIDIOC_QBUF, &buf)){
> >                    LOGE("there is something wrong in enqueue buffer(VIDIOC_QBUF)") ;
> >                        return V4L2_IOCTL_ERROR ;
> >                }
> >                //break ;   //i don't know whether the break is needed ;
> >
> >        }
> >        return V4L2_NOERROR ;
> > }
> >
> > when executed the VIDIOC_DQBUF IOCTL,the return value was right, but the
> > value of buf.length would always  be zero. Then I used the read()
> > function to read raw data in the file handle for debug, and I can get
> > the raw data. Anybody have met this issue before ? Who can give me some
> > advices or tell me what is wrong , thanks a lot ~
> >
> >
> 
> 
> 


  reply	other threads:[~2009-06-08  8:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-08  2:05 About the VIDIOC_DQBUF xie
2009-06-08  6:56 ` Dongsoo, Nathaniel Kim
2009-06-08  8:02   ` xie [this message]
2009-06-08 11:40     ` Dongsoo, Nathaniel Kim
2009-06-09  2:22       ` xie
2009-06-09  7:41         ` Dongsoo, Nathaniel Kim
2009-06-10  5:10           ` xie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1244448176.15110.0.camel@xie \
    --to=yili.xie@gmail.com \
    --cc=dongsoo.kim@gmail.com \
    --cc=linux-media@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox