Re: [Gizmod-devel] First Questions

[Tim B. <tim...@gm...>]

Hey Sean,

> I spent the last couple of days getting gizmod to a place where it is
> useable with my system, which has really helped me understand the
> basic framework of this tool. I have mostly focused on the python
> scripts, but I have taken a few ganders at the C++ code and most of
> it makes some sense, enough that I think I can manage with the file
> loading items I mentioned earlier.

Excellent!  Good to hear.  If you have any questions while look through
the source or the scripts, don't hesitate to ask.  I know looking at
someone else's code isn't always easy.

> first up, does whoever writes the ATIX10 scripts actually HAVE an ATI
> remote? I have to ask, because the scripts in v3.3 are seriously
> broken for the mouse :(

Hahah... sorry about this.  The story goes like this: when I originally
wrote Gizmod I had an ATIX10, but by the time it came to writing Gizmod
3, I had gotten rid of it in favor of a different remote.  I got word
from a few users that they still really wanted ATIX10 support so I said
"Okay I'll put it in, but I have no way of testing it, you guys will
have to be my testers!"  So we emailed back and forth a few times until
they seemed to agree it was working.

Obviously this isn't good enough, so I appreciate your effort in trying
to fix up the ATIX10 support!

> I'm attaching a diff for 499-ATIX10-Default.py, which does a handful
> of things.
> 
> 1) it fixes an error with the right and left mouse click (it
> previously made a call to a GizmoKey that didn't exist, which then
> threw an exception)
> 2) calls xine with the appropriate DVD flags when the KEY_DVD is
> pressed
> 3) presses "ALT+F4" when KEY_POWER is pressed, since my previous setup
> used the power button as a generic window closer
> 4) calls a special Konqueror window when you press KEY_TV (I wouldn't
> integrate this into the official version if I were you... since most
> folks won't be doing what I'm doing)
> 5) calls amarok when KEY_A is pressed on the remote

Great, thanks for the patch!  I've accepted your changes (minus part 4).
 These may need some cleanup in the future, as what I like to do is put
all the button presses relating to an app in an application specific
script (including the launchers), but these are simple enough that I
don't see a problem with it.

> Second, the mouse device on the remote, while gizmod is running, is
> not so good. First, it won't accept up/down and left/right inputs at
> the same time, thus the mouse only moves up/down OR left/right, no
> diagonal. Second, it moves in these weird jerky motions. Any ideas
> as to where I might look to start fixing that behavior? I was
> thinking it might make most sense to figure out if the mouse
> behaviors can just pass through entirely and not be interpreted
> through gizmod? I don't know.

Yes I remember this, and actually these are almost entirely
uninterpreted, this is actually how the device generates events.  If
you've used the device in Windows you'll see some post-processing must
be done.  I just never had time to implement this, and now that I don't
have one any more I can't test very well.

My thoughts are this:

Instead of passing the events straight through as they are, detect when
a press of the mouse movement pad starts, and have an 1x8 array that
keeps track of the states.  Then constantly move the mouse in the
directions specified.  Speed should increase slowly until they let go of
the pad maybe?

Does this make any sense?

> Third, there seems to be some sore to throttle code that makes it so a
> button press is only interpreted once or something, I'm not sure. 
> What I do know is that using the direction arrows is awfully flaky.
> Like if I'm scrolling through a list of files in Konqueror by
> pressing and holding KEY_DOWN, it works great at first... then slows
> down, then comes to a total stop. After I a few seconds of waiting I
> can do some more but it'll stop again soon thereafter. Same behavior
> when using the arrow directions in mplayer to move around in the
> video stream.

Interesting.  Agreed this is no good! :).

> Is that something in the code or is my remote starting to go wonky?

It may be the routine that is attempting to remove super fast button
presses.  The ATIX10 is actually very touchy hardware, and produces all
sorts of spurious button presses.  For example, when you press a button
the hardware could send out anywhere from 1-10 super fast button press
events.

There is some code I put in that tries to get around this, maybe it's
causing the issue.

See GizmoATIX10.cpp, it calls "setMinimumTimeBetweenEvents".  You can
actually call this function from Python if you want to play with it and
see if you can figure out if this is causing the issue.  First you may
want to remove it altogether (or set the value to 0).

> Well, I think that's enough for the moment (I will have some questions
> about the MythTV stuff, but it'll wait until I do some more
> investigation). I'm excited to start getting this tuned properly... 
> I think there is some really amazing potential here.

Again, thanks for all your help with this.  Much appreciated!  If you
end up wanting to get into the code more I'll have no issues giving you
developer SVN access.

Tim.