Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - derekp

Pages: [1] 2 3 ... 11
Gemini PDA - Hardware / Teardown?
« on: May 09, 2018, 08:51:21 am »
Quote from: Rosie
I used a flat bladed screwdriver (the one on my Leatherman) to open the cover.  Given a bit of care and gentleness it doesn't seem to have done any harm.

I found that the covers (front and back) pop off pretty easily if you slide your fingernails and pull up from the front lip of the cover, instead of the back.  At least on mine it is even easier than using the tool when prying from the opposite direction.

General Discussion / Maemo On Zaurus?
« on: October 24, 2007, 12:32:49 pm »
Has anyone managed to get Maemo (the UI running on Nokia N-series) going on the Zaurus yet?  Maybe by using pdaxrom and pulling in the stuff that runs under X from maemo?  I was thinking of getting the Nokia N800 or 810, but I figured a good way to test-drive it would be by running the OS on my Zaurus.

Linux Applications / Got A New Language For You...
« on: January 12, 2007, 08:54:44 pm »
Well, it's been a while since I've posted here, but thought I'd share one of my latest creations with you.  I've been working on a light-weight language, called 2e, that could be a good fit on the Zaurus (since it is rather small and light weight).  So far, I've got it fairly functional as a general-purpose programming / scripting language, but the built in funciton library only has text based i/o functions at the moment.  It is set up to support dynamic loadable modules, and I have plans on throwing some gui libraries together (most likely just hooks into qt and/or gtk), once I get a bit more gui programming under my belt.

Anyways, it is at if you want to check out what I've got done so far.  If anyone is interested in assiting with gui librarys for it, any input is welcome.  But I need to document the loadable module interface a bit more.

General Discussion / Is There Ever Going To Be A New Z
« on: October 16, 2006, 09:59:02 pm »
Actually, I'd rather not have one with an x86 compatible chip, even if it could be made with the same power characteristics of the embedded arm / xscale cpu's.  The reason?  If a handheld is binary compatible with the desktop, then most likely we will see it running desktop versions of software, instead of programs specifically designed for a handheld unit (this goes for both Windows and Linux software).  The problem with this, is a lot of desktop semantics don't translate properly to a handheld (i.e., assuming the presence of two / three mouse buttons, along with full keyboard / large screen, lots of ram / storage, etc).  Whereas when developers have to specifically port an app to an alternate platform, they are more likely to also take into account the target form factor.
An example of this is the difference between the feel of a Zaurus running Qtopia / Opie, v.s. running X11.  When I'm running in X mode, I tend to use it as a mini laptop (or laptop replacement), whereas when I'm just using the Qtopia or Opie environment, the unit feels like, and I use it as, a PDA.  However, I can concede that there are times when I would rather have a laptop replacement, but most of the time I need PDA functionality and usability.

New products and alternatives / Open Linux Mobile Phone By Trolltech
« on: September 15, 2006, 02:15:11 pm »
One thing to keep in mind with this greenphone product, is that it is not an end-consumer device.  I've heard a lot of people complain about the high price, lack of this or lack of that (wifi, etc..).  But keep in mind that this was a special limited run of units (I think they only ordered 1000 in the initial run).  That automatically creates a higher per-unit cost.  And, if you compare this against the normal cost of evaluation / development platforms, it really is about right in line.  I've seen arm / xscale dev boards go for around $1500 or so.

Now, it would have been nice if Trolltech would have decided to make this a consumer device, with better power management (longer talk time / standby time), better radio, more expandability.  But then they would be in compitition with their customers (the handset makers that they hope will start selling qtopia phone edition based phones).  Also, the average person wouldn't buy it, because even with higher production runs it would still cost around $300 to $500 (that's about the going price for a Treo).  The only way a consumer would get this is if it was offered subsidized by a carrier (i.e., so it appears as a "free" phone).

