[PATCH 14/21] port-node: Introduce pa_port_node

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

 



On Wed, 2013-06-19 at 19:50 +0200, David Henningsson wrote:
> On 06/19/2013 05:40 PM, Tanu Kaskinen wrote:
> > pa_port_node takes care of things that are common to all port nodes.
> > The port device class is used in the node name for some extra
> > user-friendliness. The goal is to avoid the long and cryptic names
> > that are currently generated for sinks, sources and cards.
> 
> I'm not following. Why do we need extra pa_port_node and pa_sink_node 
> objects? Why don't we just have a pa_node pointer (or even embedded 
> struct, if that makes sense) in pa_device_port / pa_sink instead?

pa_node will probably have some callbacks, at least for activating the
node. I expect that e.g. pa_port_node would have a common implementation
for activating ports. There may or may not be need for further
specializing the activation code by adding an activation callback also
to pa_port_node. This is largely speculation, however, because this
hasn't been fully designed yet. If you think pa_port_node is bad, we
could try going without it until we actually need it.

> If every sink, source and port have exactly one node, that seems to be 
> the logical object model. Or can sinks, sources and ports have more than 
> one node attached to them?

I don't think it's likely that we would some day need one port or sink
to have multiple nodes - we certainly don't need it today. It's entirely
possible that a port or a sink could have zero nodes, however (or at
least it's possible for sinks - e.g. bluetooth sinks don't have nodes,
and neither do alsa sinks if ports are present).

-- 
Tanu



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

  Powered by Linux