WiiRemote EventClient disconnect problems

[doesntcount]

I built the WiiRemote EventClient to try it out. When I run it, it connects with xbmc (xbmc makes some noises) then I put the WiiRemote in discovery mode which results in stdout output:

Sucessfully connected a WiiRemote
Lost connection to the WiiRemoteà¥`
Sucessfully disconnected a WiiRemote
Sucessfully connected a WiiRemoteremaining
Lost connection to the WiiRemoteà¥`
Sucessfully disconnected a WiiRemote
Sucessfully connected a WiiRemoteremaining
Lost connection to the WiiRemoteà¥`
Sucessfully disconnected a WiiRemote
Error setting WiiRemote report modete
Sucessfully connected a WiiRemoteremaining
Lost connection to the WiiRemoteà¥`

And it works for a couple seconds, but then it disconnects. Then it reconnects, works for a bit, then disconnects again. After a few repeats of that it finally stops reconnecting and it doesn't work.

Even when it does work, the repeat is much too fast such that when I press the dpad to navigate the menu, it flies through the selections. Hopefully there's a way to fix that as well.

Here's my xbmc.log: http://pastebin.ca/1209923

SVN: 15668
Linux 2.6.24-gentoo-r7 x86_64

Thanks for the help. Let me know if there's any more debugging I can do or more info to provide.

[theuni]

I was suffering from the same problem, also running gentoo x64. Solved it by commenting the following line in ~/XBMC/tools/EventClients/Clients/WiiRemote/WiiRemote.h and recompiling

#define CWIID_OLD

I was also getting extreme sensitivity in keypresses, solved by simply running with the --disable-mouseemulation switch.

I'll ask a dev, seems this should be commented by default by now.

TheUni

[topfs2]

I was suffering from the same problem, also running gentoo x64. Solved it by commenting the following line in ~/XBMC/tools/EventClients/Clients/WiiRemote/WiiRemote.h and recompiling

#define CWIID_OLD

I was also getting extreme sensitivity in keypresses, solved by simply running with the --disable-mouseemulation switch.

I'll ask a dev, seems this should be commented by default by now.

TheUni

Yeah we probably should. Just that gutsy needs CWIID_OLD and I havent had problems in hardy so I kept it. Ill revise if we should make the switch to the new lib.

You can also use the deadzone switch to get it less sensative.

[theuni]

I get a feeling that it's not the sensitivity that's a problem, but a bug in the client/cwiid library. when the mousepointer is enabled, there seems to be no pause between button events. For example, go to the home screen (In PM3.HD) and hold up/down on the wiimote. When enabled, the menu items cycle about 30/sec. Far too fast to control. Also, pressing 'A' once will take you into a section, start playing a movie, and pause/play a few times.. all with one quick keypress. When --disable-mouseemulation is set, everything works as expected.

I've been messing with the client to try to get the pitch/roll working as seen here: http://xbmc.org/trac/ticket/4264

The same thing happens here. I've pinned it down to these functions:

ToggleBit(m_rptMode, CWIID_RPT_IR);
ToggleBit(m_rptMode, CWIID_RPT_ACC);

