gizmod-devel — Gizmo Daemon Development Mailing List

[Gizmod-devel] Compiling on recent distributions

[Michael H. <ma...@co...>]

There are three issues WRT compiling "gizmod" on Fedora 9 and probably 
other recent distributions:

1. The file "gizmod/cmake/Modules/DefineCompilerFlags.cmake" sets the 
"-Werror" compiler flag which causes warnings to be treated as errors 
and terminate the build.  Unfortunately, the newer C++ compilers 
generate lots of warnings with the current code and at least one comes 
from an included system file which you probably do not want to change. 
Clearing the warnings would be a noble enterprise but the flag needs to 
be removed for the moment.

2. The newer compiler libraries define the "INT_MAX" constant in the 
"limits.h" header which is not included in the "libGizmod/Alsa.cpp" or 
"libGizmod/Alsa.hpp" files.  The attached "Alsa.cpp.patch" adds it but I 
do not know if this will be backwards compatible.

3. In the Boost 1.34 library, the function "for_each()" no longer 
appears to be part of the "std" namespace.  In the file "libH/Util.hpp", 
this reference has to be removed and the header 
"<boost/mpl/for_each.hpp>" included explicitly. The attached 
"Util.hpp.patch" makes these changes but it is probably not backwards 
compatible and there may be a better way to handle this.

It does appear to run properly on Fedora 9 with these changes.

The ".patch" files are "diff -c ..." output.

Mike Hughes

Re: [Gizmod-devel] First Questions

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

>> 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.
> 
> Thanks, I appreciate the offer, but let's see if I can actually do 
> anything good first :)  I'm in the process of moving from one side of 
> my town to the other, but once that is over I'm going to be looking 
> for a hobby to occupy a few weeks I've got to burn.  This project 
> seems like a GREAT one.
> 
> I'll be in touch again once I've got something to show or more 
> questions.

No problem, sounds good.  Like I said, if you do end up looking at the
code, and have any questions, don't hesitate to ask!

Good luck with the move!

Tim.

Re: [Gizmod-devel] First Questions

[Sean K. <ske...@gm...>]

On Monday 13 August 2007 04:26:43 am Tim Burrell wrote:
> 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.

Thanks, I appreciate the offer, but let's see if I can actually do=20
anything good first :)  I'm in the process of moving from one side of=20
my town to the other, but once that is over I'm going to be looking=20
for a hobby to occupy a few weeks I've got to burn.  This project=20
seems like a GREAT one.

I'll be in touch again once I've got something to show or more=20
questions.

=2DSean

=2D-=20
Sean Kellogg
e: ske...@gm...
w: http://blog.probonogeek.org/

So, let go
=A0...Jump in
=A0 ...Oh well, what you waiting for?
=A0 =A0...it's all right
=A0 =A0 ...'Cause there's beauty in the breakdown

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.

[Gizmod-devel] Hey all

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

Testing the list!

[Gizmod-devel] First Questions

[Sean K. <ske...@gm...>]

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

But I do have a few questions that I hope you can answer for me.

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

I'm attaching a diff for 499-ATIX10-Default.py, which does a handful=20
of things.

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

=46eel free to take from that what you want :)

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

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

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

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

=2DSean

=2D-=20
Sean Kellogg
e: ske...@gm...
w: http://blog.probonogeek.org/

So, let go
=C2=A0...Jump in
=C2=A0 ...Oh well, what you waiting for?
=C2=A0 =C2=A0...it's all right
=C2=A0 =C2=A0 ...'Cause there's beauty in the breakdown

[Gizmod-devel] Testing, Testing... 1... 2... 3...

[Sean K. <ske...@gm...>]

April is the cruelest month...
April is the cruelest month...

=2DSean

=2D-=20
Sean Kellogg
e: ske...@gm...
w: http://blog.probonogeek.org/

So, let go
=A0...Jump in
=A0 ...Oh well, what you waiting for?
=A0 =A0...it's all right
=A0 =A0 ...'Cause there's beauty in the breakdown