On Tue, 11 Nov 2008, Robert Jarzmik wrote: > Guennadi Liakhovetski <g.liakhovetski@xxxxxx> writes: > > >> }; > >> > >> - camera host provide a static table like this : > >> struct soc_camera_format_translate pxa_pixfmt_translations[] = { > >> { V4L2_PIX_FMT_YUYV, V4L2_PIX_FMT_YUYV }, > >> { V4L2_PIX_FMT_UYVY, V4L2_PIX_FMT_UYVY }, > >> ... > >> { V4L2_PIX_FMT_YUV422P, V4L2_PIX_FMT_UYVY}, > >> }; > > > > Hm, I don't think you want to list all possible formats you can pull > > through this camera host. AFAIU, camera hosts can transfer data from > > cameras to destination (memory / framebuffer / output device...) in three > > ways: > Oh yes, you should list them all : that's what you'll end up doing once the > function format_supported() is fully implemented anyway, wouldn't you ? > format_supported() will compare a list of known formats to the sensor output > formats, and keep only known ones (ie. drop RGB32, or YUV 4:2:0, etc ...) Don't you think we can have a default case? If the format requested by the user is provided by the camera and we "can trandfer it 1-to-1" (bus-width == depth or some such) then just switch on the pass-through mode? > > Also, a probably better approach than what you suggested above (if I > > understood it right) would be not to use a static translation table, but > > to generate one dynamically during .add() and have them per-device, not > > per-host. > The translation table will be per-host static (it's hardwired in the chip), but > the generated supported formats will be dynamically generated by the host on > sensor attachment (ie. computed), and for each device. > > >> Is there a reason you chose to fully export the formats computation to hosts ? > > > > In short: I'd prefer to first keep this in pxa-camera, and then see as new > > host drivers arrive, whether we can make portions of the code generic. > > Makes sense? > I understand your thinking. I don't think it's the good way to go, but you're > the maintainer, you decide. We'll see soon enough, once TI and Qualcomm embedded > devices will be enough documented, who was right. Wow, I'm scared...:-) Ok, let's try it your way, I don't want to play the "maintainer" card, and you seem to be strongly in favour of a central solution, whereas I just slightly incline towards local... So, either give me a few days, or feel free to code off - whichever you prefer. If you do this, I think, best do something like int soc_camera_host_register(struct soc_camera_host *ici) { ... if (!ici->ops->enum_fmt) ici->ops->enum_fmt = soc_camera_enum_fmt; ... etc. for any other methods you want to provide defaults for. Instead of exporting more functions and letting hosts do int x_do_something(...) { return soc_camera_do_something(...); } Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list