[MPlayer-dev-eng] [PATCH] Apple Remote support
Ulion
ulion2002 at gmail.com
Tue Aug 14 10:43:38 CEST 2007
2007/8/14, Diego Biurrun <diego at biurrun.de>:
> On Mon, Aug 13, 2007 at 09:12:22PM +0800, Ulion wrote:
> > 2007/8/13, Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>:
> > > Hello,
> > > On Mon, Aug 13, 2007 at 03:38:41PM +0800, Ulion wrote:
> > > > 2007/8/13, Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>:
> > > > >
> > > > > > + cc_check -framework IOKit && tmp_run && _apple_remote=yes
> > > > >
> > > > > configure checks should not execute anything unless absolutely
> > > > > necessary.
> > > > I think this run check is necessary when apple-remote support is setted 'auto'.
> > >
> > > I do not really like it because I think it causes problems for everyone
> > > compiling for a different machine.
> > > But configure is Diego's domain and if he is fine with it I won't
> > > complain.
> > > But the function you use to test is a copy-and-paste of the FindHIDDevices
> > > function you updated, so it would be good to update this as well so they
> > > match again.
> > for machine has Apple Remote support it run return 0 and _apple_remote
> > setted to yes.
> > for machine not support Apple Remote, it run return non-zero,
> > _apple_remote setted to no.
> > this is exactly what the 'auto' mean, check whether current machine
> > support Apple Remote.
>
> There is a difference between a machine that can compile Apple Remote
> support and another one that has Apple Remote support and can actually
> use it. What happens if you compile on a machine without a remote for
> other Apple machines that do have remotes?
when compile on a machine without support for Apple Remote, compiled
mplayer will not support Apple Remote on any machines when the default
configure action set enable-apple-remote as 'auto'. if need the
feature compiled-in even compiling machine not support the remote,
explicit set --enable-apple-remote as configure paramter, and if the
machine has headers need to compile file ar.c, the feature can be
compiled in and running correctly on any osx machine support the
remote. this is exactly behavior we expected.
>
> > --- input/input.c (revision 24050)
> > +++ input/input.c (working copy)
> > --- input/ar.c (revision 0)
> > +++ input/ar.c (revision 0)
> > @@ -0,0 +1,411 @@
> > +
> > + // TODO: multi controls could be found, we only use the first usable one
>
> multiple
>
> > + // TODO: cooperate correctly with other apps using Remote Control
> > + // Wrapper 2.0 above, after open exclusive mode failed, try to send
> > + // a request to other apps and wait for a moment someone release it.
>
> Using a software called "Remote Control Wrapper" at version 2.0 or
> above?
>
> I think what you want to say in the second part (which should be a
> separate sentence) is
>
> If opening the remote control in exclusive mode failed, try to send a
> request to other apps and wait a moment for it to be released.
>
> Did I understand correctly?
sorry for this comment, removed, maybe added in future.
>
> > + /* depth: maximum number of elements in queue before oldest elements
> > + in queue begin to be lost. */
>
> Number of elements the queue can hold before the oldest elements get
> dropped.
>
> Is that really a queue? A queue should drop the newest, not the oldest
> elements.
a size-limited queue can have different behavior, when queue is full,
it can reject new element as you said, or drop the oldest one to keep
the new element.
>
> > + // FIXME: should we necessary to add these cookies into the queue,
> > + // or just wait the queue give us new events?
>
> I cannot parse this one.
after a real test, I found the remote will not work without these two
lines that add cookies to queue although I don't know why. so the
comment will be changed.
>
> > + // not used any more.
>
> anymore
fixe.
>
> > + // not useful any more.
>
> ditto
fixe.
>
> > + // if mplayer running in slave mode, also check parent process
>
> if MPlayer is running
>
> > + // skip 5 to get different sum cookie from each input from Apple Remote
>
> Skip 5 cookies to get a cookie with a different sum from each input of
> the Apple Remote.
>
> Is that what you were trying to say?
this is a problem, init codes was not written by me, this comment was
added because Reimar Döffinger asked, after a research, I found it
probably is for shorten cookie sequence. this is current cookie
sequences:
{ 25, AR_PREV_HOLD }, // 14+6+3+2
{ 26, AR_NEXT_HOLD }, // 14+6+4+2
{ 40, AR_MENU_HOLD }, // 14+6+14+6
{ 43, AR_VUP }, // 14+12+11+6
{ 44, AR_VDOWN }, // 14+13+11+6
{ 54, AR_MENU }, // 14+7+6+14+7+6
{ 56, AR_PLAY }, // 14+8+6+14+8+6
{ 58, AR_NEXT }, // 14+9+6+14+9+6
{ 60, AR_PREV }, // 14+10+6+14+10+6
{ 76, AR_PLAY_HOLD }, // 18+14+6+18+14+6
comment at each line end is cookie sequence of certain input. to
identify a input. original cookie sequences also include cookie value
5, they were:
{ 30, AR_PREV_HOLD }, // 14+6+5+3+2
{ 31, AR_NEXT_HOLD }, // 14+6+5+4+2
{ 48, AR_VUP }, // 14+12+11+6+5
{ 49, AR_VDOWN }, // 14+13+11+6+5
{ 50, AR_MENU_HOLD }, // 14+6+5+14+6+5
{ 64, AR_MENU }, // 14+7+6+5+14+7+6+5
{ 66, AR_PLAY }, // 14+8+6+5+14+8+6+5
{ 68, AR_NEXT }, // 14+9+6+5+14+9+6+5
{ 70, AR_PREV }, // 14+10+6+5+14+10+6+5
{ 86, AR_PLAY_HOLD }, // 18+14+6+5+18+14+6+5
you can notice each cookie 5 is after each cookie value 6, here remove
cookie 5 was probably just for shorten the cookie queue.
to identify each input accurately, it's better use the squence instead
of use the cookie sum.
so I modifed the code, give a upgraded identity for remote input.
new method also can identity from continual input sequences, and still
use the shortened version of sequences.
same thing also happens on the cookie value 18 and 19 on leopard, I
removed cookie 18 to shorten the sequence too.
>
> > + // 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.
>
> > + // TODO: same as first time open the device, try cooperate with
> > + // other apps to request exculsive open.
>
> excLUsive
removed, maybe added in the future.
>
> maybe better:
>
> TODO: Try to cooperate with other apps to exclusively open the device,
> just like on initial opening.
>
>
> Thanks for bearing with us through all those review rounds. Since
> Reimar seemed reasonably happy with the code I will apply it after we
> address the minor issues above.
>
> Diego
thanks, some code updated mainly the cookie squence identity part,
here's the new version of patch
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?
--
Ulion
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apple_remote_seq_identify.patch
Type: application/octet-stream
Size: 31220 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070814/1426589e/attachment.obj>
More information about the MPlayer-dev-eng
mailing list