Re: [PATCH 3/3] AVRCP: Add Passthrough Signal

["David Stockwell" <dstockwell@frequency-one.com>]

Luiz,

-----Original Message----- 
From: David Stockwell

Hello, Luiz

-----Original Message----- 
From: Luiz Augusto von Dentz

Hi David,

On Thu, Aug 25, 2011 at 2:58 AM, David Stockwell
<dstockwell@frequency-one.com> wrote:
> +++++ OK, maybe a readwrite Passthrough property indicating how 
> passthroughs
> are handled: Signal, Uinput, Both, None?  Or simply a PassthruSignal
> property (true/false, default false), given that the presence/absence of
> /dev/uinput handles the other case?
>
> I really think the Control should emit the signal...since it comes from a 
> CT
> (and not really from a MediaPlayer or somesuch).

You are missing a very important point here, parsing of these vendor
specific commands would have to be split to each target thus we cannot
guarantee a consistent handling of them, if we stick to uinput I think
we should use KEY_VENDOR, otherwise we should send the commands
directly to the player.

+++++
Actually, I expected that the routing of these passthroughs would be handled
outside BlueZ, from Control(s) to (whatever) media playing app(s) in a
supervisory app/daemon.  Whether the signal is issued from the Control or
from the MediaPlayer interface is not significant to me; an easy code change
in the patch and in my supervisory app.  Any additional thoughts or
comments?
+++++

+++++

On second/third thought: while right now the Path of the Control and the 
MediaPlayer are the same (just different interfaces), this will probably not 
be the same in the future.

For my purposes, any Passthroughs received from a Control need to be tied 
back to the Control, hopefully by the path (which includes the bdaddr of the 
device).  Any routing from Control(s) to the media playing app(s) is really 
better handled outside, in the supervisory app.  Any impacts on the state of 
MediaPlayer are better handled outside BlueZ, looping back via the 
supervisory app.

Anyway, I know I am looking at things differently.  If this does not fit 
into the BlueZ Scheme of things, I will be quite happy to maintain this (and 
more) in a private fork, rebasing when warranted (while following GPL for 
any redistribution, etc.).

+++++
-- 
Luiz Augusto von Dentz