On Tue, 10 Apr 2007 14:50:52 +0200, Martin Thomas
<[EMAIL PROTECTED]> wrote:
On Tue, 2007-04-10 at 08:57 +0200, David Bourgeois wrote:
On Mon, 09 Apr 2007 23:55:23 +0200, martin <[EMAIL PROTECTED]>
wrote:
> Are button presses (like wing or head or RC) always passed on by the
> firmware or can they be 'swallowed'?
>
> I am thinking of adding a function to the firmware so that I can tap
the
> head button to mute sound.. but I am not sure if the button event will
> still
> be propagated to the daemon, overloading the button. Maybe I could
just
> do
> everything on the pc.. but I would like to play with the firmware a
> little
> more.
That depends on what you want to handle locally and from the computer. I
would say that muting the sound requires to have sound sent from the
computer so I would find it more logical to have the computer get the
head
button event and decide to do the mute (by siftware or send the mute
command). But in case you just use the usb audio device and don't have
the
daemon running, that makes sense to have it locally by firmware.
You might also want to mute locally stored sounds which Tux will play
regardless of a host computer. So perhaps a mute button is not as simple
as it appears.
You're right, it might be intersting to mute the local sounds easily. On
the other hand the internal sound flash can only store 1 minute of sounds
so you're not likely to play local songs and you can also turn off the
volume dial.
But anyway the above solution is still convenient if you store the mute
funciton associated with the head button event in eeprom, then even if the
computer is disconnected and you restart tux, you'll be able to mute with
the head button. That makes me think we need a toggle_mute() function
otherwise you'll only be able to mute and not unmute with this method :-)
In such a case, I think the standalone behavior proposal I already
explained a bit would be a good solution. You could associate the mute
function to the head button event in the eeprom (when this will be
possible to do from the api in the near future) and easily
enable/disable
that event from the computer. When disabled,the status of the button
would
still be sent to the computer but the sequence won't be played. So even
if
your applications need to use the head button at a certain point, they
could still disable the standalone head button event momentarily. Though
the daemon/api should handle that instead of the application.
It probably is an application level behaviour to associate buttons and
behaviours.
Yep but what I mean is that some of your your applications (let's say
VOIP) aren't supposed to know that you associated the mute function with
the head button locally on tux or from another application. So to avoid
muting at the same time you pick up the call, the api or a manager
application needs to deal with that.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
tux-droid-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tux-droid-user
