Ikkakujyu doesn't have a personal statement currently.
28 years old
Gender Not Set
San Diego, CA
Embedded Linux, comics, music, swordplay
Joined: 20-October 04
Profile Views: 822*
Last Seen: 31st May 2012 - 08:39 AM
Local Time: Mar 9 2014, 08:56 AM
27 posts (0 per day)
* Profile views updated each hour
11 Mar 2007
I had to delete my package announcement because I simply can't get CWiid to work with our packaging system. Bloody annoying, but for the adventurous, you can install it from source on your own!
CWiid is a collection of tools to interface the Wii Remote with Linux. It compiles under pdaXrom if you just steal some headers from Debian
This will probably only work in r121 or newer.
First, get the source: cwiid-0.5.01.tgz . Unpack it to wherever you unpack your source.
Other packages you will need:
bluez-libs>=3.9 (check package announcements)
bluez-utils>=3.9 (also in package announcements)
linux-kernel-headers (see foonote)
gawk (in main feed)
bison (also main feed)
flex (main feed)
Once everything's installed, go back to the CWiid source and do the ol' ./configure && make && make install.
To access with a gui: type wmgui. Though it's pretty slow if you enable the accelerometers or extensions.
To actually use it for input: You'll have to insert the uinput module: "modprobe uinput". After that, press 1+2 on the Wiimote and type wminput. The default mode uses the tilt sensors to move the mouse, maps A+B to the mouse buttons, and maps the d-pad to up/down/left/right. Other configs are stored in /usr/local/etc/cwiid/wminput. Pass "-c [name of config file]" to wminput if you want to load another.
For more information, the homepage is here.
Anyway, getting this in a usable package is baffling me. It does some weird symlinking when you make install; it doesn't work in any prefix other than /usr/local. I'm going to bug the author about this, but if anyone else can package this in the meantime, great!
Footnote: Getting the right kernel headers is a task. Here's what I did:
- Downloaded Alien (you'll need perl)
- Got the linux kernel headers from Debian/ARM here.
- Untar Alien and change to its directory. Run "./alien.pl -t [name of kernel package from Debian]".
- Untar the resulting .tgz file and copy everything in usr/include to /opt/native/arm/3.4.6-xscale-softvfp/armv5tel-cacko-linux/include
And you're done. I have an ipk made up, but it's fairly large and I'm only on a 56k connection here. I'll have it uploaded tomorrow.
5 Mar 2007
I realize that I'm asking a REALLY big question here, but I also want to make sure I don't end up doing a lot of work for nothing.
From what I've seen, pdaXrom is using some pretty old software - glibc 2.2, XFree86, gcc 3.6, etc. These are all pretty fundamental subsystems, so I can't just compile a new version and drop it in. This is causing me trouble because some of the software I'm trying to port over (especially CWiid) rely on features only available in the newer versions.
What I seem to be drifting towards now is developing yet another Zaurus ROM, with everything compiled natively (I am very patient). Thanks to u-boot, this is actually quite doable, the only thing holding me up so far is making a kernel that can boot properly (almost there!). The thing is, I'd rather NOT start a project altogether seperate from pdaXrom, because I'm going to have to borrow a lot of code from pdaXrom to make it work, and because I have a bit of loyalty
So, my specific questions are:
-Is the pdaXrom team even thinking about updating glibc, switching to xorg, and building with gcc 4.1/EABI yet?
-Is anyone else interested in a more bleeding-edge, pdaXrom-like distro?
-If I manage something useable, will it be possible to merge it back in to pdaXrom somewhat? (I'd be in charge of keeping it compatible, of course.)
(For those of you who missed the memo, EABI is totally awesome.)
21 Aug 2006
So, I'm looking into the prospect of 3D programming for the Zaurus. Mesa3D looks nice, but slow... on the other hand, there's a fairly old 3D library called Klimt out there.
Klimt is meant to be similar to OpenGL|ES. The whole thing is coded with fixed-point arithmetic. It can display high-poly (around 1000) models at over 100fps on a 206Mhz StrongARM.
There are a couple of threads that point to this library running on the Zaurus... with the Sharp ROM. The Klimt code supplies interfaces for both QT and X11, however, so there's hope for pdaXrom.
Unfortunately, the code fails horribly when you try to compile it now. Probably because it's over two years old. I don't have GCC2.95 lying around anywhere to see if it'll compile under that, or the requisite libraries Klimt needs aside.
I've sent a letter to the maintainer... no idea if I'll get a reply. Is anyone interested in Klimt for pdaXrom? I'd definitely use it to make games if I could just get it to build.
15 Jul 2006
Sooo, I'm having a ball with OZ 3.5.4 and its just-barely-usable native development chain.
Once you get it running, Kobo Deluxe compiles cleanly :D It even works with sound, at least on the Collie. The trick is not overloading the poor thing's limited memory. So far I've gotten it to work at the lowest sound quality (8khz) and al the lowest mixing quality, with reverb turned all the way off. Trying to enable the music made it segfault :( which is a real shame.
There is no noticeable slowdown when the sound is enabled, however :D
The important thing to note is that Kobo Deluxe creates its sound files at runtime, and that it uses a lot of floating-point operations for this... it's also caused trouble with the PlayStation2 port. So it takes a -really- long time to load the sounds, and the Zaurus stops responding while this is going.
Also note that the first time you run it, you have to use the -fullscreen and -nosound options, or else you won't be able to set everything up correctly.
I'd make an IPK for everyone but I have no idea how :/
18 Sep 2005
I've been playing around with BitBake again, and after finally getting a toolchain together, I find out that it's using GCC 4.0. This is a slight problem because OpenZaurus 3.5.3 uses GCC 3.4, so I can't make anything work without upgrading my whole system or building a new toolchain.
The question I'm asking here is, would it be worth it to upgrade, or am I going to run into incompatibilities and such?
Ikkakujyu has no visitors to display.
Other users have left no comments for Ikkakujyu.
There are no friends to display.
|Lo-Fi Version||Time is now: 9th March 2014 - 07:56 AM|