How to handle hosts w/color conversion built in?
Hi Guennadi and all,
I've been trying to make my omap4 camera host driver to allow YUYV -> NV12 color conversion, and add that to the supported host-client formats, but I think I have hit the wall with the host design.
I noticed that the soc_camera seems to be designed to just pass-through the client supported formats (i.e. if my sensor supports YUYV and JPEG, those will be the supported formats only)
Now, in my host driver, I have a feature to do a color conversion to NV12, but I'm still not sure on how to expand the supported formats to, say: YUYV, JPEG, and NV12 (which would be available only if the client outputs YUYV, of course).
I was trying adding a customized get_formats function, but as soc_camera_init_user_formats anyways depends heavly on the sensor's enum_mbus_fmt, it's hard to add supported formats that the sensor doesn't directly support.
Has this been done before? Any advice?
Regards,
Sergio
Quoted 9 lines · Sergio Aguirre
Hi Guennadi and all,
I've been trying to make my omap4 camera host driver to allow YUYV -> NV12 color conversion, and add that to the supported host-client formats, but I think I have hit the wall with the host design.
I noticed that the
soc_cameraseems to be designed to just pass-through the client supported formats (i.e. if my sensor supports YUYV and JPEG, those will be the supported formats only)
No, this is not the case.
Quoted 11 lines
Now, in my host driver, I have a feature to do a color conversion to NV12, but I'm still not sure on how to expand the supported formats to, say: YUYV, JPEG, and NV12 (which would be available only if the client outputs YUYV, of course).
I was trying adding a customized
get_formatsfunction, but assoc_camera_init_user_formatsanyways depends heavly on the sensor'senum_mbus_fmt, it's hard to add supported formats that the sensor doesn't directly support.Has this been done before? Any advice?
Of course, this is supported. See sh_mobile_ceu.c, mx3_camera, pxa_camera, omap1_camera. Just search for the format array defined with "static const struct soc_mbus_pixelfmt" and see how it is used. Feel free to ask again, if you have more questions.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
Hi Guennadi,
Thanks for replying.
Quoted 8 lines · Guennadi Liakhovetski
Quoted 6 lines · Sergio Aguirre
Hi Guennadi and all,
I've been trying to make my omap4 camera host driver to allow YUYV -> NV12 color conversion, and add that to the supported host-client formats, but I think I have hit the wall with the host design.
Quoted 5 lines
Quoted 3 lines
I noticed that the
soc_cameraseems to be designed to just pass-through the client supported formats (i.e. if my sensor supports YUYV and JPEG, those will be the supported formats only)No, this is not the case.
Ok.
Quoted 11 lines
Quoted 11 lines
Now, in my host driver, I have a feature to do a color conversion to NV12, but I'm still not sure on how to expand the supported formats to, say: YUYV, JPEG, and NV12 (which would be available only if the client outputs YUYV, of course).
I was trying adding a customized
get_formatsfunction, but assoc_camera_init_user_formatsanyways depends heavly on the sensor'senum_mbus_fmt, it's hard to add supported formats that the sensor doesn't directly support.
Quoted 6 lines
Quoted 1 line
Has this been done before? Any advice?
Of course, this is supported. See
sh_mobile_ceu.c,mx3_camera,pxa_camera,omap1_camera. Just search for the format array defined with "static const structsoc_mbus_pixelfmt" and see how it is used. Feel free to ask again, if you have more questions.
Ahh... OK. I understand now :)
So, you basically first determine the count of sensor formats, by looping through enum_mbus_fmt in the sensor, and with every call to get_formats with the index range, you can return 2 or more formats.
In my case, when the sensor supports YUYV, I'll return 2 and update the xlate array with 2 entries, instead of just one, is that right?
Sorry for the noise, and thanks for the patience :)
I've been focusing more on the actual HW functionality, rather than the clean design. But now it's time to clean things up and prepare for upstreaming :)
Regards,
Sergio
Quoted 7 lines
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
Quoted 10 lines · Sergio Aguirre
Quoted 4 lines
Of course, this is supported. See
sh_mobile_ceu.c,mx3_camera,pxa_camera,omap1_camera. Just search for the format array defined with "static const structsoc_mbus_pixelfmt" and see how it is used. Feel free to ask again, if you have more questions.Ahh... OK. I understand now :)
So, you basically first determine the count of sensor formats, by looping through
enum_mbus_fmtin the sensor, and with every call toget_formatswith the index range, you can return 2 or more formats.
Actually 0 or more. Usually you return 1 if you just support the sensor format in pass-through mode. If you return more, that usually means, that in addition to pass-through you can also convert that sensor format to some other format.
Quoted 2 lines
In my case, when the sensor supports YUYV, I'll return 2 and update the xlate array with 2 entries, instead of just one, is that right?
Right - because you can pass YUYV 1-to-1 and also convert it to nv12.
Thanks
Guennadi
Quoted 16 lines
Sorry for the noise, and thanks for the patience :)
I've been focusing more on the actual HW functionality, rather than the clean design. But now it's time to clean things up and prepare for upstreaming :)
Regards,
SergioQuoted 7 lines
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/