If either of these are set (on a 64bit system only, i'm assuming) the repeat rate is screwed, though I can't seem to find the reason.

Edit-

From state.c (cwiid lib). Could the sizeofs explain why buttons work but acc/ir get messed up?

case CWIID_MESG_BTN:
wiimote->state.buttons = mesg->btn_mesg.buttons;
break;
case CWIID_MESG_ACC:
memcpy(wiimote->state.acc, mesg->acc_mesg.acc,
sizeof wiimote->state.acc);
break;
case CWIID_MESG_IR:
memcpy(wiimote->state.ir_src, mesg->ir_mesg.src,
sizeof wiimote->state.ir_src);
break;

[theuni]

Topfs2

I've written a new client based on WiiUse that is much simpler and seems to provide more functionality. All buttons already work as they do in the other, as well as pitch and roll. It's a bit rough and needs some error checking/handling, but seems to work well. All extensions work (i believe) even guitarhero control and wiifit board, and the project seems to be more active.

Would there be any interest in replacing the current eventclient with this one? It should work on all platforms and the lib could easily be included and compiled with the source, so no need to worry about different versions for different distros/platforms/arches.

TheUni

[topfs2]

If you send a patch and agree to opensource it I´d love to pop it in svn so we can have that instead!
Asumed that it works as this one, even in an unfinished state it would be good for the windows users and when the error checking and such is working well we could phase out the cwiid based one.

(if you were the one that did the pitch/roll patch Im sorry I havent added it yet, didnt want to patch WiiRemote until after gold, but thank you very much for the patch and Ill integrate it atlantis+1 )

Thx.

[theuni]

I'm not the one who submitted the patch, but that is what gave me the idea. Unfortunately, i could never get anything using CWiid to run correctly.

I'll clean up the code some and get you a working copy, I should have some more free time tomorrow. The lib should work fine in win, and most of the code i've taken from samples/other projects, so it shouldn't be a problem. Only thing I'm not sure about is the ugliness of windows + bluetooth. Since I don't have a windows box around, I may not be of much help there.

TheUni

[theuni]

Topfs2-


edit: removed old link. See attachment on http://xbmc.org/trac/ticket/5080

Buttons work, roll/pitch work reasonably well. hold B to activate. Mapped to buttons 33/34 for roll and 35/36 for pitch. Works well with controlling volume, that's about all I've tested.

No IR for now because I don't have an LED bar, will fix asap.

TheUni

[doesntcount]

Hey guys, I had this working great for a couple weeks, theuni's new WiiRemote event client was great. Then my new motherboard ended up being defective and i had to reinstall from scratch. I redownloaded from ticket 5080 but now it won't compile:


client.cpp: In member function 'void CWiiController::handleKeyPress()':
client.cpp:46: error: invalid conversion from 'int' to 'const char*'
client.cpp:46: error: initializing argument 1 of 'void CXBMCClient::SendButton(const char*, const char*, short unsigned int, short unsigned int)'
client.cpp:50: error: invalid conversion from 'int' to 'const char*'
client.cpp:50: error: initializing argument 1 of 'void CXBMCClient::SendButton(const char*, const char*, short unsigned int, short unsigned int)'


svn shows that the api hasn't changed since 9/29 which was long before theuni's code was uploaded. That seems to indicate i've botched something up as it used to work before and the only thing that's changed is that i've reinstalled my system. Anybody have any clues? I'm stumped.

Also, when will this client make it into svn? If testers are needed to make this happen, count me in.

Thanks for the help.

[theuni]

I believe it's due to a bug in the .h (either that or i'm using it incorrectly with great success :)

You need to change a line in XBMC/tools/EventClients/lib/c++/xbmcclient.h

line 760 or so should be

void SendButton(unsigned short Button, const char *DeviceMap, unsigned short Flags, unsigned short Amount = 0)

[doesntcount]

Yup, that did it. Thanks. Missed that instruction in the README (I did read it, honest). No other code in the EventClients directory in svn seem to use the SendButton method, so should it not be safe to just change the xbmcclient header?

[theuni]

Missed that instruction in the README (I did read it, honest)
No prob, it was wrong in the readme anyway. It's updated now.

No other code in the EventClients directory in svn seem to use the SendButton method, so should it not be safe to just change the xbmcclient header?
Really not sure tbh. The function is overloaded, 2 ways to call it. I assume that either other clients call it the other way or that I am using it wrong, though I can't make sense of how it would be used as-is.

