Hi, > > Not religion, it's experience. I understand what you want to do and it is > just a bad idea in the long term. Mind you, it's great for prototyping and > experimentation. But if you want to get stable sensor support in the kernel, > then it has to conform to the rules. Having some sensor drivers in the kernel > and some in userspace will be a maintenance disaster. Sorry, from our perspective the current v4l2 system *has* already been a maintenance disaster. No offense, but that is exactly the reason why we had to internally circumvent it. You're free to use the system for early prototyping stage as well as for a stable release (the framework is in fact running since 2006 in medical imaging devices). It certainly cost us less maintenance so far than syncing up to the changing v4l2 APIs. > > Besides, how is your sensor driver supposed to work when used in a USB webcam? > Such a USB bridge driver expects a subdevice sensor driver. Since you use a > different API the two can't communicate. Hence no code reuse. > I don't see a problem there either. Because you just put your register access code into the kernel. That's merely a matter of two functions. The sensor daemon doesn't really care *how* you access registers. >> >> Not sure if you understand: I do not have to implement or generate ioctl >> handlers and call them. This is definitely less expensive in terms of >> coding. All the register access is handled *automatically* using the HW >> description layer. > > Using what? /dev/i2c-X? That's using ioctls (I2C_RDWR). > Yes. But I have to write exactly two wrappers for access. Not create tables with ioctl reqcodes. > > Well, you clearly want *your* solution. I've been working in the v4l subsystem > for many years now ensuring that we can support the widest range of very > practical and non-academic hardware, both consumer hardware and embedded system > hardware, and working together with companies like TI, Samsung, Nokia, etc. Nope. I want any solution that does the job for our requirements. So far it hasn't been doing it. It's not just getting an image from a sensor and supporting v4l2 modes, but I think I've been mentioning the dirty stuff already. > > You (or your company/organization) designed a system without as far as I am aware > consulating the people responsible for the relevant kernel subsystem (V4L in this > case). And now you want to get your code in with a minimum of change. Sorry, that's > not the way it works. > Just that you understand: I'm not wanting to get our code into somewhere. I'd rather avoid it, one reason being lengthy discussions :-) Bottomline again: I'm trying to find a solution to avoid bloated and potentially unstable kernel drivers. Why do you think we (and our customers) spent the money to develop alternative solutions? Cheers, - Martin -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
