Suggestions (#3) - button press cause multiple events? (#10) - Message List

Hmmm....moving stuff between forums.....I'll get back to you on that. This is a beta plugin to beta software - that may require some digging.

Yup, CWiid is just me, although that's partially my fault - I'm sitting on patches from a couple of people that I haven't had time to verify and apply (hoping for this weekend). For anyone interested in contributing, the two biggest things off the top of my head are IR tracking quality and Python bindings.

Some of the things you guys are talking about could be done currently with plugins - "could" and "can" are two different words though.

Concerning the modular configuration, this is what the include statement is for. Take a look at the way the acc and ir_ptr config files work - the same thing could be done with any number of different parts of the configuration.

I'll reply in more depth later - gotta go to work.

I think this should be moved over to a different forum as well. Maybe "Suggestions"? Maybe we should create a wishlist wiki page. As far as gesture recognition goes, I know there are plans for this in the future, and will it seems it will likely involve python. I think things like this and my earlier suggestion would be implemented very similarly.

I got the feeling that this was mostly just one person (dsmith), and I have to say I am very impressed by his work. I am also willing to help out as I've said before. I know c++ pretty good (going on 4 years with it) and have played with python a bit. I can usually pick up and do straight forward stuff in other languages pretty quick. I guess what I'm getting at is: dsmith, if you ever need help with something feel free to ask.

Well, sorry for rambling. It's around 4:30 AM my time now as well. Maybe we do need a Thinking-Up-Crazy-Shit-At-4-AM board.

To the Batmobile!

I think the wiimote tilt thing idea would be an idea much better (easier, simpler, etc.) reconciled outside the driver. The reason I say this is because the idea (tilt = faster repeat rate) is rather vague when translated into code. What should the default button rate be? What should the sensitivity be? Should there be a dead zone within the first few degrees? Should the repeat rate increase linearly? exponentially? logarithmically?

The more logical thing (IMHO) would be to take the raw roll and pitch data and use them as multipliers for keypress emulation (I was digging around and found xmacro  http://xmacro.sourceforge.net/ might handle something like this quite neatly). You could probably do the same with the accelerometer output.

What I think might be really cool though would be to make cwiid ultra modular, although I'm not exactly sure what I mean by that (sorry, it's 4:30am local time). What I envision, however, is having little bits and pieces of profile/plugin information each individually selectable from a higher level profile manager of sorts. This would allow for fine-tuning of individual components and then mixing and matching them into a frontend that dispatches commands accordingly. By doing this we could, for instance, change button mapping from profile A to profile B without changing the IR control mechanism (or vice versa). My apologies for the thoughts in this paragraph being entirely incoherent. Feel free to disregard it until I have time to wrap my head around what I'm trying to convey. =P I'll sleep on it and come back with something intelligible in the morning. I swear. =D

Also, another thought I had was CWiid having the capability to implement rocking and swinging gestures that call keystrokes/functions. For example, a simple example would be pressing a button and rotating the controller 45 degrees counterclockwise could send ALT-LEFT (Firefox "back" button) or CTRL-SHIFT-TAB (FF previous tab) to the X server. A similar function (although think different plugin/profile) could use the tilt to seek back/forward in Amarok, VLC, or MythTV.

More complex examples could include flings of the remote (as determined by the motion sensor X, Y, and Z values exceeding certain limits) calling functions. Implementing this would be much tricker, but presumably within the bounds of reality. As I stare at the wmgui output, flicking the wiimote left causes the X value to increase rapidly, decrease rapidly, and return to baseline. We could define a rule for this (minimum threshold values in each direction), and then when triggered, could output CTRL-ALT-RIGHT to rotate the Beryl cube right (simulating a "grab" of the present face and a "yank" with the remote to the left.)

My apologies if a lot of this is just pie-in-the-sky type wishful thinking. I'm kinda just throwing out ideas of the "wouldn't that be cool!" variety. Ultimately I would love to help turn the Wiimote into a "killer app" of sorts for Linux. And I think nothing would be cooler than to head to a friend's house with a Wiimote, Bluetooth dongle, and a LiveCD and show off my 1337 h4xx0r 5k!11z =P

As far as "devs" are concerned, I'm not sure there are any. AFAIK, CWiid is a one man operation with dsmith running the show. I should also confess that I personally have incredibly limited programming skills (read: none) and would by no stretch of the imagination consider myself a developer. I do, however, have a copy of Python for Dummies lying around somewhere that I would certainly like to break in. If there's anything that's gotten me interested in serious programming lately it would be this driver project thingy.

And one final note as I end my rant for tonight. Am I think only one who think this thread should be moved to another forum (possibly the Development, Suggestions, or Matt's-Thinking-Up-Crazy-Shit-Again boards?)

I'm still thinking about different ways to address the configuration. I haven't come up with anything ground breaking yet.

I have thought of another feature I'd like though. It would be nice if you could map Plugin.acc.Y and Plugin.acc.B to buttons. The more the wiimote is tilted, the faster the repeat rate will be for the assigned button.

School will be out soon. When that happens I'll actually be able to contribute more than a little script and dreams for cwiid.

I also agree that these changes should be part of the 2.0 release. With everything we've been talking about here, cwiid sounds like it's turning into more than just a driver, but a complete set of userland tools as well. If the devs feel like this is the way it's going, the wiki homepage should be updated to reflect this (I don't want step on any toes).

One more thing - I was wondering how many devs there are for cwiid. How many people contribute to this project regularly? Just curious.

-Nick

Give me a few days to get some of the libwiimote issues cleared up, then I plan to switch to user interface mode for awhile - come up with some more definite ideas about how to address configuration, as well as the (currently poor) quality of accelerometer and IR tracking. If the solution ends up being involved, I don't think a temporary measure (such as triggering scripts) would be too difficult.

At this point, I want to keep the C plugins - maybe have some mechanism through which a plugin can be written in any of several languages. Having tracking algorithms implemented as plugins keeps the core code cleaner, allows easier collaboration (trading plugin so files is easier than trading patches).

Another key issue that I've been thinking about lately is how all of this fits in with ultimately (I'm thinking 2.0?) making a kernel module out of CWiid.

