Topics

1

Angstrom & OpenZaurus / Ir Problems With 3.5.4.1

« on: August 04, 2006, 10:32:38 am »

I'm trying to get my zkbdd IR keyboard drivers working on OZ 3.5.4.1 but I'm not having much luck with the IR port. It seems that the 2.6 kernel uses a different set of drivers for IRDA than 2.4 so I'm not entirely sure how all of the pieces fit together. For most keyboards, I need to get the port in SIR mode communicating through a tty device. So far I've tried /dev/ttyS[0-1] and /dev/ircomm[0-1] and though I can open the devices, I'm not seeing any of the IR data.

Before I go down the path of instrumenting all the drivers, I figure I should check and see if anyone has actually seen IR work on a C7xx running 3.5.4.1?

2

Zaurus - pdaXrom / Ir Keyboard Drivers - Alpha Release

« on: October 12, 2005, 12:47:36 pm »

An "alpha" release of my new IR keyboard drivers for pdaXrom RC11 is now available! Supported keyboards are Belkin F8U1500-T and Pocketop. Possibly supported keyboards (the code is in there but I can't test it) are Targus and Palm IR keyboards.

This is a C7x0/C860 release only! Versions for other Zaurii will follow, but I want to make sure there's no serious breakage on the platform I can test on before I release for platforms I can't.

Disclaimer: this software has only been tested on one single Zaurus in the entire known universe. There are many things that could go wrong. If this software breaks your Zaurus, you get to keep all the pieces. Backup, backup, backup, backup!

Installation is pretty simple:

* Backup, backup, backup!

* Install the kernel-modules-input and zkbdd IPKs from my feed at http://kopsisengineering.com/rc11/Zaurus-7x0-860/feed/

* From an Aterm or the console do a "modprobe keybdev" and "modprobe uinput"

* From an Aterm or the console do an "lsmod" and make sure input, keybdev, and uinput modules are listed

* From an Aterm or the console run "zkbdd -h" to get the help page for launching the driver. The general form of the command is "zkbdd -t kbtype".

* Launch the driver (eg. "zkbdd -t pocketop &")

* Start typing on the keyboard

* Post your results here -- good or bad

3

Zaurus - pdaXrom / Best Way To Handle Ir Keyboards In Pdaxrom

« on: October 06, 2005, 12:45:55 pm »

If I'm to stay with pdaXrom, it absolutely must let me use my Belkin IR keyboard with my C760! So I recently hacked up pdaXrom's virtual keyboard applet (Xvkbd) to give me that capability. It worked surprisingly well and got me through a business trip, but it isn't the perfect solution. The weaknesses of the Xvkbd approach are:

* Only works in X (doesn't work in console mode before you "startx" or after you exit X11).
* Has some performance issues (pegs CPU usage at 100% and is still sluggish in some apps).
* Not easy to add support for different IR keyboard types.

Since my return I've been looking at "kbdd" from Handhelds.org which is a user space keyboard driver that sends keystrokes directly to the Linux kernel. It was designed for the iPaq (which has no built in keyboard) so it will take some work to adapt it to the Zaurus. It addresses all three of the Xvkbd issues above, but it does introduces a couple new ones:

* No GUI app to activate/control the driver (easy enough to create but don't expect it in my first release).
* Built-in Zaurus keyboard won't work right when IR KB driver is running (this is the biggest issue).

My initial thinking is that despite those limitations Kbdd is still the right approach, but I'd like to get feedback from other IR keyboard users before I spend a bunch of time coding up my solution. I'd like my work to benefit the pdaXrom community so if you're an IR keyboard user and one approach or the other would result in something you couldn't use, here's your chance to let me know

Also, if you'd like to see support for a particular IR keyboard, feel free to reply with make and model. No guarantees, but I'll do what I can (short of buying new keyboards).

4

Qt/Qtopia / Sharp Zaurus Sdk The Easy Way

« on: July 18, 2005, 05:53:06 pm »

From some of the discussion in the General topics, it's become clear that getting the Zaurus SDK up and running is a stumbling block for aspiring Zaurus developers. In an effort to lower the bar, I've created an entire development environment (based on Damn Small Linux) that has the toolchain and SDK pre-installed in a complete lightweight Linux distro and ready to run.

I've written an article that details the advantages of this approach along with download and installation instructions. You can find the article at
http://kopsisengineering.com/kopsis/SharpZaurusSdkDsl

I had initially hoped that this solution would be radically simpler than the tool installation itself. I'm not entirely certain that I've succeeded in that.  I may just be pushing the complexity into a different area (getting Damn Small Linux and possibly QEMU running) so I'm very interested in getting feedback from anyone who tries my approach.

Note that these tools are for Sharp ROM development only. They will definitely not work for OpenZaurus, and I suspect they won't work for pdaXrom either. If this approach proves to be sufficiently easy for people, then I may try to set up similar DSL based environments for those systems.

Good luck!

5

General Discussion / Qemu Based Sharp Rom X-devel Environment

« on: July 07, 2005, 08:47:52 am »

There's been a good deal of discussion lately regarding barriers to Zaurus software development. One of the issues seems to be the difficulty of setting up a cross-development environment.

I have a QEMU disk image that features a minimal Linux install plus the Sharp ROM compatible cross development toolchain and I'm wondering if it would be worth the effort to clean it up and release it.

There is (or at least was) already a Live CD that had the x-devel tools, but rebooting every time you want to hack a little code is mighty inconvenient and that still leaves Mac users high and dry. QEMU  is a full x86 PC emulator that can run on Linux, Windows, and the Mac. It allows you to run a complete virtual Linux machine in a window on your desktop right along with all your other apps. It's a good deal slower than native execution (about 10 - 15X) but I've found it more than adequate for building Zaurus apps.

Though I still advocate the use of higher level languages like Python and Ruby for Zaurus app development, there are a variety of reasons for folks to want to develop in C/C++. This wouldn't help with the C/C++/Linux/Qtopia learning curve, but at least folks wouldn't have to struggle with tools. How about it? Would this be a big help or are there still too many barriers to development for this to make a difference?

6

Python / Python 2.4 Zaurus Image Available

« on: January 14, 2005, 05:55:17 pm »

The first release of my Python 2.4 image for the Zaurus is now available for testing

• Python Zaurus Image download page

The website has fairly complete download instructions. This hasn't had a huge amount of testing so be careful! (backup critical data, yada yada yada). If you do have problems, you can always go back to the previous version (old versions still available at Sourceforge).

Details of what to expect from this version have been covered in this topic. Feel free to report any problems here (but don't expect fixes until next week). Good luck and have a great weekend!  

7

Python / Creating Python 2.4 Zaurus Image

« on: January 05, 2005, 04:15:58 pm »

I decided the shiny new Cacko 1.22 ROM on my Z needed a shiny new version of Python to go with it, so I'm building up a new Zaurus Python image with Python 2.4. I have the base Python image built and working and it includes all the "standard" Python modules (with the exception of crypt and nis for which I'm still missing libraries) including distutils, encodings, curses, readline, xml, etc.

In addition to the ext2 format, I'll also be releasing this new Python image as a cramfs for folks that want to run off SD (or internal flash) without chewing up so much space. Its not easy for folks to add stuff to the cramfs image on their own, so before I package it up, I'd like to find out if there are any "site-packages" that people think are critical to doing Python on the Z. The obvious ones (to me) are PyQT and pysqlite so I'll be including those. If there's anything else you'd like to see (that won't bloat things up too much), now's the time to ask.

8

Python / Learning Pyqt

« on: December 08, 2004, 09:16:03 am »

Python plus PyQt is a great way to develop Zaurus apps. Python is (IMHO) much easier to learn and work with than C++, but Qt (the class library for Zaurus GUI apps that PyQt "wraps") has a bit of a learning curve. It's not difficult, but if you're just getting started, you'll likely need some references.

If you're new to Python, you'll want to get a handle on the basics of the language before you dive into any PyQt stuff. Dive Into Python is available both online and in hardcopy and provides an excellent introduction to Python for folks coming to Python with experience in other programming languages. The book teaches by example and does a pretty good job of zeroing in on core Python concepts.

Once you have a handle on Python basics, check out the book GUI Programming with Python: QT Edition by Boudewijn Rempt. You can read the whole book online at http://www.opendocs.org/pyqt or snag a hardcopy from your favorite bookstore (ISBN: 0-97003300-4-4). This book is a tutorial that does a pretty good job of walking you through the basics of creating apps with Python and PyQt.

PyQt is a very "thin" wrapper around the Qt C++ class library. The Python classes in PyQt have a one-to-one correlation with the C++ classes in Qt. Trolltech's Qt Reference Documentation is outstanding. Every method in every class is documented and everything is nicely hyperlinked making it easy browse up and down the inheritance trees, type definitions, etc. It's not a tutorial, but once you understand the Qt basics, you can learn a lot by browsing this reference. Note that there are many versions of Qt. The link above takes you to the 2.3 docs which is what the Zaurus Qt libs are derived from.

Qtopia (also from Trolltech) is the GUI "shell" on the Zaurus. Qtopia is to Qt as Windows is to Win32. Qtopia extends some of the Qt base classes so that they pick up extra functionality on the Zaurus. For example the base class for a Qt application is QApplication but apps on the Zaurus should actually use the QPEApplication class from Qtopia. That's going to sound mighty confusing if you're not familiar with object oriented programming, but as you come up to speed on Qt development it will start to make sense. Trolltech has a Qtopia reference that you may find useful. That link is actually for the 1.6 version which is newer than the 1.5 version on the Zaurus. The 1.5 version docs appear to be long gone, but for most things the 1.6 docs are close enough.

There are probably lots of other good references and tutorial out there. Those are what I used. If you know of others that you think are worthwhile, post links in this topic.

9

Site Suggestions, Requests, and Updates / Python Forum

« on: November 24, 2004, 11:17:40 pm »

Python is proving to be a great way to develop Zaurus apps ... quick, easy, develop on any platform including the Zaurus itself, run the same code on Sharp, OZ, and pdaXrom, etc. But we've no good place to discuss it. There's been some great stuff posted today in a topic in "Sharp ROMs" that would be a lot easier for folks to find if it had a better home. For "Everything Development" to live up to its name, it really needs a Python forum!  

10

Linux Applications / Sqlite 3.0.8 For Zaurus

« on: November 24, 2004, 03:56:14 pm »

I've built and ipk'd the latest (3.0. version of SQLite for the Zaurus using the standard Sharp SDK (gcc 2.95, etc.). Should be compatible with all Zaurii running a recent Sharp or Sharp-based ROM.

• download sqlite3_0.8.6_arm.ipk

This was requested in another thread but I figured I'd post the notice here in case anyone else is looking for it.

11

Qt/Qtopia / Using "cancel" In Qtopia Apps

« on: November 23, 2004, 02:57:33 pm »

For a while now I've had a Qtopia application where I wanted to use the "Cancel" button to do something other than close the app. None of my Google or ZUG searches ever turned up the answer so today I decided to dig around a bit in the Qtopia source code. What I discovered is the following very simple trick:

Assuming you have a pointer "main" to your QMainWindow object, you can simply do the following:

Code: [Select]

main->setWFlags(main->getWFlags() | WStyle_Customize);
This causes the QPEApplication class to ignore the "Cancel" button and pass it on as a normal key event. The only side effect that I've noticed is that the "Ok" button will no longer be mapped to "Return" but if your app needs "Cancel" control, that may actually be a bonus.

This is probably old news to most Qtopia developers, but I wasn't able to find this info anywhere. Sooner or later someone else is going to need this so hopefully this post will save them from trudging through the Qtopia source code.

12

Python / Python on CF/SD

« on: November 10, 2004, 12:27:01 pm »

For the impatient:

http://pyqplayer.sourceforge.net/cgi-bin/b...qPlayerDownload

The story:

For the past couple months I've been working on a nice iPod-like media player front end for the Zaurus. It's getting close to where I can release it (GPL'd open source) but I've been struggling with the question of how to let ordinary Zaurus users run Python apps.

There are Python binaries/libraries available for the Zaurus (Python for arm-linux) but the versions built for Sharp or Sharp-compatible ROMs have to be installed in internal memory (or an ext2/ext3 formatted CF/SD card) to work properly. To make matters worse, for my app you'd need to install a bunch of those packages and it ends up requiring some knowledge of Python and using a lot of internal memory.

So instead I built an almost complete (missing the Tk stuff and some test scripts) Python 2.3 distribution for Sharp and Sharp-compatible ROMs. Then I packaged all that up into a single file that contains an ext2 image of the Python installation tree. Thanks to some scripts and the magic of "loop" mounting, you can toss that image on any FAT formatted CF/SD card (with enough free space to hold a 50 MiB file), install a 1.2 MiB IPK, and you'll now have a relatively complete Python 2.3 distribution on your Zaurus without chewing up the 30+ MiB of internal memory that it would normally take. Note that you can install all of this without ever seeing a command prompt

My media player still isn't quite ready for prime time, but I'm releasing the Python image and IPK now in hopes that folks with some Python knowledge will try it out and report any problems.

This has been tested on an SL-C760 running Cacko 1.21a and an SL-5500 running a standard Sharp 3.13 ROM. It should work on other Sharp-compatible ROMs. It will probably not work on OE or pdaXrom.

I've found that Python with PyQt (included in this image) is by far the easiest way to write Qtopia applications for the Zaurus. And it has the added advantage that you can develop directly on the Zaurus! If you know or want to learn Python, give this image a try and let me know what you think.

13

Accessories / IRK for Belkin F8U1500 Available

« on: October 29, 2004, 03:39:57 pm »

I've been using a Pocketop keyboard with the Zaurus ever since the first release of Craig Graham's IRK. I've always liked the Pocketop's small size but the lack of a number key row really hurts typing speed ... especially when writing code.

So after recently trying every IR PDA keyboard I could get my hands on, I decided my favorite was the Belkin F8U1500. It's almost the exact same design as the Pocketop but a little longer and wider with a full row of number/punctuation keys.  Keyspacing is a little tighter than a standard laptop, but the layout is sane so it's not hard to get used to. The mirrored PDA stand that comes with the keyboard is a little flimsy, but with my C760 I don't have any need for the stand. Just swivel the screen around backwards and line up the IR ports. With the stand discarded, the Belkin is much more compact than the Targus (which was my second choice) and it has regular arrow keys instead of that funky Targus joypad thing. And to really clinch the deal, Amazon has the Belkin in stock for $40 with free shipping!

There's only one minor problem with the Belkin ... IRK 0.11.0 doesn't support it. Luckily Craig has been good enough to release the source code for IRK so it was a pretty simple matter to go in and hack it up to work with the Belkin. Since I'm sure there are other folks out there who would like to be able to use this keyboard, I'm releasing my Belkin version of IRK as IRK 0.11.1. When Craig finishes IRK 2 I'll be happy to merge this in so we'll have on IRK that supports everything, but until then this hacked up version should do nicely.

You can download my Belkin IRK from

• http://kopsisengineering.com/irk-zaurus_0.11.1_arm.ipk

and if you'd like the source code just grab

• http://kopsisengineering.com/irk-current.tgz.

A few things you need to know before you install:

• If you have a previous version of IRK installed, you must uninstall it before installing this one.
• The Belkin support replaces the Targus support so this won't work with a Targus keyboard (Pocketop is still supported).
• This is built for standard Sharp ROMs and tested on Cacko 1.21a. It should work on most Sharp-like ROMs but if you have OZ or pdaXrom, you're on your own.
• Not all of the special functions on the keyboard work. I'll work on improving that but I wanted to get this out sooner rather than later.
• This is unsupported, untested software! Back up anything you can't afford to lose before you try it!

Good luck. If you have problems, post here and I'll do what I can to help. Thanks and credit for this should really go to Craig Graham for writing and releasing IRK! If Craig ever decides to accept donations for IRK I'll be first in line

14

Accessories / Wearing out flash memory

« on: October 05, 2004, 04:54:58 pm »

The following is a copy of a post I wrote addressing the question of flash memory "wear". I'm reposting it to it's own topic since it may be of interest to people not following the PDF reader topic (yes, I went a wee bit off-topic  ) where it originated. The original question was whether it's a good idea to routinely use a swapfile on a CF or SD card ...

Flash life is typically between 10K and 100K erase cycles per sector (depending on the flash memory technology used). When data (let's say a byte) is written to flash what really happens is that the chunk of flash (sector) where the byte is to be written first gets read into RAM. The byte in question is then changed in the RAM copy, the sector in the flash is erased back to all zeros (or ones depending on the technology), and then the RAM copy of the sector is programmed back into the flash. As a result, writing 512 contiguous bytes may be done with only a single erase cycle. Writing the same byte 512 times could be as much as 512 erase cycles.

Good flash cards combat wear by using wear leveling techniques. Wear leveling works by spreading the writes out amongst all the free flash sectors. Let's say you have one sector (perhaps in a swapfile) that's getting hit over and over. The logic in the card will actually map that logical sector to a different physical sector each time a write happens. That means that if the life of a sector is 10K cycles and the card has 128M sectors (typical for a 64M card) then the card can theoretically survive 1.28G writes. Now, wear leveling generally only works on "free" sectors so keeping your card 50% full would cut that number in half. Keeping your card 99% full is going to get you back down close to that 10K - 100K number since there are few free sectors to share the erase/write cycles.

When using flash as a file system, data is typically written in big chunks - and only when the user does something. User's aren't very fast (relatively speaking) so this keeps the number of erase cycles to a minimum. When you use a swapfile, the flash can get hammered at much higher rates. Note that Linux will often use the swapfile even with plenty of free RAM available so you don't have much control over the level of activity your swapfile will see. Needless to say, using a swapfile occasionally on a CF or SD card with plenty of free space isn't likely to have a noticeable impact on the life of your card. On the other hand, using a swapfile continuously on a relatively full card could significantly shorten its lifespan.

As for the question of internal memory, the SL-5xxx series use RAM for the internal file system so there are no worries.  The SL-Cxxx series use flash for the internal file system so there *is* a risk of intense activity wearing out the internal flash. And all Zaurii use flash for the operating system but it's typically only erased on a reflash and not too many folks are going to reflash 10K times.