On 02/10/2012 04:50 PM, Mark Brown wrote:
On Fri, Feb 10, 2012 at 02:08:52PM +0100, David Henningsson wrote:
On 02/10/2012 11:55 AM, Takashi Iwai wrote:
David Henningsson wrote:
I guess it could be easier to parse if we avoid spaces in names,
Exactly, it was the reason.
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.
OTOH, we can take an optional directional suffix, i.e. "[location] base [direction] [channel]", too. For example, base can be "Video" or "Line", and direction can be "Out" or "In".
I'd like to hear rather comments from others.
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?
That will be worse for everyone, both those doing work with them, looking in alsamixer, etc.