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@xxxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
