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 d
>
> Userspace tells the driver what it should do and the driver decides how to do
> it.
> That's how it works.
Sounds a little religious. Not sure if you've been listening..
>
>> And for us it is even more reusable, because we can run the
>> same thing on a standalone 'OS' (no OS really) and
Hi,
>
> The XML is basically just a dump of all the sensor registers, right?
>
There are two sections: The register tables, and the property wrappers.
Property wrappers don't have to necessarily link to registers, but
that's covered in the docs.
> So you are not talking about 'properties', but
Hi Hans,
>
> Can you give examples of the sort of things that are in those registers?
> Is that XML file available somewhere? Are there public datasheets?
>
If you mean the sensor datasheets, many of them are buried behind NDAs,
but people are writing opensourced headers too...let's leave this
Hi,
>
> Yes. As long as the sensors are implemented as sub-devices (see
> Documentation/video4linux/v4l2-framework.txt) then you can add lots of custom
> controls to those subdevs that can be exposed to userspace. Writing directly
> to sensor registers from userspace is a no-go. If done correctly
Hello,
I was wondering if it makes sense to raise a discussion about a few
aspects listed below - my apology, if this might be old coffee, I
haven't been following this list for long.
Since older kernels didn't have the matching functionality, we (a few
losely connected developers) had "hacked" a
