Rodrigo Rosenfeld Rosas wrote:
> Hi Jan and others interested.
> I've finally got my driver in a usable condition. It lacks a lot of 
> functionalities yet, but it aplies to my needs.
> I would like to propose a real-time video interface for using with RTDM.
> For making it simple to port Linux applications to Xenomai, I tried to make 
> it 
> as close as possible to Video for Linux 2 API. I didn't see any serious 
> problem regarding its use on real-time environments in the specification. So, 
> the changes I think that would be necessary are:
> o Change open/fopen to rtdm_dev_open
> o Implement MMAP/MUNMAP as an IOCTL (while it can not be done in a rt-context 
> in the mean time, nor should be necessary)
> o Implement also as IOCTLs: select and poll (I didn't implement them on my 
> driver because I didn't need them, but it should be necessary accordling to 
> specs)

You may want to have a look at this thread regarding poll/select and RT:

Do video capturing applications tend to have to observe multiple
channels asynchronously via a single thread? If so, my statement about
how often poll/select is actually required in RT-applications may have
to be reconsidered.

> o Change all timeval structs to uint64_t or some typedef to it for making it 
> easier to store the timestamps (we use rtdm_clock_read() instead of 
> gettimeofday())
> I can't remember of another issue now. I think these changes would be enough.
> Any ideas?

Does your time allow to list the minimal generic services a RTDM video
capturing driver has to provide in a similar fashion like the serial or
the CAN profile? If it's mostly about copying existing Linux API specs,
feel free to just reference them. But the differences should certainly
fill up a RT-video (or so) profile, and that would be great!


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to