It's very basic, a bit buggy, but It works.
If you are a gentoo user, check this howto, written by stone.
If using Ubuntu 7.10 (gutsy gibbon):
- First, make sure bluetooth is working
- Download the program
- Extract the file "demo" (no need for a configuration file now)
- sudo apt-get install lswm libcwiid0 libsdl1.2debian libxext6 libxtst6
- sudo ln -s /usr/lib/libXtst.so.6 /usr/lib/libXtst.so
- Now we are ready to execute it: ./demo
- Put the wiimote in discovery mode (press 1+2)
- If the computer cannot connect with the wiimote, you can try to pass the wiimote address as the first argument: "./demo thewiimoteaddress". To obtain this address, execute "lswm", as you press 1+2 in the wiimote.
- When the wiimote is connected, you should see four crosses and small rectangle at the center of the screen
- Point the wiimote to the screen, and start moving your IR pen.
- The position of the IR pen will show in the little square at the center of the screen. You can use it to adjust the wiimote so the distance between the points at the corners is maximized.
- With the IR pen, click at the crosses, in this order: top-left, top-right, bottom-left, bottom-right.
- After each click on the each cross, you have to press spacebar (you will notice that the cross you have to click is blinking)
- When you press the spacebar the fourth time, the IR pen and the mouse pointer will be in sync. You can start to use your electronic whiteboard
- To exit, press any wiimote's key.
If you want to compile it yourself, check the project in google code (go to the source tab if you want to browse the code).
UPDATE: I opened another branch in the project, with experimental code from vahtu1987 (a great contributor to the project). Here, check the svn/branches/cpp folder.
If you have subversion installed on your system (sudo apt-get install subversion), you can get a working copy just typing:
$ svn checkout http://linux-whiteboard.googlecode.com/svn/trunk/ linux-whiteboard-read-only
You need to install some development libraries:
$ sudo apt-get install libcwiid0-dev libsdl1.2-dev libxext-dev libbluetooth-dev
Maybe you will need to make a link for the libXTst library:
$ sudo ln -s /usr/lib/libXtst.so.6 /usr/lib/libXtst.so
If you can't get it working, post a comment. I will try to help you!!
GOOD LUCK, and happy hacking (linus dixit).
179 comments:
hello,good program .i hope installing it tomorrow.
can i use several lightpen??
i would like see http://multicursor-wm.sourceforge.net/
with two penlight
i would like if would be posible config it as a touchscreen
on xorg.conf,as i do with cwiid ,configuring it as mouse.
thanks
good job
dani
Hey. Thanks for your comment!!
For now, I haven't thought of multiple cursors.
The program generates mouse events. It's not necessary to configure anything else in xorg.conf
Thank you very much for porting the program. I tried it on my Ubuntu machine with great success. My laptop, however, is running Gentoo, and I can't seem to find the necessary libraries easily. Will I just have to download, compile, and manually install each one?
Hi !
Greate work ! I wanted to start writting a program in C after seeing the same video, but you were quicker than me ;)
I'll read your code, and I really want to help you to improve this software.
Under which licence do you want to release it (I hope, a free one) ?
here is my e-mail address, if you start a project or need some help, please feel free to contact me :
makoto.kaworu@gmail.com
Stone: thank you!! It makes me happy that my program is useful to you!
I don't know about gentoo. I use Debian normally, and ubuntu occasionally. I think there must be all the libraries in other distributions. Let me know when you have it running!!
kaworu: I appreciate all help. The code is avaliable on google code: http://code.google.com/p/linux-whiteboard/
Dowload the code, and if you can enhance it, let me know!!! I want this to be free software. Don't hesitate to modify it, use it, and distribute it. I have made you Member of the project. Just login with your google account and go to the address indicated above.
Well unfortunately I've hit a roadblock that I just can't seem to pass. The meschach library refuses to recognize gcc and I can find absolutely no documentation on this happening to anyone else. So I'll just have to wait until someone can either port the program with different libraries or... well I don't know.
I can't compile libmeschach, perhaps due to the fact that the project has been dead since 1995. libmeschach only does matrix operations, correct? That's already possible without the need for an external library. Debian keeps it nicely patched to keep it in the repos.
It's nice to see that it works on Debian and it's derivatives, though. That's a great step in the right direction. I'd try to remove the meschach library myself, but I don't know how it works.
I gave up compiling and extracted libmeschach-dev over from the Ubuntu Hardy .deb package. However, I get this when compiling:
wii.c:109: error: conflicting types for ‘cwiid_callback’
wii.c:7: error: previous declaration of ‘cwiid_callback’ was here
I'm extremely close... What version of cwiid do you have?
Stone: I will try to remove libmeschach entirely. As it points TehomglolXD, that library is used only for matrix operations. I can write the matrix routines myself, I think. I am starting right now!
tehomglolXD: In gutsy gibbon, the libcwiid0-dev version is 0.5.03+svn20070508-2
(the code in wii.c is taken from the "demo" program here)
Tell me about your progress. I will help you!!!
I'm going to work on this all day!
I have eliminated the need for libmeschach. I have written the necessary routines. The subversion repository is updated. Try to compile it, and see if works!!
Hi all,
I was able to compile your software in Debian Etch (after upgrading libbluetooth to 3.23 from bluez.org to get my wiimote to work).
I got the same error as tehomglolXD. I juste remove the void before the cwiid_callback function and it works fine !
The version of cwiid is 0.6.00
To be continued...
Thanks for all
Jacques-Daniel PILLON
Hi,
Thanks for your program. It didn't work for me. I have a Gusty Gibbon on a AMD Athlon XP 2000+ and a USB BlueTooth which one work perfectly with wmgui / wminput.
When I lauch your program, I see the four cross, and I can select them with the wiimote. After the fourth cross validation (with space) the screen come back to my desktop and I see the four location of the cross and sometimes it's written : Erreur de segmentation (core dump).
How can I fix it ?
Thank a lot and courage for developpement. It's great ! (even I can't use it for the moment :) )
sizex = 1280
sizey = 1024
bpp = 32
mac = 00:19:1D:69:7E:B0
Put Wiimote in discoverable mode now (press 1+2)...
Connected!!!
Button Report: 0003
Button Report: 0002
Button Report: 0000
Erreur de segmentation (core dumped)
Umm...
Maybe you can run with the debugger. Do this:
gdb demo
> run
...
(then the program terminates abnormally)
> backtrace
(this should print some useful info)
> p p_wii[0]
> p p_wii[1]
etc...
With this information, maybe I will know what is the problem.
You can try the old version, too (it requires libmeschach, avaliable on ubuntu and debian: here
Here there is information requested..I will try your old version. Thanks a lot. If you need more information, don't hesitate.
Put Wiimote in discoverable mode now (press 1+2)...
[New Thread -1219052656 (LWP 13703)]
[New Thread -1227445360 (LWP 13704)]
Connected!!!
[New Thread -1235838064 (LWP 13705)]
Button Report: 0003
Button Report: 0002
Button Report: 0000
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1213671232 (LWP 13698)]
0xb7d947bc in free () from /lib/tls/i686/cmov/libc.so.6
(gdb) backtrace
#0 0xb7d947bc in free () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7cc471f in XkbFreeClientMap () from /usr/lib/libX11.so.6
#2 0xb7cc9613 in XkbFreeKeyboard () from /usr/lib/libX11.so.6
#3 0xb7cbd183 in ?? () from /usr/lib/libX11.so.6
#4 0x080649a0 in ?? ()
#5 0x0000007f in ?? ()
#6 0x00000001 in ?? ()
#7 0xb7d10b2c in ?? () from /usr/lib/libX11.so.6
#8 0xb7d10b2c in ?? () from /usr/lib/libX11.so.6
#9 0x00000000 in ?? ()
Same bug with the old one...Maybe I need to compile it. I'll try and I'll give you news to see if my problem is due to my system.
Thanks
I tried to compile it and the same bug appears...My X11 server is corrupt maybe. I will try on my other PC.
Anymay, good job and thanks for your help.
The strange thing I see... that messages indicate that the buttons on the wiimote are being pressed. If you don't press them (you should not), There should be no messages of this type...
Maybe if you have another wiimote to check...
With the other Wiimote on the other PC. I'll will see in the code. So, what sort of thing should I see after the calibration ? Perhaps I need mouseemu ?
Put Wiimote in discoverable mode now (press 1+2)...
[New Thread -1218548848 (LWP 15816)]
[New Thread -1226941552 (LWP 15817)]
Connected!!!
[New Thread -1235334256 (LWP 15818)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1213167424 (LWP 15811)]
0xb7e0f7bc in free () from /lib/tls/i686/cmov/libc.so.6
(gdb) backtrace
#0 0xb7e0f7bc in free () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7d3f71f in XkbFreeClientMap () from /usr/lib/libX11.so.6
#2 0xb7d44613 in XkbFreeKeyboard () from /usr/lib/libX11.so.6
#3 0xb7d38183 in ?? () from /usr/lib/libX11.so.6
#4 0x080649a0 in ?? ()
#5 0x0000007f in ?? ()
#6 0x00000001 in ?? ()
#7 0xb7d8bb2c in ?? () from /usr/lib/libX11.so.6
#8 0xb7d8bb2c in ?? () from /usr/lib/libX11.so.6
#9 0x00000000 in ?? ()
When you perform the calibration, do you see the "little dot" moving in the square at the center of the screen?
When it segfaults, it's when you try to click on the screen with the IR pen?
You can try to hack the code: eliminate all "free" routines (the instructions that free the memory, there are some in do_calcs and in other places...)
Try to insert some "prints" in the code, and see where it exactly fails...
I see the dot in the square perfectly (the dot moves with my IR source) and sometimes, I can see the location of the four cross == (50;65)== after crash (a list of four locations), but nothing after the calibration.
I will see.
The original project under Windows doesn't work for me because my dongle is not recognized. But on Ubuntu my dongle is recognized, wminput work perfectly, wmgui too, and I hope yours next :D
I'll search.
Sebastien: I think the problem is in the function "SDL_QuitSubSystem(SDL_INIT_VIDEO)".
Maybe we can find a way to delay the shutdown of the SDL video subsystem until the end of the program...
Tomorrow I will look at this issue. Come back soon!!
Alright! With the matrix file you've written (thank you again, by the way) we're making progress. Now I'm getting this output:
$ make
gcc wii.c -c -g
wii.c:109: error: conflicting types for 'cwiid_callback'
wii.c:7: error: previous declaration of 'cwiid_callback' was here
make: *** [wii.o] Error 1
I should note that when I compiled the CWiid library I had to arbitrarily choose a .so output file to copy into my /usr/lib (my options being "libcwiid.so" "libcwiid.so.1" and "libwiicd.so.1.0"), and I'm not much on the programming (I'm still a Linux newbie) so I'm unsure if that has anything to do with this.
Scratch the comment about the libcwiid.so files, I was being stupid. Regardless, I'm still stuck with that error.
Stone: In a comment above, Jacques-Daniel says "I got the same error as tehomglolXD (the callback error). I just remove the void before the cwiid_callback function and it works fine !". (in line 109)
Try this, and see what it happens!!
Thank you for checking my software. It makes me happy to give it!!
Hello,
First acknowledge you for get the program work (http://rakunic.wordpress.com/2007/12/23/wiiteboard/).
And second, I wanted to tell that I have a few ideas to improve your program. I have already managed to make the program does not require configuration file. And my intention is to liberate it from the SDL library using directly X11 (this is more difficult). If you are interested, contact me.
PD: Pardon by the spelling, I am Spanish and I translate myself using google-language-tools, although you do not worry if I don't understand you, my reading skills are better :P
Hi, I'm also having a SegFault at Line 242 in main.c:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7b8c6c0 (LWP 17353)]
0x08049893 in main () at main.c:242
242 black_color = SDL_MapRGB(s->format,0,0,0);
Is your screen at 32 or 24 bpp?
I had a similar issue with a computer that was configured at 16bpp
Check xorg.conf
By the way, some people has offered help. We plan to remove SDL and use only X11 libraries.
It was at 16bbp, just figured it out myself that it seems to need more than that.
After I changed it to 24bpp it worked fine.
Just came back to post that and saw your post.
I'm glad to know that it worked for you!
Starting program: /home/chadwick/Desktop/trunk/demo
[Thread debugging using libthread_db enabled]
[New Thread -1213876560 (LWP 6505)]
sizex = 1680
sizey = 1050
bpp = 0
mac = ANY
Put Wiimote in discoverable mode now (press 1+2)...
[New Thread -1213879408 (LWP 6508)]
[New Thread -1222272112 (LWP 6509)]
Connected!!!
[New Thread -1230664816 (LWP 6510)]
[New Thread -1239180400 (LWP 6511)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1213876560 (LWP 6505)]
0xb7d627bc in free () from /lib/tls/i686/cmov/libc.so.6
(gdb) backtrace
#0 0xb7d627bc in free () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7c927a5 in XkbFreeClientMap () from /usr/lib/libX11.so.6
#2 0xb7c97613 in XkbFreeKeyboard () from /usr/lib/libX11.so.6
#3 0xb7c8b183 in ?? () from /usr/lib/libX11.so.6
#4 0x08066288 in ?? ()
#5 0x0000007f in ?? ()
#6 0x00000001 in ?? ()
#7 0xb7cdeb2c in ?? () from /usr/lib/libX11.so.6
#8 0xb7cdeb2c in ?? () from /usr/lib/libX11.so.6
#9 0x00000000 in ?? ()
(gdb) p p_wii[0]
$1 = {x = 266, y = 723}
(gdb) p p_wii[1]
$2 = {x = 929, y = 554}
(gdb) p p_wii[2]
$3 = {x = 210, y = 214}
(gdb) p p_wii[3]
$4 = {x = 954, y = 157}
chadwick: thanks for your testing!!
I have changed a few lines in respect the SDL_quit that I think gives you a segfault.
Try the new version. Now, the config file is gone. If you cannot connect with the wiimote, execute "lswm" to get the address, then: "./demo theadressyougot"
Huzzah! Removing void lets it compile (I still get the same result, but as warnings instead of errors). The next issue I ran into was that I get a segmentation fault if I don't have my exact screen size and resolution in the config file. I just read your comment about a new version, so I'll try that one as well.
Yes, the new version compiles just fine (not even any errors) with removing that "void" again. No segmentation faults or anything. Nice work!
Thank you, Stone!
Hi !
Very nice work, you've done it quickly than me, also working on the Johnny project !
Something I want to know it's if a red pen works, or if it requires an ir pen. There is a little difference (I suppose), because red is something like 650nm and ir more than 720nm.
I would be happy if I can help you, and I will see your code next days.
Thanks Loic.
I use a IR pen from an old TV remote controller, with a 1,5 AA Battery. It's fine for testing the program on the screen, not on projection (maybe it's not bright enough). Have you any suggestions for LED's that work from a distance of, say, 4 o 5 meters?
If you want to improve the code, don't hesitate. Send the diff's directly to me and I will put you in the project member's list.
The areas we are working now are: trying to drop SDL (do all the graphic stuff in X11 libs) and improve the CPU usage.
If you don't mind, I would like to write a How-To page for the Gentoo Wiki about setting this up. If you think it's too early in development to do that, I can wait.
No suggestions, sorry !
So you've built a pen with only a led and a AA1.5 ?
Stone: go ahead, I am very happy that people do things like this with my software. Certainly, there are things that are going to improve in the following days (I hope).
Loic: yes, it's a very basic IR pen. Everyone can make one from an old TV remote. It works well on the screen.
This is amazing. I'm going to go out and buy a Bluetooth and try to get this working on my openSUSE machine. I'll report back in a few days!!!
Thank you, andrew. We will be waiting for the results of your testing.
I have written a small howto for gentoo users here: http://gentoo-wiki.com/HOWTO_Configure_a_Wiimote_as_an_Electronic_Whiteboard
If you see any glaring errors, please let me know and/or fix them yourself.
stone: Great Work!! I read your howto and was really well written. I'm sure that many people will find that very useful.
You have helped me a lot, pointing things that did not work, and being very supportive. Thanks again.
K, i just downloaded the third version, I can connect my WiiMote fine, wmgui works fine.
When i run demo this is what happens:
user@comp:~/Desktop/downloads$ ./demo
sizex = 1600
sizey = 1200
bpp = 32
mac = ANY
Put Wiimote in discoverable mode now (press 1+2)...
Connected!!!
Segmentation fault (core dumped)
right before the Segmentation fault, the screen flashes to black.
I tried using gdb. Here is what happened:
(gdb) run
Starting program: /home/michael/Desktop/downloads/demo
[Thread debugging using libthread_db enabled]
[New Thread -1213556544 (LWP 9604)]
sizex = 1600
sizey = 1200
bpp = 32
mac = ANY
Put Wiimote in discoverable mode now (press 1+2)...
[New Thread -1213559920 (LWP 9610)]
[New Thread -1221952624 (LWP 9611)]
Connected!!!
[New Thread -1230345328 (LWP 9612)]
[New Thread -1238856816 (LWP 9613)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1213556544 (LWP 9604)]
0x08048fc1 in pixel (x=700, y=960000) at main.c:110
110 main.c: No such file or directory.
in main.c
(gdb)
Right after the wiimote connected the screen went black, no crosshair, IR in front of wiimote did nothing. I had to switch to a ttyl and "killall gdb" to be able to use my screen again...
I have no idea whats going wrong...
I just finished building a pen to use with this. With demo-3 I get through the calibration stage just fine, but when I try to use the pen the mouse pointer just goes to the top left of the screen.
I'm using ubuntu gutsy with windowmaker as my window manager.
David Lang
I found my problem, since the program always does mouse with the first button clicked it was getting stuck. once I started inkscape to give me a program less sensitive to work with I had no problems.
it would be nice if there was some way to move the mouse around without it considering the button down (to be useful there would need to be a way to signal the system that you want the button held down, something like holding down shift is a fair first cut)
David Lang
Michael: make sure that your screen is at 24bpp or 32bpp
The program fails if used at 16bpp.
David: yeah, some people have pointed this (a way to move the cursor without click). It's easy to add this feature as you describe it (with the shift key). I will think about it!
Hello,
in fact, there is one parameter missing in the callback.
To solve the error :
wii.c:109: error: conflicting types for ‘cwiid_callback’
wii.c:7: error: previous declaration of ‘cwiid_callback’ was here
You just have to transform :
void cwiid_callback(cwiid_wiimote_t *wiimote, int mesg_count,
union cwiid_mesg mesg[])
TO
void cwiid_callback(cwiid_wiimote_t *wiimote, int mesg_count,
union cwiid_mesg mesg[], struct timespec *timestamp)
as specified in the prototype of cwiid_callback in the cwiid lib.
Thanks for your software !!
Jacques-Daniel PILLON
He's right, making that change removed even the warnings. I have updated the Gentoo Wiki page accordingly.
I've tried that change in the callback function, but now in Gutsy Gibbon fails:
wii.c:116: error: conflicting types for ‘cwiid_callback’
wii.c:7: error: previous declaration of ‘cwiid_callback’ was here
make: *** [wii.o] Error 1
Maybe it's the libcwiid version. In gutsy, it's 0.5.03+svn20070508-2
What version do you have?
a couple other thoughts.
one other thing that would be good to do is to set led_status to light one of the LED's on the remote, this would help to make sure that it gets turned off when you are finished and doesn't drain the remote's battery.
how hard would it be to use a wiimote that's already connected to the system instead of initializing it from scratch each time?
when I get a little time to hack on this I want to make it accept input from multiple wiimotes at one time, so that I can put one on each side of the screen so that when I hide the LED from one it's still visable to the other and I still have control (this should be very simple, do the initialization on both at the same time, and when operating ignore a position from the second one that is close enough to the first one to be considered the same)
David Lang
What libraries do I need installed? I'm running openSUSE 10.2. I installed cwiid, and lswm recognizes the MAC address of my Wiimote. But I don't know what else to install.
The error I'm getting -
./demo: error while loading shared libraries: libcwiid.so.0: cannot open shared object file: No such file or directory
Andrew: what cwiid libraries are in your /usr/lib directory?
Try to make a link of one that says something like wiid to libcwiid.so.0
for example: ln -s /usr/lib/libcwiid.so.0.1 /usr/lib/libcwiid.so.0
I'm using CWiid version 0.6.00, so it looks like they've changed something from 0.5.x to 0.6.x.
I had "libcwiid.so.1.0" and "libcwiid.so.1" in that directory, and I symlinked "libcwiid.so.1.0" to "libcwiid.so.0" per your instructions.
Getting closer!
*********
linux-drew:~/Desktop/demo-3 # ./demo
sizex = 1280
sizey = 960
bpp = 32
mac = ANY
Put Wiimote in discoverable mode now (press 1+2)...
./demo: symbol lookup error: ./demo: undefined symbol: cwiid_connect
***************
PS - I ran this on my laptop (Ubuntu 7.10) without pro0lems. Coolness!!!
On openSUSE - (Installed cwiid manually)
**********************************
linux-drew:~/Desktop/demo-3 # lswm --version
CWiid Version 0.6.00
On Ubuntu 7.10 (Installed via your commands), lswm won't even print out a version number, telling me that it is older, and probably v 0.5.x.
Hmmm...
Confirmed - the Ubuntu version is 0.5.03.
Hello AndrewTheArt,
I've encountered the same problem with my Gentoo. Maybe because I'm using a 64 bits processor.
The solution consists in downloading and compiling cwiid
wget http://abstrakraft.org/cwiid/downloads/cwiid-0.6.00.tgz
if your cpu is 64 bits, then don't use ./configure
you should prefer instead
./configure --libdir=/usr/lib64
if your libcwiid.so symbolic links points to /usr/lib64/libcwiid.so
I have just added a comment in http://gentoo-wiki.com/HOWTO_Configure_a_Wiimote_as_an_Electronic_Whiteboard
for gentoo users with 64 bits processors
Note that I've also compiled linux-whiteboard project from the sources to make it work properly.
Otherwise, I've got a message :
./demo: error while loading shared libraries: libcwiid.so.0:
I hope this would help
I have a 32 bit machine...
Well, I removed the packaged version of cwiid and compiled/installed it from source. Then I found that none of the libraries for the wii were in the /usr/lib before were there anymore so I reconfigured and specified the library location (--libdir=/usr/lib64). Then I resymlinked the libwhatever.1.0 to the libwhatever.0 as before, and reran the demo executable.
Same issue.
Make that
--libdir=/usr/lib
I'm sure this will get sorted out.
If anyone has the sources for cwiid v 0.5.3 handy, give me a link (=
Okay, in fact cwiid does not install the libraries in /usr/lib by default but in /usr/local/lib
so you can try to add the following entries in your /etc/ld.so.conf if they don't exists :
/usr/lib/
/usr/local/lib
then run ldconfig
-----
before recompiling cwiid don't forget to do a :
make uninstall && make uninstall_config
to remove any previous installation of cwiid as written in README file.
Than re-run
./configure
make && make install
Then it should work
./demo: symbol lookup error: ./demo: undefined symbol: cwiid_connect
Andrew: I think some users have it working with cwiid 0.6. Check this
I guess you have to compile it yourself for your system. That means you have to install the development libraries for sdl, libXext, bluetooth and cwiid
Thanks, works great!
If you want this to gain widespread appeal, you need to determine exactly what versions of the various tools you use and post them as requirements. I'm not ragging on you, to the contrary, you did a great job implementing the code to work seamlessly with Ubuntu. You definitely have skill (= But for the average user it is asking too much to make them determine what versions of the various tools are needed and make them custom compile more than a few packages. If it is a necessity, an instruction guide would be great.
I know you haven't configured this for widespread usage yet, of course, but I'm sure it's a long term goal of yours.
Thanks for the portage and I hope to fix this issue with openSUSE eventually, when you post exactly what versions of the various tools are needed and if any special compilation flags are necessary.
hi there!
i'm experiencing same problem as some other comment authors. I'm running the demo in Ubuntu Gutsy. I get the calibration screen ok untill hitting SPACE on the last cross. This is what i get running gdb (note i compiled from source since the downloaded demo executable thrown similar problem. I did so by following the instructions found at the gentoo wiki):
Starting program: /home/daniel/Software/LinuxWii/svn/trunk/demo
[Thread debugging using libthread_db enabled]
[New Thread -1213131088 (LWP 18960)]
sizex = 1280
sizey = 800
bpp = 32
mac = ANY
Put Wiimote in discoverable mode now (press 1+2)...
[New Thread -1213133936 (LWP 18968)]
[New Thread -1221526640 (LWP 18969)]
Connected!!!
[New Thread -1229919344 (LWP 18970)]
[New Thread -1238447216 (LWP 18971)]
[Thread -1238447216 (LWP 18971) exited]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1213131088 (LWP 18960)]
0xb7ce96a2 in ?? () from /usr/lib/libX11.so.6
As you see, i'm on 32 bpp, and I think I'm running the right version of cwiid...
any ideas?
Thanks a lot for your help and efforts.
Hi Dainel!
Thanks for your testing. Please compile the last revision (I have made little changes this morning), and see if it works for you.
I'm trying to get rid of SDL. I don't know if I'm using the functions incorrectly. I'm working on it right now.
Cool!
I downloaded from the svn and got this compile-time error:
gcc main.c -g -c -I/usr/include/SDL/
gcc wii.c -c -g
wii.c:116: error: conflicting types for ‘cwiid_callback’
wii.c:7: error: previous declaration of ‘cwiid_callback’ was here
make: *** [wii.o] Error 1
but solved easily, again, replacing the cwiid_callback() declaration as said in the gentoo wiki.
So it's working like a charm now!!!
Moltes grà cies :)
Thanks! That works like a charm for me. This is really powerful stuff!
Tnx to stone and Pere Negre you 2 have made this program work in gentoo and it is easy to compile and do :D so tnx.
stone you know you can install cwiid whit emerge you just need to read http://abstrakraft.org/cwiid/wiki/Gentoo link :D and than you have it in portage and so you can install it he he
But really nice program and good work Pere Negre
Thanks!
It makes me glad that you find this useful. I enjoy writing code, so for me it's a pleasure.
Thanks again all of you for testing and encouragement
Can't believe it!
Guys, you are making the linux experience worth it!
I was unable to make it work on Windows machine (no drivers for BlueTooth dongle), but it works directly on my Ubuntu!!!
Great!
Thanks a lot, keep on the good work.
Hi,again
i was trying to use it ,but i have no many time.i have several problems build penlight,(i tried first with win version but it is unable to detect.i build several infrared (emisor and receptor) but it is unable to detect.i hope having more time and try again.
i tried "TV remote controller",but it doesnt detect.only detecs Candles.
now i will begin exams and i can not test anymore.
i would post here an interesting link i saw yesterday
http://mtg.upf.edu/reactable/
http://www.iua.upf.es/mtg/reactable/?software
http://nuigroup.com/log/about/
Hey!
I got the following problem: I run the programm, calibrations seems to go fine, but then it just terminates. Whatever I do, it dos not click when I light up my pen...
Could it be that my wiimot somehow disconnects or something? Would be glad if you could help me!
Leon
Hello Pere,
Thanks for your wonderful software. I have it running fine under Ubuntu Gutsy.
However I wonder if you or someone else who is following these comments can offer some advice about how to set up the Wiimote to read the IR points reflected off whatever surface the light pen is pointed at.
Firstly, what is the best distance of the Wiimote from the surface. I imagine it depends on the size of the "screen". In my case it is a 52" Plasma TV.
Secondly, what surfaces and light conditions are suitable? I have seen examples of using a DPU to project onto a screen and a table top; and have read about bouncing IR off an LCD laptop screen. But what about a Plasma TV?
Lastly, if the calibration screen shows response to moving the light pen in an extremely jerky fashion, and shining the light pen directly at the Wiimote is better but no cigar, can we conclude that the light source is not bright or focused enough? Or could there be other causes?
Thanks again for your great work,
John
Great project, thanks for your work!
As your program generates standard mouse events (if I got it right), do you have any plans to support multiple pointers?
wiimote can actually follow up to 4, and the MXP X server seems to already be ready to handle those (http://wearables.unisa.edu.au/mpx/)
thanks again.
B.
Hello,
Could you add right click functionality ?
It could be done the same way as on pocket pc (press the stylus on the screen with no movement for a few seconds ==> IR ON with no movement for a few seconds).
Thanks for your program pere negre.
Marty
>> Could you add right click functionality ?
I've added this feature into yesterday's SVN. Although admittedly, the whole program is a big chunk of code hacked together :) no offense, at least it works!.
Right-click/single-click/drag-n-drop is a tad bit more difficult to implement with the Wiimote because the cursor virtually moves all the time (incorrectness of the IR sensor or the user's hand, we are talking about a LED here). So there need to be some tolerance.
I'm thinking about rewriting most of the code so multiple input styles can be easily added. Examples of those may be:
- The LED is only used to move the cursor. Mouse buttons are simulated through key pressings. Cons: not possible to use it with projectors.
- Move the LED to move the cursor, and hold it still for a certain amount of time to left-click. Cons: no right-click and middle-click.
- IR on to click and drag, IR on and hold the cursor for a certain amount of time to right-click.
I'd personally prefer #1, though projector users may like #3.
libcwiid currently doesn't support waiting for events. So eventhough the program uses callbacks, it still has to poll periodically for IR events, which consumes 100% CPU usage. But I'm not familiar with the Wiimote and POSIX threading (yet) to implement such functionality.
VAnhTu1987, If you want to contribute some code, I can make you a project member.
I'll be glad to contribute. Thanks :) .
I submitted a patch for the matrix code. pere negre, can you check it?.
That's unfinished, there are still lots of things to refactor. I need us to reach some consensus before continuing however.
Thanks Vanhtu for your work!!
I will read through your code soon. I'm excited to see that there are people that want to enhance the program.
Thank you again!
I think you're code should get in http://wiiwhiteboard.wiki.sourceforge.net/
try to contact johnny lee directly from johnny_AT_cs_DOT_cmu_DOT_edu....
One idea to make the left/right/middle clicks is to use different iR frequencies, like in a regular TV remote... I think this is possible but the pen would need more hardware, maybe we could use a modified universal TV remote, by modified I mean, the LED should probably be replaced by a brighter one and the LED should be moved out of the remote, with a tube sticking out from the front or something like that so it would be more visible to the wiimote!!!
Thanks Davim, I'll contact him as soon as the code base has been stabilized. Currently though, some work needs to be done in the cwii lib for it not to consume 100% CPU usage (the program has to poll for state changes, basically).
About clicking issues, it is possible to attach 2 LEDS with different frequencies onto a single pen with 2 buttons (for left- and right-clicking), but not anyone has the necessary tools to build such pens :-) making a LED with switchable power is hard enough for me. We need to get to the lowest common denominator IMO.
I know that the cwiid lib as more features but I've used http://libwiimote.sourceforge.net/ and it works quite well :) and its light...
VAnhTu1987,
Thank you for the right-click solutions you are thinking about.
I'm using the electronic whiteboard with a projector for teaching. And I do agree that #3 (IR on to click and drag, IR on and hold the cursor for a certain amount of time to right-click) would be my first choice.
Keep on the good work!
Marty
@Davim: libwiimote is the old name of libcwiid :) .
@Anonymous: Can you suggest an IR pen with temporary turn-on button that I can buy from eBay or Amazon?.
For info about iR pens visit:
http://www.wiimoteproject.com/index.php?board=24.0
@Davim: Thanks for the excellent info :) .
VAnhTu1987,
I should use a better DIY IR pen in a few days (one I could be proud of ! I hope :) ! - until now i have just added a momentary switch on an old IR remote).
This new IR pen will be made with the body of a laser pen (2 AAA and temporary turn-on button) and i will replace the laser LED with a IR LED - and add a resistor). All parts should arrive in my mailbox in a few days from Conrad.
The laser pen : http://www.conrad.fr/webapp/wcs/stores/servlet/ProductDisplay?catalogId=10001&storeId=10001&productId=535770&langId=-2&ItemHighLightId=529805&from_fh=1&category=recherche
If I manage to make the IR pen and if you are interested I will let you now how it works and more precisely how I made it.
Marty
This is a intermediary workaround which eliminates the high CPU usage. Although it works properly, it is not up to my standard and should be fixed.
The code is still being heavily updated, so expect new version coming soon. I'm still waiting for Pere to add me as a member. At the moment, please download the source (pre-compiled) and the patch from the link below:
http://download.yousendit.com/7CBEAD9F79F87FDF
Does anyone need a GUI for this program?. I'm intending to use 'zenity' for a simple GUI if needs be.
Additional input method should be added within the next few days.
@Anonymous: I couldn't access the URL (Page Not Found error). But I've made a crude pen suitable for testing. Please post a HOWTO in the forum when you're done if possible :) .
Pere add vanhtu1987 to the project!!!! xD
I've test the demo and work perfectly, CPU usage has vanished, congrats
Now I'm busy by the exams until February.
VAnhTu1987,
Trying again the address for my
laser pen
see this:
http://elxordi.no-ip.org/wairglove/english.html
there is a video on the bottom of the page
http://download.yousendit.com/7CBEAD9F79F87FDF
patch applied by
patch < whiteboard*.patch
also will need libxtst-dev on debian systems not sure what the gentoo equivalent is.
Compiles great with the patch and the processor usage is reduced substantially.
yes, I need a GUI for this programm !
because I want to generalize it in my school and without GUI, it wont be accepted :)
I vote for your GUI ! +1
@Pere
Plase add vanhtu1987 to the project!
@vanhtu1987
Your code should be in http://wiiwhiteboard.wiki.sourceforge.net/ already....
:D
I'm sorry for replying so late. Unexpected things happened with my threading code. So we are back to square one again with 100% CPU usage.
The good news are:
- More stable IR event, I'll try to make it behave more like a normal cursor.
- Right-clicking support: I have to admit I over-engineered the thing. Multiple control schemes features have been abandoned. In the mean time, I may try to hard-code most common control schemes and still user-selectable.
- GUI.
It is not possible to support multiple light pens without multi-cursor X (and as far as I know, Windows doesn't support this either, although there is a customized X server for exactly this type of feature).
The feature you might have seen on Chung Lee's demo program uses a Direct3D window, which had its own method for rendering and controlling multiple pointers. It is certainly possible to implement this in 3D games in SDL in Linux, but not with normal X windows.
Here is a compiled version along with the patch for the curious. It's got a lot of 'trash' because of left-over code from previous attempt, although it shouldn't cause atrocities :-) .
Have phun!. Thanks for your video and links.
http://download.yousendit.com/2C0BE65A07A729B1
Updated:
http://download.yousendit.com/36E6D8D9421A8524
To calibrate the Wiimote, hold at a calibration point for 0.7s :) and move on. IR on will generate a left click, without moving the pointer, hold it for 0.7s for a right-click.
Good work vAnhTu1987!!
Although, its a bit buggy, I like the ++ style, and the code is more legible.
If pere does not return, we must start thinking on a new project. But I do not have to involve until finalizing exams T_T
PD: Perhaps, pere is in exams like me.
Nice to see you posting again VAnhTu1987 :)
With your last post :
* What works on my ubuntu gutsy is :
* holding a calibration point for a few seconds to validate it
* sync with mouse pointer
* I really like this new calibration (without pressing space bar)
* What doesn't work is :
* right click by holding IR on a few seconds
* cpu usage (but you already know that ;) )
********
Output from your program while trying right-clicking
Mouse has been down for: 700 milleseconds.
Mouse has been down for: 700 milleseconds.
Mouse has been down for: 700 milleseconds.
Mouse has been down for: 700 milleseconds.
Mouse has been down for: 700 milleseconds.
Mouse has been down for: 700 milleseconds.
Mouse has been down for: 700 milleseconds.
Mouse has been down for: 700 milleseconds.
Mouse has been down for: 700 milleseconds.
Mouse has been down for: 700 milleseconds.
Mouse has been down for: 700 milleseconds.
Mouse has been down for: 700 milleseconds.
Mouse has been down for: 700 milleseconds.
Mouse has been down for: 701 milleseconds.
MOUSE 3's state changed to 1
MOUSE 3's state changed to 0
MOUSE 1's state changed to 0
***********
But no right click happen.
--------------------------------
A few ideas (possible improvements ?)
1)
I use your program at school for teaching with jarnal and xournal.
I have to admit that i can use the IR pen for clicking on icons, moving windows... but not for writing.
In fact, i think that output from the wiimote is a bit jerky (not very stable).
On the other hand we have 100 Hz tracking in wiimote. Which is a lot for
hand writing speed.
Then, is it possible to smooth / filter wiimote's output in your program ?
(I know that jarnal / xournal smooth strokes but it's not enough)
2)
Could you change background color during calibration or add a colored border around the screen ? (because the calibration points are not at the corners of screen
and it's sometime difficult to see exactly where are the borders)
3)
While calibrating screen we go from top left TO top right TO down left TO down right.
Perhaps am i a little bit too lazy but calibration would be smoother (with a projector --> big screen) if you could invert the last two calibration points.
It would be clockwise : from top left TO top right TO down right TO down left.
Thank you very much for what you are doing with this program
The last update should support right-clicking, unless you downloaded the one just prior to that (I made 2 simultaneous updates).
Anyway, you may want to use the latest snapshot. It's got these features/fixes:
* Right-click works
* CPU usage only jumps up when you want to right-click (that is, hold the pointer for 0.7s :) , normally it should stay close to 0.
* Colored borders added while calibrating.
* It calibrates in your order (TopLeft, TopRight, BottomRight, BottomLeft).
- It needs libsdl-sge for the drawing, since I was too lazy to reinvent the wheel :) .
That's it, if you can bother to run it under a debugger :) . Yeah, I know it sounds strange, but that's what happened: the same threading code runs correctly under gdb. I will try to fiddle around with different threading libraries.
In the mean time, to run it under a debugger (I assume you have gdb, it should come pre-installed, or at least along with 'build-essential' package):
gdb ./demo
And type "r" or "run", Enter to run the program.
About the jerky motion, I've got an idea. Which issue (motion jerkiness and threading) will be fixed first depends on the situation, please bear with me :) .
Latest snapshot along with the patch:
http://download.yousendit.com/2007360547ECC491
rakun85:
Right-click should now work properly (including click-drag for copying and moving). I also removed every crufts left from last attempts. Can you try it again?.
Its OK, the last version works better (even right click)
But I experimented some estrange behavior, in the desktop, the selection rectangles don't disappear when y finish a selection.
It seems to work good on jarnal and other apps.
Don't trust me much, my reviews (actually) are very superficial
VAnhTu1987,
wonderful !
* perfect border ;)
* point in the middle square is bigger --> perfect too
* right-click is working like a charm
* calibration point --> perfect again
* cpu load low
PS : i tested it with gdb
PS : did I already say it : "WONDERFUL !!!"
Thank you very much :)
Vahtu: I've opened another whiteboard project. I think you are contributing a lot to the program, and you deserve to see your changes into the repository.
Please, use this repository
I will try to backport some of your changes in my version. In this way, we can develelop our versions without interference.
I will post a link to the two repositories in my blog. This way, people can try both versions.
I think I've made you a project member. Try to upload your versions and post a comment if something doesn't work.
Thanks again for your great work!
vanhtu, what is your google username exactly? I need it to include you as a project member
Another project?? why?? Can't you work together??? you could make svn branches in the same project... And you shouldn't be creating new projects you should post your code in sourceforge, it has more visibility!!
I'm agree with davim.
I don't know why create a new separate project. The code of vanhtu is legible and well commented. He improve the code a lot, but I still find parts of the old code in the program.
If you are busy by other business, only need to add vanhtu to the project.
Thank you for your comments.
@gemini:
My email is VAnhTu1987 [at] gmail,com. Google will convert it to lower cases anyway, so is my Gmail username also vanhtu1987?. My first name (on the Google settings page) is Tu, my last name is Vuong.
I've been to both projects but didn't see me listed on the homepage. I already logged on Gmail though.
@Davim:
I prefer C++ but he likes to keep it in C. It's quite easy to port between both though. But I agree that it'd probably better be kept in separate branches.
I'm trying out boost's threading library, until the threading issue is fixed. It is not quite acceptable to have to run it under a debugger, unless I'd cheat and provide a script to invoke gdb automagically :) .
@rakun85: Does the code run correctly now?. If not, can you provide some output from the program again?. How would it behave without a debugger?.
Vanhtu: I've added a new branch, for your code.
Please use the following command to check the repository:
(warning: I've split the command into lines, you have to join them):
svn checkout
https://linux-whiteboard.googlecode.com/
svn/branch/cpp
linux-whiteboard
--username vanhtu1987
The idea of another project was just silly. I'll try to cancel it.
@gemini; OK, right decision xD now the project go, and we could work better with the svn.
@vanhtu1987; I'm trying to study T_T...xD in a few days (since 8-feb) I'm not human.
Here is the latest snapshot. Changes are:
- Threading issue fixed.
- The code for handling pointer is a lot simpler.
There is only an executable in my package. Anyone who is curious can check out the "cpp" branch using svn.
http://download.yousendit.com/3DCCAD054C9284D1
Next up: Motion jerkiness :)
I just posted a request on the wiimote-whiteboard sourceforge project.
Updated: http://download.yousendit.com/FA5981D72072E891
Possibly it's time to make a configuration file as well. I just switched to another pen and quickly realized it was too cumbersome.
Hi!
First I want to say that I really appreciate your work! this kind of cheap touch screen solution is really cool.
I just tried out the demo. It works quite well - especially in GIMP. When it comes to normal windowmanager manipulations (like dragging windows arround, etc.) I often got "mesg pipe overflow".
Next, I tried to compile the code (in this case vantuh1987's code) by myself.
It is likely, that this is because I'm a noob in matters of compiling, but I got some problems.
The make command tells me "SDL/sge.h: No such file or directory
make: *** [main.o] Error 1".
And vantuh1987's demo file (from "http://download.yousendit.com/FA5981D72072E891) tells me "Permission denied".
What am I doing wrong?
Thanks,
Spindoctor
If you're using Ubuntu/Debian, you need to install 'libsdl-sge-dev', I suppose you've got libcwiid and libsdl-dev installed as well.
You need to make the file executable, either using 'chmod' or in the Permissions tab of Nautilus's file properties dialog.
thanks vanhtu1987!
At least the chmod-solution i should have been able to figure out myself. Stupid me :(
Compilation still doesn't work (now there seems to be a problem with a missing xtst package and collect2, where "ld" gives back 1???), but I guess i would have no advantage of compiling myself compared to using the demo, would I?
Everything seems to work just as it should (including right click).
But I can't figure out how to perform a left click. Pointing at something with my IR-led places the cursor at that position. Holding the position for some time performs a right click. A left click sometimes "happens" but I don't know how to do it.
Probably its a piece of cake, but I can't find how to do it...
Thanks,
Spindoctor
Possibly the IR LED was too jerky (either you had a fairly small monitor, the IR pen was unstable or the position of the Wii was too tinted for the monitor). You'll need to modify the source a bit by going to 'wiicursor.cpp' and looking for 'MOVE_TOLERANCE', set it to some higher value instead of 5 and off you go.
You need libxtst-dev and probably some other. The next time make bails out: just install apt-file, do 'apt-file update' and 'apt-file seach file-name', the package(s) containing that file should show up.
I'd say this tool works best with a real whiteboard, as you've got no mouse and a pretty big screen so the jerky motion shouldn't affect your usage.
thanks once more, vanhtu1987!
If I get you right, you think that the led-spot-position moves, and therefore your program interprets a click as a drag, right?
Well, I don't think this is the case. I have absolutely no problem performing a right click.
As far as I understand the function of your code, it behaves like that:
* ir-spot for less than 0.7 seconds => left-click
* ir-spor for more than 0.7 seconds => right-click
* ir-spot moving => drag
So, if a jerky motion of my led was the reason for my problem doing a left-click, I shouldn't be able to perform a right-click at all.
Also, although I'm not familiar with the output of your code, it always says "MOUSE 1's state changed to 1
Thread is finished."
when I try to drag.
It always says
"MOUSE 3's state changed to 1
Thread is finished.
MOUSE 3's state changed to 0"
when I try to right-click.
When I try to left click it says:
"Thread has been created.
Thread is finished.
MOUSE 1's state changed to 0"
So after all of these thoughts of mine, I don't think jerky motion is the reason for my problems performing a left click.
Concerning my "make-problems":
Thanks for all of your help. The last package you suggested did the rest of the job. It was no problem to compile after installing it.
Thanks,
Spindoctor
[edit] I have constructed my ir-LED-pen, such that it has both, a tip-switch just behind the LED and an ordinary button-switch.
Because of the tip-switch i have the possibility to "click" at a point of my screen very often in a short time period.
When I do this, sometimes a left-click "happens". I realized that the left click always works when this message appears:
"MOUSE 1's state changed to 0
Thread has been created.
Assertion 'data.m_this_thread != 0' FAILED at line '28' of function 'thread_func' in file 'wiicursor.cpp': 'This thread has become immortal, omfg!!!1'.
Thread is finished.
MOUSE 1's state changed to 1
MOUSE 1's state changed to 0
Thread has been created."
However, left clicking does not completely correlate with this message. Sometimes a left-click also is performed without this message...
I don't know...
Spindoctor
@Spindoctor: I updated the cpp branch to revision 31, this should be fixed. Thank you for the report.
Thank you VAnhTu1987, now it works just as it should! Right click function is a big step forward in my opinion!
I'm really looking forward to following improvements, until I finally can use it just instead of a mouse on some special computers!
Thanks,
Spin
@Spin: I was excited about this too. But unfortunately the inherent instability of its IR pointer makes it both harder to implement than a normal touch-screen pointer and more error-prone (this was designed to be a gaming device anyway).
Without the jerky motion, this would make a really nice, portable, flexible touch-screen adapter (even to the point of mounting the Wiimote at the top of a screen, so nothing will block its view). Currently though: I have only been able to find it useful in games (Crayon Physics Deluxe, anyone?).
The Wiimote must be positioned so that its camera cover the whole screen and nothing else to archive near-perfect precision.
Thoughts have been made to improve the precision such as using more than one Wiimote. This is easy to implement, but I figured most people don't have a second Wiimote and having to position both of them is clumsy :( .
Any insights are welcome!.
Spin: By the way, how did you manage to build your pen?. My pen has too big a tip point (that is the LED) and it only has a momentary switch :-) so drawing in the GIMP is about as good as chicken scribbles.
My ambition would be to mount the wiimote on a fixed position just above a screen build in a table. I would like to use the whiteboard-system as an additional control device at a media station in some kind of semi-public room. I think a lot of people would prefer this input device to the mouse, when it's about adding an mp3 to a playlist or something like that.
To realise that, it would be essential to setup the whole software within the boot process. That means, that there should be no mandatory calibration at each start (that shouldn't be to hard), and there has to be a way to connect the wiimote without pressing buttons 1 + 2 each time (I don't know how to do that yet).
My pen:
I bought the same switch-button two times. One I attached as a normal momentary switch and one I attached right under the LED (that means I glued the LED on the button-switch.) I will post some photos and a more detailed description after sleeping, but at the moment I'm much too tired...
By the way: Wouldn't it be better to concentrate all the thoughts and communication about the linux-electronic-whiteboard? I mean, there are messages here under pere negre's article, there are messages on the google code-site, there are some messages in the wiimoteproject-forum and maybe there are even some informations at other places, that I didn't find yet. I don't know, but in my opinion the wiimoteproject-forum would be the best place to focus all informations and discussions. Maybe we would even get an own subsection...
Cheers,
Spin
It's easy to store the configuration, but the thing is: with only one Wiimote, the program has no way to know whether the remote's location has been changed since last time. This, thus, necessitates re-calibration.
We can certainly bypass the whole calibration process using the Wiimote and the sensor bar. We can even draw a rectangle representing the eye of the Wiimote so users can move it around until it covers the whole screen, entirely in real-time.
1+2 is the combination to activate 'discoverable' mode of the Wiimote, we cannot change it using software.
Please post some pictures of your pen :-) I'm kinda curious about what kind of momentary switch can be used as a tip point.
Pege and I made a reply in a 'Mac/Linux developers needed' thread. but no one has answered.
@ VAnhTu1987: Perhaps it would be an improvement to leave the choice to the user, if he or she wants to calibrate or not. But maybe this function is better implemented with a (maybe) future gui...
Concerning the activation of the wiimote: there is no software-solution, i know... maybe someone hast thought on a hardware solution?
I posted a quick description of my pen here. Tell me what you think or if you have questions about it.
I also asked the admin of wiimoteproject to setup a linux-whiteboard-section. Maybe this would be a way to concentrate communication!?
Cheers,
Spin
> I also asked the admin of wiimoteproject to setup a linux-whiteboard-section. Maybe this would be a way to concentrate communication!?
Yes. It would be great!!!
I updated the cpp branch to revision 32 with initial support for configuration saving and loading. Can you try it out?.
Your pen is nice :-) I bursted out laughing at first though (in a good way), it looks sturdy. Unfortunately I haven't got a lot of time recently to make myself another pen.
About the sensor bar, I doubt many people have it (I only have a Wiimote). Although it would make everything a lot easier.
pere negre and VAnhTu1987, I have to thank you once more! You're doing a great job for the community!
I've just tried out rev 32 - storing and loading configuration works fine! Is there a possibility to recalibrate? I guess it would be the most comfortable to do that with a start parameter, like "./demo -cal" if this is possible.
Another thing I discovered, is that dragging arround objects (like windows or symbols) sometimes doesn't work so well. The "dragging process" often breaks off, so I have to point and drag the object again. I don't know if the reason for that is that the LED is not visible for a moment or if there is a software problem (could it be that the buffer is full and therefore the dragging process stops, or something like that?) When this situation is happening, I can see the output of MOUSE 1 switching from 1 to 0 and then from 0 to 1 again.
If it's a visibility problem, there is no need to solve it, but I guess it would be easy to teach the software to ignore very very short mouse button switches.
Anyway, the software you provide is really great - if there comes up a solution for connecting the wiimote, I will install it permanently.
VAnhTu1987, could you explain your idea with the sensor bar once more? I also don't have a wii nor a sensor bar, but a sensor bar would be really easy to make.
... and thanks for your coment on my pen. It was my first attempt, but I wouldn't know what to do different, if I would build another one (except gluing the LED a little more in line for reasons of beauty).
I'm afraid I didn't get an answer to my request on wiimoteproject, but I will try again.
Cheers, Spin
I updated to revision 34th which allows recalibrating: refer to the svn changelog for details and '-h' for a (slightly modified) usage :-) .
@Spin:
You are correct, the IR event was unstable and it just disappears occationally, which whiteboard interprets as a mouse up event (you can visually see it when calibrating). But this doesn't happen much to me. I'll think about this one.
Since the sensor bar is essentially an array of IR leds: There are enough information to correctly determine the location and direction of the Wiimote without having to calibrate, as is the case with the Nintendo Wii. We know the relative 3D location of the wiimote, its viewing frustum and the size of the screen, it is easy to figure out IR LED's location.
Note that it only works with normal monitors though, not projectors (since there is no way to determine the size of a projected screen, users will have to specify themselves). So I don't think it's worth implementing.
Suggestions are welcome.I'm happy with it at the moment (apart from the lack of a decent GUI and multiple pointers *and* the jerky motion... and that little issue above, there is no problem :-) ).
can anyone create ubuntu debs for this??
maybe they could be posted in www.getdeb.net :)
@Davim: I updated to revision 37, which uses autoconf from now on.
I couldn't create Ubuntu package for you since I'm running Hardy, libcwiid got updated and is incompatible with the previous version in Ubuntu Gutsy. Here is the debian directory:
http://download.yousendit.com/F436E54B7559DAAA
Checkout the latest CPP branch, extract debian into program's root directory and run these commands:
autoreconf --install
dpkg-buildpackage -b -us -uc -rfakeroot
That's it!. It should build a proper deb package, given that you've got autoconf, automake and the usual dependencies installed.
I'm in the process of writing a GTK+ GUI for this, which should eliminate the need for command-line stuff and a spare terminal. Hopefully it will be done today.
Updated the CPP branch to revision 38, which sports a GTK+ GUI. One needs to have libgtkmm-2.4-dev libglademm-2.4-dev as additinoal dependencies, but configure should check for their existence anyway.
To build the latest snapshot, these commands are needed:
autoreconf --install
./configure && make
I know the GUI is horrible :-) if someone who is familiar with the GNOME Human Interface Guidelines, or have any suggestions/improvements, that is very appreciated.
http://lavacano.googlepages.com/linux-whiteboard_0.38_all.deb
Van- I'd totally make you one but I'm getting an error---
http://pastebin.com/m2d248731
@Chadwick: You need to install libsdl-sge-dev. Since the default Ubuntu package doesn't have a pkg-config entry so I couldn't have autoconf autocheck for this package (libcwiid-dev doesn't too).
@Pere: I think this blog entry needs updating a bit.
The next GUI feature would be an icon in the notification area :-) .
Updated to revision 39th: New icon in the notification area, allowing the application to run in the background.
Due to glade bug, I couldn't create a message box. When clicking Connect, there will be no message dialog showing up, but in the terminal.
http://pastebin.com/m5c65fa39
I'm getting this now
Sorry, that was my fault. Didn't expect anyone to build a Ubuntu package so early :-) .
The program needs 'main-window.glade', which is basically an XML describing the window. It lays in the /src directory by default. The icon file needs to go along too.
I'm updating it to take that file into account, when installing, it will go to /usr/share/whiteboard.
In the mean time, please bear with running it in the source directory.
Updated to revision 40th: Icons and data files should now go into appropriate places when properly installed.
http://pastebin.com/m20496725
one more time? :-P I have no clue how to work with those advanced Makefiles. of coarse the workaround is to ln -s or mv them to the correct spot but the .deb wont be able to see that.
Updated to revision 41st, it should work now, thanks.
(I didn't bother to check last night :-) .
Suggestions to the GUI are welcome.
http://lavacano.googlepages.com/whiteboard_0.41-1_i386.deb
want to light this baby up like wild fire and post it in gentoo, ubuntu, pclinuxos etc. forums?
If it is anywhere close to usable in your opinion then yeah, it wouldn't be a bad idea.
Vahtu, use the wiki's project page and home page to post all the information regarding building the debian/ubuntu packages...
I think if that info is there it would be more visible.
And we can post the .deb's in the release tab.
I wrote BuildingInstructions on the wiki with general instructions for all Linux distros.
Instructions for creating packages should be left to package maintainers's of that distro IMO, since it would be different with everyone of them.
Next update I will remove the sdl dependency.
@Chadwick: thanks for the package. I uploaded those two to the repository.
@Chadwick: Some people reported a missing dependency with the Ubuntu Gutsy package. I will upload the 'debian' directory and update the Wiki for those who wants to build their own package.
There will be two versions for Ubuntu Hardy and Gutsy, personally I can only maintain the Hardy one but I'll try to keep the Gutsy version correct.
hi again! I just come back from skiing (got my ligaments hurt badly) and see that there was a lot of progress in the last days. Great!
Finally also the linux subforums on wiimoteproject are ready to use.
I think they will make discussion on "linux electronic whiteboard" muc more comfortable.
I'm looking forward to the upcoming postings here:
http://www.wiimoteproject.com/index.php?board=27.0
Cheers,
Spin
The SDL dependency has been removed, whiteboard now use libcairomm for drawing, which should have good performance and behave nicely on lower-end machines.
I haven't committed though, it needs a bit more polishing.
@Spin: Thanks for that, but it seems most people on wiimoteproject use Windoze :-) .
Updated to revision 45th with lots of changes:
- Now became entirely GUI-driven.
- Dropped SDL dependency, everything GUI-related is handled by GTK+ .
- Dependencies: gtkmm-2.4, libglademm-2.4, cairomm-1.0, xtst and sigc++-2.0 .
- Added real-time notification of IR inaccuracies when calibrating.
I also uploaded the Hardy package to the repos (now version 0.2).
I'll think about making whiteboard more resilient to short disappearance of IR signals, which makes drag-n-drop unreliable. It's been happening a lot to me lately.
maybe you could put for example 2 input fields in the gui:
The first could set a variable for short disapperances of the ir signal that are ignored.
The second could set a time variable for a click to be interpreted as right button click.
Depending Wiimoteproject:
It's true, most people seem to use windows there. Anyway, I find the usability of a forum much better than the usability of blog-comments.
However, I know how difficult it is to change a communication-media once another one is in use.
Cheers,
Spin
http://code.google.com/p/linux-whiteboard/ needs some screen shots... if you send me some screenshtos I'll make a post on ubuntuessentials.net
@Spin: I figured out the solution for the jerky motion. The next version will come with automatic optimizations for things you've mentioned, but also incorporate ways to change those settings manually. Basically, of all the 4 issues I mentioned a few weeks ago, only multi pointers will be left alone.
Supporting multiple different languages is also in the list.
@Davim: Weren't you able to compile it yourself?. I will post screenshots if needed, but if you're using Gutsy (which has an older version of libcwiid), just configure it this way:
./configure CXXFLAGS="-DCOMPATIBILITY_GUTSY"
If you want 'make install' to install to a particular directory, add option '--prefix=/path' to configure.
Btw, I'll post news in here and in the wiimoteproject forums. So if anyone has suggestions/bug reports... he can post in the wiimoteproject forum.
@Davim: UbuntuEssentials is nice :-) .
I would be glad to help you with a german translation, if needed.
Cheers, Spin
I've updated to revision 61st, which supports multiple languages. Users who want to contribute translations can contact Pere or me.
Next in the to-do list is removing the jerky motion.
By the way, I will appreciate anyone wanting to maintain the Ubuntu Gutsy package (creating a DEB for Gutsy, that is), or any other Linux distros.
New SVN version available with supports for multiple Wiimotes. But it needs more polishing and I need to cough up a new configuration file format for this, so currently this does not support loading/saving configuration yet. I will upload the new version in a short while.
It works in a seamless manner: Just turn on your Wiimotes one by one, as soon as the last one connected successfully. Calibration will go through all of the available Wiimotes.
If anyone wants a Ubuntu Hardy package, I will make one. It's not feature-complete at the moment so I will upload the new package when I finish it.
Testers for the new feature are very welcome!.
New SVN is available which eliminated the jerky motion, many thanks to "ujs" (http://www.wiimoteproject.com/index.php?action=profile;u=1240) from WiimoteProject forums for his idea.
I will bring back the saving/loading configuration feature soon. Right-click waiting time will also be added.
New SVN version is available: Linux Whiteboard now tolerates short disappearance of IR signals, currently the time is hard-coded. But the next versions will 'guess' the values when user calibrates their Wiimotes.
The latest SVN version now supports pixel-perfect drawing: Previously the IR has to move a certain hard-coded value to generate a click-n-drag event.
Note that Whiteboard became more restrictive when calibrating than it used to be since I've yet to make it heuristically guess an optimal value. Testers for how comfortable the calibration process is are welcomed.
Whiteboard now uses threading to make the GUI responsive when connecting. A menubar was added, the notification area popup menu was improved a bit.
Please note that the 'Settings' section in the main window has no effect currently, until I implement a proper configuration system, which will be coming in a short while.
Some weird bugs in Gtk(mm) made it extremely prone to crash so I had to make a few compromises. I've identified the crash spot but couldn't do anything about it. Testers are very welcome to see how it performs in other computers (wasted several days on this bug :/ ).
New SVN version available which makes Wiimote blinks in a fancy manner when being calibrated :-) .
@Pere: It's been a while since the C branch was updated. Can you consider moving the CPP branch to main and move the C code to a C branch instead?.
If you're using Gutsy, it helps to make packages for Gutsy too. French translations is also helpful.
The latest SVN version supports user-configuration values. At the time of writing, only right-click time is available.
Suggestions on what should be made configurable are welcome. Configurations saving will be functional in a short while.
Whiteboard 0.3 comes with lots of changes from the last major version, 0.2. Here is the changelog:
****
2008/03/27:
- Version bumped to 0.3 .
- Eliminated motion jerkiness.
- Can tolerate short disappearances of IR signals.
- Application's launcher now shows up on the GNOME and KDE menu, and others
which are compatible with the X Desktop Sepcification.
- Added a PNG icon for KDE users.
- Major GUI improvements.
- Configurations saving/loading are back.
- Some settings can be changed in real-time.
- Current Wiimotes being calibrated can blink to notice users.
****
Ubuntu Hardy users can download a pre-built package in the homepage, other users are advised to follow the instruction in the Wiki. Package maintainer volunteers and translators are welcome.
I also filed a 'needs-packaging' submission to Ubuntu Launchpad, hopefully it will be available in the repository soon.
>@Pere: It's been a while since the C
>branch was updated. Can you consider
>moving the CPP branch to main and move
>the C code to a C branch instead?.
That's a good Idea. CPP version should be main.
Great suggestion! I really enjoyed this post and quite satisfied this information.
Very nice work, you've done it quickly than me, also working on the Johnny project !
Something I want to know it's if a red pen works.
I would be happy if I can help you, and I will see your code next days.
Recently I just came across a good article on "100 Linux Tips and Tricks"
Here is its link.
Post a Comment