Mouse input does not work.

[bakercp]

Currently ofAppRaspberryPi window does not support mouse input.

[bakercp]

Mouse examples
e.g https://github.com/raspberrypi/firmware/blob/master/opt/vc/src/hello_pi/hello_triangle2/triangle2.c
e.g. https://github.com/chriscamacho/gles2framework/blob/master/src/input.c

[arturoc]

was looking through the examples and that code is also plain linux nothing particular for the rpi so it can be integrated in the ofAppEGLWindow too

[bakercp]

Almost working flawlessly. Two issues @arturoc

1. The mouse cursor is subject to the shader :) (this is seen in raspberrypi_ES2ShaderExample)
2. For some reason, when using the ofGLES2Render, when entering the EGLWindow's infiniteLoop, ofThread throws the error:

[Thread 1:warning] cannot start, thread already running

A "fix" is to remove the return function in ofThread here:

void ofThread::startThread(bool blocking, bool verbose){
    if(thread.isRunning()){ 
        ofLogWarning(thread.name()) << "cannot start, thread already running";
        //return; // don't return here and the mouse works just fine. 
    } 

So, basically, threadRunningis getting set to true and the only way I can see that happening is b/c startThead is called somewhere ... I can't figure out where and why it only happens when using the ofGLES2Renderer

[arturoc]

On 11/28/2012 12:43 AM, Christopher Baker wrote:

Almost working flawlessly. Two issues @arturoc https://github.com/arturoc

1. The mouse cursor is subject to the shader :) (this is seen in
   raspberrypi_ES2ShaderExample)

:) yes, i've fixed the custom shaders so the default shader is set when
end is called, check the shaderExample in examples/gl that should work
ok now

1. For some reason, when using the ofGLES2Render, when entering the
   EGLWindow's infiniteLoop, ofThread throws the error:

this is super weird, i'm not getting it at all, and startThread is
called only once, it seems more some kind of memory corruption or
something like that, where thread isRunning is returning true for some
reason even if it's not really running. it's also weird that you don't
have the thread priority methods, probably you have a different version
of the poco library to that in the headers and that's making the threads
go crazy, i'm not sure what version we are using in the core, the last i
remember compiling is 1.4.3 but it's weird that you don't have the
priority functions in 1.4.4 and i do, the last version seems to be 1.4.5
where those functions exist too

a

|[Thread 1:warning] cannot start, thread already running
|

A "fix" is to remove the return function in ofThread here:

|void ofThread::startThread(bool blocking, bool verbose){
if(thread.isRunning()){
ofLogWarning(thread.name()) << "cannot start, thread already running";
//return; // don't return here and the mouse works just fine.
}
|

So, basically, |threadRunning|is getting set to |true| and the only way
I can see that happening is b/c |startThead| is called somewhere ... I
can't figure out where and why it only happens when using the
|ofGLES2Renderer|

—
Reply to this email directly or view it on GitHub
#2 (comment).

[bakercp]

Great on the mouse texture shader interaction.

Yes, I'll bet that my armv6l poco libs are not matched to the header versions. Is there any easy way to check the header versions? Or should we upgrade to poco 1.4.5 across the board?

[bakercp]

@arturoc I tested the new shaderExample and it works great! The shader is not applied to the mouse texture.

The apps/devApps/raspberrypi_ES2ShaderExample/ examle does apply the shader to the mouse texture. I believe this is because that example is replacing the default shaders. Is that correct? And is this expected behavior? Or should we also figure out a way to never apply any shaders to the mouse tex?

This is looking great! Nice work!

[arturoc]

i think it is ok if the default shader applies to the mouse texture. also most examples shouldn't pass a default shader but use a custom one inside the app, the iphone example was setup like that because there was a problem with the custom shaders but it's fixed now.

[arturoc]

about poco, i've been looking for a way to check the version but had no luck, i was thinking that we should try to remove as much libraries as possible and use the system ones, even for poco and opencv unless there's some major incompatibility, that way we will be able to give support for every device

also we could have libraries like tess2 which are just a couple of files as source directly and use a mechanism in the makefiles similar to that we have for addons so if there's an src folder it is compiled with the OF library

[bakercp]

I agree on both accounts. I'll modify the make files to compile core lib sources.

I'll also get RPI running with system poco via apt-get install libpoco-dev.

[bakercp]

Also .. just noticed that the current raspberry pi Poco repo is running poco 1.3.* I don't think that thread priority stuff was added until 1.4. Do you think poco 1.3 will be a problem? Are we relying on any other 1.4+ features (the current poco headers are 1.4.*).

[bakercp]

There are a lot of changes since 1.3 ...

https://raw.github.com/pocoproject/poco/poco-1.4.5/CHANGELOG

[danzeeeman]

So debian is infamous for defaulting apt-get to older versions. I wonder fi
we should update the sources config of apt-get to include the newer
versions.
On Nov 28, 2012 5:16 PM, "Christopher Baker" notifications@github.com
wrote:

Also .. just noticed that the current raspberry pi Poco repo is running
poco 1.3.* I don't think that thread priority stuff was added until 1.4. Do
you think poco 1.3 will be a problem? Are we relying on any other 1.4+
features (the current poco headers are 1.4.*).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-10825415.

[jvcleave]

you might be able to get it with an experimental repo
http://packages.debian.org/search?suite=experimental&arch=armhf&searchon=names&keywords=poco

[arturoc]

the problem with the experimental repo is that setting it up can be messy, we could get the packages we need from it and create an ubuntu ppa so we can have some newer versions for packages that are outdated like this although i'm not sure that ubuntu ppa wil support arm

[bakercp]

I think there is some poco thread stuff involved here -- see #62.

[bakercp]

This is resolved using the 1.3 debian system poco libs (and should be resolved with @artoroc's recompiled 1.4.3p1 poco libs).

[bakercp]

fixed with #63