Personally, I think I'm going to go the do it yourself route.  I'm not going to go as far as the Pocket Penguin group here is doing (buiding the circuit boards from scratch), howerver I was looking at getting a GumStix module, lcd, gsm module, and pack it all in either a regular phone housing (you can get the housings fairly cheap), or gut one of those $5 toy phones and use that for a housing.  Total cost doing it this way would be around $450 or so, but it won't have that "finished" look and feel.  Other option is to pick up a Motorola A780 and load up the userland replacement from open-ezx project.  That may be the easier route, but then I'd be lacking a few hardware features.

C1000/3x00 Hardware / Zaurus C3100 And Monitor
« on: September 08, 2006, 03:16:43 pm »
A while back, I saw some pcmcia vga cards (intended for laptops).  I would think that you could combine this with a cf -> pcmcia adapter, and as long as the card is using a standard chipset you should be able to get X11 going on it.
Two problems that you could run into, is:
1) the CF slot only has 3v, whereas pcmcia also has 5v.  Some cf -> pcmcia adapters have an additional power plug to provide 5v though.
2) I can't tell if the currently shipping pcmcia vga cards are the older pc card spec (which matches up with cf slots), or if they are cardbus.  From what I understand, pc card is equivilant to an ISA bus, where cardbus is more like a PCI bus.

User Request for Applications / Losetup
« on: September 08, 2006, 01:57:51 pm »
anyone seen the source code around, I cant seem to find it anywhere...
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

It's in the util-linux package, at [a href=\"][/url]
Look in the mount directory, from their you should be able to do a "make losetup".  I might have the binary floating around for the zaurus, I'll check when I get home tonight.

PocketPenguin / Body Design
« on: August 25, 2006, 04:22:31 pm »
Nice Idea, but only practical for a basic tuxphone. .  not for a PDA.
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

I was thinking that there is a couple of projects going on, and if you can get to a basic cell phone form factor fairly quickly, then work on the ultimate one while you have something in your hand.  I have also seen toy cell phones in a few other form factors, plus you could mod the case slightly to get a bigger screen (i.e., if you get one of the "flip" toyphones, you could hack off most of the flip but keep the hinge, etc.)