I think what we're ultimately getting at here is making cwiid modular, leaving the core driver in c but everything else in python (ir tracking, andling accelerometer input, plugins, etc). The driver would deal directly with the wiimote and make it easy to take/send data through the scripts. If this were to happen there could still be simple config files like the ones that are in place now, but the user could change how input and output to/from the wiimote is handled through the python scripts. To me this sounds like a great goal and an awesome solution to expansion.

Until something like the above could be written and implemented, it would be nice to be able to map a script or multiple events to a button in the config files by "wiimote.<button> = _script-to-run" or "wiimote.<button> = <button1_symbol> + <button2_symbol>." Would this be easy to do?

I think you make a very good point about the config syntax getting ugly and the idea of unnecessary code bloat and such would not be ideal. Personally, I think the way it is now would make for a very sensible and workable default setting. However, I think extensibilty would be a key feature for some users. I would imagine a buttons.conf file that allowed for some basic trivial modifications (e.g. Wiimote.Foo = KEY_X) and offload more complex functions to an external script or plugin (e.g. Wiimote.Bar = SEND_STDIO_SIGNAL_X_TO_$INTERFACE).

The only downside I could see would be a slightly trickier interface when communicating with the driver. It would be necessary (I think) to standardize some sort of framework for a third party applet to make Wiimote status inquiries (some basic accelerometer/button detection output and LED/speaker input) in order to provide maximum functionality.

I also think Python would be a great choice. Whereas C looks like Chinese to me, Python is a much more understandable French. (relatively speaking - I took Spanish in high school ;)

As for IR tracking, I'm not entirely sure where that would fit in. I think ideally it should be part of the driver itself. It seems (to me at least) like it shouldn't require hacking of config files and installation of various plugins (perhaps a commandline switch with the ability to turn it on/off through a call to the driver). OTOH, I think it's a possiblity that having a plugin do the IR tracking would allow the tracking to be separately controlled and optimized (and configured on the fly depending on context tracking). I'm not sure how this would be an important feature (maybe I'm just lacking forsight ATM), but someone a lot more creative than I might find it useful. So basically as far as the IR tracking is concerned, I'm not sure where I'd suggest putting that. Hope that helped =P

I agree that you should stick to a well-known and common scripting language as opposed to "reinventing the wheel". Python is a good choice because it is fast, well documented, very popular, included with most Linux distros, etc... although I'm wondering if it might be a little too low level for your needs. Almost any scripting language could handle what you're looking for... heck, even Javascript! Just pick a popular one that you know well :)

spidey

My current thinking is that these ideas are all good, but that good ideas will keep coming in, the configuration syntax is just going to keep growing indefinitely, and I see no point in implementing a full scripting language as GlovePIE has done when there are so many available. What would you guys think about a python interface? If done correctly, I envision little to no changes in simple scripts like the ones currently in the distribution (keeping things simple for users who don't want to learn programming/Python), but it would have the power to handle more complex events, and possibly even things like IR tracking (although I think I want to keep the C plugins around). I realize this is a vague idea - I'm not sure yet how it would all work together. Comments?

I was just digging around through the 'buttons' config file and wondered the same thing. I think being able to register multiple keypresses for one wiimote buttons press would be a huuuge improvement in usability and usefulness. Both MythTV and Beryl have been mentioned, but I was thinking even simpler actions such as ALT-TAB spring to mind. I think having to specifically map a button to both CTRL and ALT for certain tasks (the default keyboard settings for rotating the Beryl cube comes to mind) makes the wiimote rather awkward to control. While the B buttons lends itself well as a modifier key (the top buttons are still easily accessible with the B button pressed), the others don't really lend themselves to similar behaviors. Being able to map a single button to multiple keypresses (e.g. ALT-TAB and CTRL-ALT-LEFT_MOUSE_BUTTON) would be incredibly useful.

The other idea about being execute (shell?) scripts from button presses would also be helpful. The first idea that comes to mind would be to bind a certain button (likely the 1 or 2 buttons) to either rebind the button configuration on the fly (sorta like pressing the TV/VCR/CATV buttons on a universal remote) or to bring up a third party application uniquely helpful to the wiimote (I imagine something like those pie menus from the Sims (perhaps w/4 options at a time for D-Pad navigation) that could contain links to commonly used programs or (see previous option) a variety of "control modes" to put the wiimote into).

Again, this is just stuff that's been rolling around in my head as possible functionality improvements for the wiimote. (I also posted about the button configuration thinger on the wiili forum  http://www.wiili.org/forum/brians-suggestions-t1139.html which I can't claim to have come up with first.) Ultimately though, I feel like the wiimote has some really cool potential within linux (think mythtv, amarok/rhythmbox/xmms, beryl, konqueror/firefox all working seamlessly) if we can get the right software running alongside it.

Regardless, great work so far, but having two events and/or a shell script fire from a single keypress would be unbelieveably useful from both a third-party developer and end-user point of view =)

I like this idea. It would be useful with programs like beryl.

It would be even better if you could specify a script to run in the config files instead of just key presses. This would make interfacing the wiimote with programs that support dcop much easier as well as allowing key presses to do more complicated tasks. I was thinking of writing a small program that would do this for you, automatically setting up xmodmap and the config files, all through a simple gui. This would have to wait until school is out though.

Not currently, although you could kludge it with a plugin. This seems an odd request - why do you want two events to fire?