My client seems to be the only one that uses the CXBMCClient class for some reason (way easier, it must've been added after the other clients were written?) so it should be the only one affected by the change to the .h.

I would appreciate it if Topfs2 would shed some light here.

TheUni

[doesntcount]

grep -Ri sendbutton * | grep -v xbmcclient | grep -vi wii

returns absolutely nothing, so I'm pretty sure your wiiremote client is the only one using it. Hopefully topfs has some thoughts.

Also, can you post your Keymap.xml? I'd like to try out the roll stuff to control volume and perhaps even video seeking and I'm not sure what to add to Keymap.xml to make that happen.

Thanks.

[theuni]

if you're using the default keymap.xml, just find the first instance of "WiiRemote" and change:

<button id="7">VolumeDown</button>
<button id="8">XBMC.ActivateWindow(Home)</button>
<button id="9">VolumeUp</button>
to

<button id="33">VolumeDown</button>
<button id="8">XBMC.ActivateWindow(Home)</button>
<button id="34">VolumeUp</button>

That's all that I've found so far that works well.

Hold B for a sec, then roll.

New FF/RW functions would have to be implemented because afiak, all you can do is change the playback speed (2x,4x,8x,etc.), not an actual "analog seek". Feel free to play around though, I could definitely be wrong.

Pitch and Yaw can also be enabled, though in my testing, they weren't reliable enough to use. You can enable pitch by uncommenting lines 72-75. Button id's are 35 and 36. The logic is VERY bad and needs to be researched lots more, which is why it's disabled atm.

I've also thought about implementing a "wrist flick", though I can't think of how it would be useful in XBMC other than, say, moving left/right in coverflow views. That would get tiresome very quickly though.

TheUni

[doesntcount]

Thanks!

Ya, i saw the commented out pitch code and curiosity got me to uncomment it. I'll play around.

Also, for FF/RW i was hoping that there was similar functionality as with the original xbmc for xbox where the right analog thumb stick on the xbox controller could be used to slide the seek bar anywhere in the file and when you let go, it went to that part of the file. It's a superior feature imo, and I think it would work really well with the wiimote pitch control.

[doesntcount]

Awesome, got the volume control working.

One thing i'm noticing though, the calculations are absolute, not relative. And by that I mean, it doesn't calculate my roll relative to where i started presing B, but rather it's always relative to the flat/unrotated position. Do you know what I mean? Sorry if i'm explaining it poorly.

It wouldn't be too difficult to add a way to do these calculations differently. The first time we realize the HOLD_BUTTON_TIMEOUT threshold has been crossed, you could get the current roll value, then subsequent entries to handleACC would calculate the difference between the current roll value and the original roll value and pass that onto the EventClient.

Thoughts? I'll try coding this up to if it works as well as I think it will.

[doesntcount]

Looks like it's not as easy as it sounds. I added what i thought would be the code to handle this. Looks like this currently:

if ((controller.m_buttonDownTime > HOLD_BUTTON_TIMEOUT) && controller.m_holdableHeld)
{
EnableMotionSensing(wm);
if (!controller.m_newMotion)
{
printf("New Motion!!!!!\n");
controller.m_newMotion = true;
controller.m_startRoll = wm->orient.roll;
controller.m_startPitch = wm->orient.pitch;
printf("NewStartRoll: %f\n", controller.m_startRoll);
}
else
{
float currentRoll;// = wm->orient.roll;
controller.m_roll = (currentRoll = wm->orient.roll) - controller.m_startRoll;
controller.m_pitch = wm->orient.pitch - controller.m_startPitch;
printf("current: %f, start: %f, diff: %f\n",
currentRoll, controller.m_startRoll, controller.m_roll);
controller.handleACC();
}
}


But when i test it, the starting value isn't usually very accurate. Might be that you want to wait a couple of ticks before settling on a start value? But how many ticks is a tough question to answer.

Other than that, the logic seems pretty sane. About a quarter of the time, the start value does end up being accurate, and in those cases, it works like a charm. I'll keep fiddling.

[theuni]

See updated client @ Trac ticket. Works MUCH better, thanks for the idea.

Now needs to keep a ubound and lbound for how high/low the roll gets, so that it's activated at ubound +/- 30 rather than just +/-30. Hard to explain, but play around some and I think you'll see what i mean.

I'll work that out next.

TheUni

[dteirney]

I've just got the Wii remote working with XBMC. Seems to work well so far - great not having to point the remote at a receiver for it to work.

Once I get video playback working decently due to ATI driver issues I'd be keen to try some of these motion related changes that have been discussed. The old XBox seems like a dream setup compared to Linux at the moment.

What would the easiest way to do that? Will the wiiremote Linux packages in the PPA be updated, or will I have to revert to compiling code?

Cheers,
David

[theuni]

For now you'll have to compile the code, since it's still in development. Top2fs mentioned that maybe at some point it will replace the current client available from apt, but it will be after gold release for sure.

TheUni

[dteirney]

Finally got XBMC under Linux working and have the Wii Remote all hooked in.

Using the standard WiiRemote Keymapping that ships with XBMC, while playing a video the Up Arrow pauses, and the Down Arrow stops. We were using these buttons on the original XBox remote for Big Skip Forward and Big Skip Backward (timing configured for them to be 6 commercial breaks). They were really handy, and the WAF will decrease if I don't keep them.

What key mappings are other people using? Not sure how best to access:
Big Skip Forward - would prefer the Up Arrow (as opposed to Pause)
Big Skip Backward - would prefer the Down Arrow (as opposed to Stop)
Fast Forward - this may be able to be done using "Hold down B and then rotate right" based on discussion here. Analog seek might work quite well. Not sure how that was thinking of being implemented.
Rewind - this may be able to be done using "Hold Down B and then rotate left" as above
Pause - pretty easy to get to by using A and then navigating. Would prefer this was a single button press though. Probably fine though.
Stop - also pretty easy to get to by using A then navigating. XBMC seems to remember the option that was last chosen, so if that was stop it's only two button presses. (Actually it only remembers it sometimes, seems to default to Audio Settings other times. Perhaps just the Mediastream skin does this though?)

The 1 and 2 buttons open things we'd hardly ever use while watching videos, so wondered if these could be used differently.

What keymappings or behaviors are other people using that seem to work quite well?

[dteirney]

I had a spin through the default Keymap.xml. There are a few changes that I will make to the default WiiRemote settings so I can more easily remember (and explain) the general functions for the buttons, e.g.

1 for "Info/ContextMenu" type stuff
2 for "Delete/Backspace/Stop" type stuff
B for "Back/Close" type stuff

Where do I get the latest code that includes the button definitions for roll and pitch mentioned in this thread? The downloads on the trac ticket (http://xbmc.org/trac/ticket/4264) seems to be from 5 months ago. Really want to try the Analog Fast Forward and Rewind.

Also, I noticed the the PS3 joystick entries in the Keymap.xml had <axis> tags in them that seemed to be for a similar thing to the accelerometer stuff mentioned in this thread. Do those <axis> entries in XBMC behave differently to a button that is triggered by an acceleration in a direction on the Wii remote?

Great work making the changes to get the Wii to work as good as it can. Bluetooth remote is fantastic, and the Wii remote has just enough buttons to cover most everything we seem to need.

Now that Atlantis final has been released, maybe this can get into the main trunk.

[theuni]

The latest code is here, though it's still a work in progress:

http://xbmc.org/trac/ticket/5080

I've also got tilt working, though it's not yet reliable enough to use. I've tried to come up with a good way to use it, though I can't find a good case for it. PM me if you'd like to try it.

TheUni

[dteirney]

For anyone else trying to get this working here are some more detailed instructions (I haven't compiled C stuff for ages so it's a reminder for me when I do it on the HTPC).

Download, Make and Install the WiiUse libraries

Install the development libraries for bluetooth. sudo apt-get install libbluetooth-dev
Download wiiuse from SourceForge. http://sourceforge.net/project/showfiles.php?group_id=187194
Extract the wiiuse files to your machine and change to that directory. Read the README file - the next two steps are contained in the README.
Make the wiiuse library make wiiuse
Install the wiiuse library. sudo is needed because some of the libraries are put into locations only root can write to. sudo make install


Download and Compile the WiiRemoteNew code

Download latest source from http://xbmc.org/trac/ticket/5080
Extract WiiRemoteNew directory to XBMC/tools/EventClients/Clients/WiiRemoteNew and change to that directory.
Read the README.
Fix the compile error as per the README
Compile using g++ -lwiiuse client.cpp -o xbmc-wiiremote
Try it out by running it ./xbmc-wiiremote