On Fri, Feb 10, 2012 at 05:09:35PM +0100, David Henningsson wrote:
On 02/10/2012 04:50 PM, Mark Brown wrote:
Given that the normal desktop user does not usually look at these values these days, I'd say being parser friendly weighs heavier than being "normal English".
Not all the world is desktop.
The normal end user of the embedded system does not look at those values either.
There's rather a lot of people who do embedded development and do need to look at this stuff, though. There's a real cost to raising the bar for humans to understand things.
I think both naming schemes are good, and I'm not too worried about them being too verbose. If we run into names being longer than the string length we could back off and drop the location, I guess.
It's a complete pain for actually working with them and doing development - it renders badly in UIs (think about alsamixer for example, or people looking at things on 80 column terminals) and isn't friendly to people typing things in.
So your suggestion was, to avoid "Front Headphone" and "Rear Headphone" because the names were too long, and instead have "Headphone" and "Headphone,index=1" and have "Front" and "Rear" read out of a TLV?
No, some of the information should go in the name but we keep on coming up with more and more things to add and when we end up with "Left Silver Headset Jack Headphone" or whatever (which would be a fairly complete description of half the headset jack on one of my laptops) we probably ought to be cutting some of that out.
Though thinking about it duplicating all the individual bits of information in TLVs would be helpful to automatic parsing, we could possibly even do something clever like make minimal subset names that contained only the bits that were unique on a given system if we were bored enough.
Oh, by the way the extcon (Android switch class more or less) code looks to be coming along quite well which is going to be a third way of getting jack information out to userspace.