[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://trac.xbmc.org/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://trac.xbmc.org/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:

Code:

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

Code:

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:

Code:

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

to

Code:

<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.