Topics

1

Zaurus - pdaXrom / Wiimote On Zaurus!

« on: March 12, 2007, 03:11:46 am »

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.

2

Zaurus - pdaXrom / Roadmap For Pdaxrom?

« on: March 06, 2007, 01:32:58 am »

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

3

Zaurus - pdaXrom / Revisiting Klimt

« on: August 21, 2006, 05:01:55 am »

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 Website

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.

4

Angstrom & OpenZaurus / Kobo Deluxe With Sound

« on: July 15, 2006, 07:43:04 pm »

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 :/

5

Open Embedded / Which Version Of Gcc To Compile Against?

« on: September 18, 2005, 12:20:05 pm »

Alrighty.

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?

6

General Discussion / Psp Power Brick!

« on: April 09, 2005, 10:20:58 pm »

Well, the Zaurus and the PSP use the same size power connector, so I gave this thing a shot. It's a pretty small, 3600mAh battery.  Seems to work just fine, but I haven't given it an extended test drive yet.  My Zaurus hasn't exploded yet, so that's a good sign...

Among other places, you can get it here: http://www.price88.com/product_info.php?pr...3016&tc=Froogle

Or here: http://www.baysoftgames.com/powerbrick.html

I found mine at the local GameStop.

It's hard to tell, but judging by the size and weight, it's probably a lithium-ion battery. NiCd batteries at that size tend to have a much lower life, but ya never know.



EDIT: The back of the battery says 3.6 volts, which is common for radio-controlled cars, which tend to use NiCd/NiMH... also, it does seem a little too heavy for Li-ion, but I wouldn't really know. The brick does get a little hot at first, but after having it plugged in for five hours it was pretty cool, so I suppose it charged all the way and shut off. The only indicator on it is a small LED that flashes when it's plugged in.

Checking the voltage with a... volt-checking thing... it outputs 5 volts, just like the regular power supply. It gets a teeny bit warm where the cable-to-PSP (or Zaurus) plugs in, so maybe it has a circuit to step the voltage up?


EDIT AGAIN: Oh yes. The brick is designed to use the standard PSP AC adapter. The Zaurus one works fine, and I'm actually using one for an iPAQ. Also, the PSP's battery is 3.6 volts, and charges at 5 volts; it's quite possible that the Power Brick's battery is a standard 3.6 volt Li-ion with the voltage stepped up. Which'd be nice, because I don't really like the whole "full discharge" thing with NiCd, and there's no way to tell how charged up the brick is.

7

General Discussion / Yep, I broke it

« on: October 27, 2004, 01:22:45 am »

I seem to have bad luck with PDAs. I broke my iPaq putting Familiar on it, and now I've managed to turn my Zaurus (SL-5500) into a brick.

Don't ever try swapping batteries in the dark. There's no way to tell which way it's facing. I  managed to put mine in upside-down. The unit won't power on. Plugging in the AC adapter makes the charging light go on for a few seconds, then it goes out.

I tried reflashing (OpenZaurus 3.3.5), and it goes through the process, but it still won't turn on. Haven't tried any other ROMs yet. I read elsewhere on the board that you can fix a bricked Zaurus by reflashing with the original Sharp ROM. Haven't been able to try it yet because I only have a 16mb CF card.

Is there any hope, or am I gonna have to send it back to Sharp?