[MPlayer-dev-eng] [PATCH] Apple Remote support

[Diego Biurrun]

On Tue, Aug 14, 2007 at 04:43:38PM +0800, Ulion wrote:
> 2007/8/14, Diego Biurrun <diego at biurrun.de>:
> >
> > > +    // current front, if closed, re-open the device to make sure
> > > +    // not affected by other apps or system use apple remote
> >
> > I don't understand.
> I explained this in another reply earlier:
> 
> in current mac osx, every process can open the device for Apple
> Remote, but only one can in exclusive mode, since we need exclusive to
> prevent triger system's or other apps' response for Apple Remote when
> mplayer is running front, we has to open the device in exclusive mode.
> and if mplayer or the master of slaved mplayer lost focus, mplayer
> should release the device from current exclusive mode, since we need
> not input when mplayer or master lost focus, so close it is  the right
> choice.
> 
> if do not add these foreground/background code, when mplayer is not
> the front app, system will take over the remote input, but both system
> and mplayer still response to the intput from remote, this is not the
> expected behavior, and after mplayer be re-focused, still, both system
> and mplayer will response to the inputs, this is not the expected
> behavior either. so I added these foreground/background check code to
> release inputs when mplayer not focused and to grab the input when
> mplayer is re-focused.

OK

The problem with your comment is that it is ungrammatical.  English
sentences *always* have to contain *both* a verb and a subject.  If you
leave out either your sentence will be wrong and what's worse, it will
not be understandable without considerable effort.  I've pointed this
out below, hopefully I'll be able to explain it.

I'll try to rephrase the comment with the help of your explanation:

  If we are switched from running as a foreground process to a
  background process and back again, re-open the device to make
  sure we are not affected by other applications or the system
  using the Apple Remote.

Is that what you were trying to say?

> and also, the license problem, although the original codes was writen
> by Ponekker Zoltan, but main idea of the codes possibly comes from the
> object-c version of Apple Remote codes --
> http://www.martinkahr.com/source-code/ which is MIT license, since our
> codes were writen by C, can we just use standalone license no matter
> whether inited codes comes from the object-c codes?

The MIT license is generally interpreted to allow relicensing, so there
is no problem.

> --- input/ar.c	(revision 0)
> +++ input/ar.c	(revision 0)
> @@ -0,0 +1,465 @@
> +
> +// on tiger, 5 always follows 6; on leopard, 18 always follows 19
> +// on leopard, seems no cookie value of 5 or 6.

there seems to be no cookie value of

> +// following is shortened cookie sequence list

is a

> +// keycode      cookies_on_tiger cookies_on_leopard keep-down

keep-down?

> +// hidden keys current not implemented:

currently

> +// MENU_NEXT_HOLD 15+14+6+15+14+6
> +// MENU_PREV_HOLD 16+14+6+16+14+6
> +// MENU_VUP_HOLD  20+14+6+20+14+6
> +// MENU_VDOWN_HOLD 19+14+6+19+14+6

This could be aligned.

> +// seems MENU_PLAY_HOLD trigger Apple Remote try to make pair.

This sentence contains no subject and is therefore hard to understand.
My best guess would be

  IT seems MENU_PLAY_HOLD triggers the Apple Remote into trying
  to make a pair.

> +// if system already in paired state, it will not pair the remote

This sentence contains no verb and is therefore hard to understand.

  If the system already is in paired state, it will not pair the remote.

> +// then will lost the remote bacause remote's internal id changed.

bEcause

This sentence contains no subject and "will lost" is a mix of past and
future.  I have several guesses about what you could be trying to say,
but they contradict each other :)  My best guess is:

  We will then lose control of the remote because the remote's
  internal ID changes.

> +    // TODO: multi controls could be found, we only use the first usable one

multiple, like I said in my last mail.

> +    // has to add elements to the queue to make the queue work

Who has to add those elements?

> +int is_mplayer_front()

What do you mean by front?  Foreground?

> +    if (GetFrontProcess(&frProc) == noErr

Google tells me that Apple indeed uses this as a synonym for foreground.
Oh well ...

> +        // shorten cookie sequence by remove cookie value 5 and 18
> +        // bacause 5 always follows 6, 18 always follows 19(on leopard).

bEcause

  Shorten cookie sequence by removing the cookies with value 5 and 18
  because 5 always follows 6 (on tiger), 18 always follows 19 (on leopard).

> +        // as least 4 cookies make up a valid sequence.

4 cookies are needed to make up a valid sequence.

> +    // current front, if closed, re-open the device to make sure
> +    // not affected by other apps or system use apple remote

see above

I hope you don't mind my grammar lessons :)  And don't worry, your patch
is as good as applied.

Diego