On Thursday 21 March 2002 07:04 pm, Mark McClelland wrote: > Joe Burks wrote: > The time it would take to add that to gnomemeeting would be time well > spent. > There are quite a few cameras that only output RGB (ibmcam and > se401, to name a couple). The majority of the time would be spent > writing the conversion function, and that has to be written in either > case. In fact, ibmcam.h has a YUV->RGB macro that you could probably use. I don't think the majority of time would be spent writing the conversion function. I bet I could google for a RGB->YUV or YUV->RGB algorithm and have the result converted to code, tested and debugged within an hour. I think the majority of my time would be finding where gnomemeeting does its v4l, and figuring out how to change it to support RGB without affecting YUV. I have no doubt this would be time well spent. It would benefit people well beyond the scope of my little v4l driver. I also think there are about 100 projects which could benefit from me investing some time coding for them. Unfortunately my days are limited to 24 hours. The kernel developers are shouting "Keep It Simple Stupid" and keeping the kernel drivers as simple as possible. The application developers are shouting "Keep It Simple Stupid" and making the applications as simple as possible. If somebody isn't doing the non-simple stuff, the result is a user experience that sucks. And that's what we have. That is why I'm lobbying for a user space (middle tier, if you will) driver component that will keep the kernel space portion of the driver simple and make the kernel hackers happy, make the application side simple so they're happy, and make the user experience good. I'm not saying we should not allow a sufficiently sophisticated application low level driver access. > Also, don't forget about the time you will have to spend dealing with > angry users after Alan removes the conversion function from your driver ;-) Well, as you just said there are already a number of drivers that do colorspace conversion in the kernel (that's why there is a YUV->RGB macro in ibmcam.c). In fact cpia.c (my personal favorite sample v4l driver - it's the place I started when writing mine) does color space conversion to RGB555, RGB565, RGB24, RGB32, GREY, YUYV, UYUV, and YUV422 (I think it might be YUV420 natively). > See this page if you don't believe that will happen: > http://www.smcc.demon.nl/webcam/driver-reject.html Basically the email attached to that one says "Making a driver compatible with the existing v4l applications is forbidden". Forbidden because no app supports all the color space encodings. Basically v4l is broke, and nobody is allowed a work around to fix it (except those who already managed to get in). There is already a real simple mechanism for an application to select its "smartest" format: The first time you do a VIDIOCGPICT, the camera should return its closest-to-native format. If the application doesn't like that, then it should call VIDIOCSPICT with video_picture.palette set to the color space it likes the best. If the driver cannot support that, it returns -EINVAL. I think xawtv uses this to request 3 different color space encodings before it gives up and agrees to RGB24, as this debug info from my driver shows: 3comhc.c(182868):homeconnect_ioctl(690):VIDIOCSPICT depth = 16, pal = 7 3comhc.c(182868):homeconnect_ioctl(616):VIDIOCGCAP 3comhc.c(182868):homeconnect_ioctl(690):VIDIOCSPICT depth = 12, pal = 15 3comhc.c(182868):homeconnect_ioctl(616):VIDIOCGCAP 3comhc.c(182868):homeconnect_ioctl(690):VIDIOCSPICT depth = 32, pal = 5 3comhc.c(182868):homeconnect_ioctl(616):VIDIOCGCAP 3comhc.c(182868):homeconnect_ioctl(690):VIDIOCSPICT depth = 24, pal = 4 To all but the last one, my ioctl function returns -EINVAL.
