Ensure we compile with C++11

[feilen]

This is required for compiling with the latest GCC on Linux.

It compiles correctly, but doesn't show anything in osvr_print_tree or OSVRTrackerView if I load up the provided config, so I'm not completely certain if it works correctly. Can anyone else confirm? Has someone tried it lately?

[phiresky]

I can confirm it does not detect the controller as is under Arch Linux 64bit.

From the leap documentation:

The connection process is asynchronous, so you can’t create the Controller in one line and expect to get data in the next line. You have to wait for the connection to complete. But for how long? (source)

The following (stupid) workaround fixes it:

Subject: [PATCH] workaround for not finding the controller

---
 HardwareDetection.cpp | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/HardwareDetection.cpp b/HardwareDetection.cpp
index 8b3bc2e..a65e4b1 100644
--- a/HardwareDetection.cpp
+++ b/HardwareDetection.cpp
@@ -1,6 +1,9 @@
 #include "HardwareDetection.h"
 #include "ControllerDevice.h"

+#include <chrono>
+#include <thread>
+
 using namespace LeapOsvr;


@@ -14,6 +17,8 @@ HardwareDetection::HardwareDetection() : mFound(false) {
 OSVR_ReturnCode HardwareDetection::operator()(OSVR_PluginRegContext pContext) {
    Leap::Controller controller;

+   std::this_thread::sleep_for(std::chrono::duration<int, std::milli>(100));
+
    if ( !controller.isConnected() ) {
        mFound = false;
        return OSVR_RETURN_FAILURE;
-- 
2.8.0

It should probably be fixed by using the callbacks mentioned in https://developer.leapmotion.com/documentation/cpp/devguide/Sample_Tutorial.html

[feilen]

Ooh, excellent find! I think I might be able to make the callback based fix
later on. In the mean time I'll update my repo so everyone on Arch can get
it working using your hack. Nice work!
On Apr 20, 2016 14:20, "phiresky" notifications@github.com wrote:

I can confirm it does not detect the controller as is under Arch Linux
64bit.

From the leap documentation:

The connection process is asynchronous, so you can’t create the Controller
in one line and expect to get data in the next line. You have to wait for
the connection to complete. But for how long? (source)
https://developer.leapmotion.com/documentation/cpp/devguide/Sample_Tutorial.html

The following (stupid) workaround fixes it:

Subject: [PATCH] workaround for not finding the controller

HardwareDetection.cpp | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/HardwareDetection.cpp b/HardwareDetection.cpp
index 8b3bc2e..a65e4b1 100644--- a/HardwareDetection.cpp+++ b/HardwareDetection.cpp@@ -1,6 +1,9 @@
#include "HardwareDetection.h"
#include "ControllerDevice.h"
+#include +#include +
using namespace LeapOsvr;

@@ -14,6 +17,8 @@ HardwareDetection::HardwareDetection() : mFound(false) {
OSVR_ReturnCode HardwareDetection::operator()(OSVR_PluginRegContext pContext) {
Leap::Controller controller;

• std::this_thread::sleep_for(std::chrono::duration<int, std::milli>(100));+
  if ( !controller.isConnected() ) {
  mFound = false;
  return OSVR_RETURN_FAILURE;--
  2.8.0

It should probably be fixed by using the callbacks mentioned in
https://developer.leapmotion.com/documentation/cpp/devguide/Sample_Tutorial.html

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#19 (comment)

[phiresky]

See also #13 (comment)

Looks like the whole detection process should be reworked.

[phiresky]

Just as a note: use this command to test if all fingers are detected correctly:

OSVRTrackerView $(osvr_print_tree|grep -o " /arms/.*/hand/.*" | sed 's/ /--pose /'|tr '\n' ' ')

(spiky hands) http://i.imgur.com/O2QIrQV.gifv

[feilen]

Working great for me. I'll see if I can't do something about the proper callbacks this weekend, although it seems there's already some attention to this issue elsewhere.

[feilen]

I'm thinking a way of doing this neatly would be to keep track of Leap
controllers and connections somewhere inside the plugin, storing them
whenever an asynchronous call comes in to do so, and handing them up to the
Core when the HardwareDetection callback is called. That way it would still
do its asynchronous thing, in a way that meshes at least somewhat okay with
how the OSVR server does things. Any thoughts?

On Wed, Apr 20, 2016 at 2:52 PM, phiresky notifications@github.com wrote:

Just as a note: use this command to test if all fingers are detected
correctly:

OSVRTrackerView $(osvr_print_tree|grep -o " /arms/./hand/." | sed 's/
/--pose /'|tr '\n' ' ')

(spiky hands) http://i.imgur.com/O2QIrQV.gifv

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#19 (comment)

[phiresky]

As far as I can tell there isn't really an optimal method. Leap only has a callback for connected, so you would still need to check .isConnected in hardwareDetect even after receiving the connected callback from leap. This assumes state (the Leap::Controller instance) can be kept somewhere when HardwareDetect returns FAILED (not sure if the plugin stays in memory then?) and also that the callback works because that's called from a different thread.

[feilen]

Ah, didn't quite work out anyway. Tried making a static Leap::Controller
and it mysteriously won't work.

The mFound boolean is particularly mysterious, by all means it seems to be
just a bit of leftovers from the example tutorial that shouldn't have any
effect, but if I remove it it fails to work at all.

On Thu, Apr 21, 2016 at 5:05 PM, phiresky notifications@github.com wrote:

As far as I can tell there isn't really an optimal method. Leap only has a
callback for connected, so you would still need to check .isConnected in
hardwareDetect even after receiving the connected callback from leap. This
assumes state (the Leap::Controller instance) can be kept somewhere when
HardwareDetect returns FAILED (not sure if the plugin stays in memory
then?) and also that the callback works because that's called from a
different thread.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#19 (comment)