What-did-you-plugin-dialog

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2013-11-29 23:55, Tanu Kaskinen skrev:
> On Fri, 2013-11-29 at 14:22 +0800, David Henningsson wrote:
>> 2013-11-29 00:39, Tanu Kaskinen skrev:
>>> I have been thinking about this problem a bit, and it looks to me like
>>> our sink, source and port concepts don't fit this use case very well.
>>> The user plugs something to a jack, and the user should select the mode
>>> for the jack. A sink is not the same thing as a jack, and a port is not
>>> the same thing as a jack. I think we should have "jack" as a core
>>> concept and expose the jacks to clients, so that clients can set the
>>> jack mode when necessary. That's of course a fair bit of work...
>> I think it's true that our port concept does not fit exactly to the
>> jacks, especially not as you have made ports unidirectional. But I don't
>> think the solution to the problem is to introduce *yet* another core
>> concept. It's just too much complexity added to the core for one minor
>> edge case problem.
> I think we'll just have to agree to disagree here.
>
> So, you won't add the jack concept to the core. How would you feel about
> exposing a similar client interface from a module instead of the core?
> Make it possible to list all jacks in the system, get notifications
> about their state changes (when something is plugged in), and make it
> possible for clients to set the jack mode for jacks that can't detect
> the right mode themselves?
>
Thinking more about this, actually this is not the only case where a 
"jack" concept would apply. We also have the mic in / line in feature 
added for some IDT codecs.
Another thing is being able to switch a mic in + line in + line out into 
5.1 output, but not sure if that is as easy to model.

As such, maybe the jack is no longer an edge case. I was thinking along 
the lines of making a light-weight jack concept (I've called it 
port-group) using port properties, e g by adding

(for analog-output-headphones)
port-group=headset
port-group-modes=headphones, headset

(for analog-input-headset-mic)
port-group=headset
port-group-modes=headset

(for analog-input-headphone-mic)
port-group=headset
port-group-modes=microphone

...or something. That wouldn't be terribly complex to do, but still 
double the code size (i e, compared to hard-coding the ports).

However, extending that thought, that begs for *another* rewrite of the 
Gnome UI to use port groups as their main concept rather than 
ports...eeek...

Also, given my currently very limited time I don't have the time to 
implement jacks/port groups, and given your limited time, you likely 
don't have time to review it. As such, it seems there is no use in 
trying to upstream any solution right now.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic



[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux