Re: [tuxdroid-user] Event handling chain?

[Martin T. <ma...@ma...>]

On Tue, 2007-04-10 at 08:57 +0200, David Bourgeois wrote:
> On Mon, 09 Apr 2007 23:55:23 +0200, martin <ma...@ma...> 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.
> 
> 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.
> 
//m