Another idea that might work a bit better (but still not big enough) is to get a replacement phone housing (esp. one for a pda phone).  They usually run anywhere from $15 to around $60 depending on the quality.  Here's one for a treo 600 that might come closer to fitting the bill...
[a href=\"][/url]

PocketPenguin / Body Design
« on: August 24, 2006, 08:48:00 pm »
Two more things...
First, one of my biggest usability issues with a pda is constantly stowing / retreiving the stylus when switching from key input to touch screen.   What would be nice, in addition to a stylus silo, is a clip at the top of the screen that you can clip the stylus on temporarily while using the keyboard.  A second option would be to have an eye hole at the top of the stylus so it can be connected to the wrist strap connection on the pda via a peice of fish line or similar.

Second thing, for those that are looking at stuffing everything into a phone factor.  Instead of trying to figure out how to fabricate a case, just pick up one of those cheap 2 dollar toy cell phones they make for kids.  They usually have a keypad on them hooked up to a small circuit board that makes beeps & buzz sounds.  Rip out the guts, replace it with the PPZ board, and there you go.  Cut out the fake display and plop in your lcd, and wire the toy keypad (which actually works) into your gpio pins or keyboard controller.

PocketPenguin / Make A Ranking ?!
« on: August 18, 2006, 03:28:49 pm »
I had an idea that could help solve some of the over design issues.  I know that making everything modular was rejected, because it would add too much complexity / bulk with the various connectors, etc.  But, what if the bulk of the core was made into a standard pcmcia card form factor?  I know that a lot of manufacturing lines have templates for pcmcia cards, which simplifies the process for putting out a few prototypes.  Here's what I envision:
The cpu, bluetooth, memory, cf / sd slots, etc. all go into a pcmcia card shell (modified slightly so someone doesn't accidently try shoving it into a laptop...).  This is the core module.  The screen, keyboard, battery charger / power supply all goes into a sperate shell.  That way, if someone wants a larger clamshell / mini laptop, they can get that shell.  If you want a tablet, use a tablet shell.  A phone would use a phone shell.  That way, you can take your core module, and put it into the device shell that is appropriate for what you want to do that day.
For example, I could see keeping the core module in a phone shell most of the time, but when I go on a trip, go ahead and pack the oversized clamshell in a suitcase, and transfer the core module from phone to clamshell at the hotel.  Or, if I'm going to be in meetings on the run, use the tablet shell.  Either way, all the core functionality will transfer to each device easily.
The only drawback I can see is that using a pcmcia-type shell may add a bit to weight / bulk, but I think the flexibility would be worth it.  And, if you do get someone to mass market this, for the end consumer it may be easier / cheaper to go and replace one of the shells if it gets damaged, than to replace the entire pda.

C1000/3x00 General discussions / Usb Keyboard Mapping
« on: March 30, 2006, 10:54:02 am »
you can use xev to determine scancodes in X.

Actually, xev does the same under X that showkey does in a Linux console.  Problem is, it is interactive, requiring manual inspection of each key.  What I'd like is to run a command to dump the mapping of kernel scancodes to X keycode numbers.  I think this compiled into the X11 keyboard driver, I'll have to dig through some source code to figure it out.
Also, after doing some digging, it turns out that a modified usbkbd.o driver may not be needed, since the same thing can be accomplished by using setkeycodes.
Here's what I've figured out so far:
The keyboard generates a raw scancode, from 0 - 255, for each key.  The kernel has a map that maps these raw codes into kernel scancodes (this is what you see in the large array in usbkbd.c in the kernel source).  These can also be set / displayed by running setkeycodes / getkeycodes.
Secondly, the mapped kernel scancode (or keycode) is assigned meaning by one of several methods, depending on what is using the keyboard.  This layer is responsible for interpreting not only the keys, but also key combinations (shift, alt, ctrl, etc.)
 -- for Console-based programs, this layer of mapping is handled by loadkeys / dumpkeys.
 -- for Qt Embedded apps (i.e., Qtopia), it is handled by /opt/QtPalmtop/etc/keycode.tbl
 -- under X11, this is set (or displayed) using xmodmap.  The settings are stored in the running X server's environment, so any changes need to be re-applied when X is restarted.  This is ually done by having a startup script (such as .xinitrc) call xmodmap, pointing to a file such as xmodmaprc.
The difference with X11 is it doesn't look at the kerrnel scancode/keycode, but instead it has it's own mapping of raw scancodes to X11 keycodes (I think -- I guess I could test this by changing some of the kernel scancodes, and seeing if that affects X11 apps).

C1000/3x00 General discussions / Usb Keyboard Mapping
« on: March 29, 2006, 11:39:29 pm »
I presume your fix works for the Sharp and Cacko ROMs?  Does anyone know what would need to be done to do a similar thing for pdaXrom?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=120978\"][{POST_SNAPBACK}][/a][/div]
It should work on any Qtopia-based roms.  For X11-based roms, X11 uses a program called xmodmap to load / change key mappings, which is effective for that particular X windows session.  These are usually saved in an xmodmaprc file or similar.  To modify this file, you'd have to match up the scan codes from keycode.tbl with the equivilant entries in xmodmaprc.  However, there is also another layer of indirection, in that raw scancodes (for example, as specified in usbkbd.c) are mapped to different X11 keycodes that xmodmap uses.  I haven't loaded up pdaXrom, but I do have X/qt installed, so I'm going to attack that next.
BTW, my modified usbkbd.c breaks from tradition, in that since I was running low on scancodes, and didn't want conflicts between the internal and usb keyboards, I use the same scancodes for the top number row as used on the numpad.  So the consequence of this is that if you have an X program that treats the numpad different from the top row of numbers, then those programs will break.  Of course, I can't think of any examples off the top of my head.
I'll update this later on when I get some working xmodmap enteries, unless someone else can beat me to it.  I'd like to put together a script to automaticaly convert a keycode.tbl file into an xmodmaprc file, but they use different symbol names (not to mention different scancode mappings).  Maybe that'll will be my next weekend project, once I figure out how to query the X server for raw scancode to X scancode maps.

C1000/3x00 General discussions / Usb Keyboard Mapping
« on: March 29, 2006, 05:36:29 pm »
Just recently upgrade to a c3100, and have been playing around with getting standard usb keyboards working.  Well, I looked through all the posts regarding fixing the key mapping, and the general conclusion seems to be to use keyhelper to remap keys in userspace.
Well, I've put together a slightly better approach.  My goals were the following:
1) Make sure it's not qt-only
2) Allow an external keyboard to be mapped properly, without messing up the internal keyboard mapping
3) Do number 2) without having to switch between maps.
4) Get any dead usb keyboard keys working.

