Add a new video(4) framework that provides /dev/videoN, buffer
management, mmap lifetime, and V4L2 ioctl dispatch for video capture
drivers. Hardware drivers implement struct video_hw_ops callbacks
and use video_buf_acquire/write/done to deliver frames.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 74972 Build 71855: arc lint + arc unit
Event Timeline
Comment Actions
I also have a WIP for this, please give me some more time to compare and merge. Thanks!
Comment Actions
Take your time, this is a framework i used for months locally, i just waited until i got the fwcam landed to do both refactoring and testing at once.
Comment Actions
@markj would you mind eyeballing the mmap / pager stuff here? seuros is looking to refactor uvideo into a generic video layer and then drivers that implement this video API. Since uvideo got a bunch of pager/mmap related changes recently I'd like to make sure this gets done too.
| sys/dev/video/video.c | ||
|---|---|---|
| 103 | What's the reason for allocating individual pages like this, and relying on the direct map to access them? It's complicated and won't work if we don't have a direct map. It looks like you can instead use kmem_malloc()... then you'll get a page-aligned buffer already mapped into the kernel, and you can use vtophys() to find the physical address when needed in the fault handler. video_buf_write() would just be memcpy(). Look at what uvideo does today, which is fairly similar. (It uses vm_map_find() and vm_map_wire() to do basically the same thing as kmem_malloc().) | |
| 139 | Please use refcount(9). | |
| 177 | offset is already unsigned. | |
| sys/dev/video/video.c | ||
|---|---|---|
| 103 | Sorry, ignore my references to kmem_malloc(). That's not as convenient since the backing pages will automatically belong to kernel_object. Just follow uvideo. | |
| sys/dev/video/video_if.h | ||
|---|---|---|
| 142 | All this is very linux-like, please do a real interface with kobj | |
Comment Actions
Sorry I'm late, thanks for your patience.
| share/man/man4/video.4 | ||
|---|---|---|
| 2 | Our style guides show a blank comment line above this | |
| 11 | "generic" is implied by "framework". | |
| 13–27 |
| |
| 31–32 | FreeBSD is is printed in the manual metadata cast by line 7, so there is no need to put it here. It's also ever so slightly harder on downstream adoption. | |
| 34 | Please consider using %d. It is more traditional and less ambiguous when used consistently. | |
| 34 | please consider using %d instead of N. It is clearer and more traditional. | |
| 38 | I'm wondering if Video4Linux2 should be .Sy (bold)? | |
| 46 | All these ioctls are Dv's. | |
| 80–91 | I'm not sure we should or shouldn't do this. Traditionally, these would be in the SEE ALSO section, and SEE ALSO would be uncluttered so it would be very obvious the relation. However, this may be a great idea on the hardware compatibility list? | |
| 96 | I'm not sure we should or shouldn't do this? | |
| share/man/man4/video.4 | ||
|---|---|---|
| 13–27 | We should probably do a sweep remove them at once. I just copy an existing manpage and edit it. | |
| 96 | I will remove it, but that the spec i used now . There is https://docs.kernel.org/userspace-api/media/v4l/v4l2.html which is more complex and complete. | |