Re: [PATCH 5/5] pxa-camera: framework to handle camera-native and synthesized formats

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Media]     [Older V4L]     [Linux DVB]     [Video Disk Recorder]     [Linux Kernel]     [Asterisk]     [DCCP]     [Netdev]     [X.org]     [Util Linux]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [SSH]     [DVB Maintainers]     [Linux USB]     [Yosemite Information]
  Powered by Linux