Here's what I found.
The one dead key I was woried about (backslash \ pipe) wasn't mapped in usbkbd.o, so I fixed that in the kernel source, and recompiled the usbkbd.o module.
Second thing, there weren't too many other keys that were mapped wrong on the usb keyboard that conflicted with internal keys (I checked the scan codes for all keys on both keyboards using showkey).  So for those, I fixed the key maps in /opt/QtPalmtop/keycode.tbl.
Now, the main keys that conflicted were the number keys.  So, for example, I couldn't remap shift-2 to be an "@" symbol, otherwise the internal keyboard would have the wrong map.  So for these keys, I ended up hacking away at usbkbd.c in the kernel source again, and ended up assigning the top number keys to the same scancodes used by the right-hand keypad, then edited entries in keycode.tbl to match.
The result is a replacement keycode.tbl and a usbkbd.o kernel module that allows the use of both the internal keyboard, and a usb keyboard without having to swap keymaps around, and no need for keyhelper.  The values that I used in keycode.tbl can be used to build the equivilent files for both X11 and console (for console key mapping, you'd have to use loadkeys I think).  I haven't got that far yet.

Anyhow, when I've been using this setup for a few days, and it seems to be working well.  If anyone is interested, then as soon as I get my other server up (it's got a bad CPU fan), I'll grab the patches for usbkbd.c and keycode.tbl, and post them here, along with an ipk.

edit: To use the attached files, unzip the attachment, then put usbkbd.o in /lib/modules/2.4.20/kernel/drivers/usb/usbkbd.o  and put keycode.tbl in /opt/QtPalmtop/etc/keycode.tbl (of coures, backup the existing ones first).

C1000/3x00 General discussions / New Sharprom Image
« on: March 29, 2006, 05:14:31 pm »
Could you post a tar image of the internal rootfs image?   The one that is on /dev/mtdblock2 (at least, on the 3100's it's there).  /dev/root should be a symlink to /dev/mtdblock2.
To get just the internal rom image, without grabbing everything else that's mounted under it, you can do the following:
# Mount a read-only copy of /dev/mtdblock2 somewhere
mkdir /mnt/tempmount
mount -oro /dev/mtdblock2 /mnt/tempmount
# tar up the image
tar -cf /hdd3/sl-c3200-root.tar
gzip /hdd3/sl-c3200-root.tar

# cleanup
umount /mnt/tempmount
rmdir /mnt/tempmount

This way, it will have everything but the kernel.

C1000/3x00 General discussions / Hdd3 In Files Tab On Qtopia Desktop?
« on: March 17, 2006, 10:55:57 am »
Look at this topic:

Apparently, the mappings are hard-coded into qtopia.  That is, the devices are hard-coded, and it will look at where that device is currently mounted (via /etc/mtab) to figure out what to put in the files tab.

Pages: [1] 2 3 ... 11