Messages

1

Zaurus - pdaXrom / Pdaxrom Rc12 For Sl-c7x0/7500/c860/c1000/c3100

« on: November 12, 2005, 12:39:57 pm »

Can someone clarify the status of PyQt on RC12?

It's not in the default feed, although the qt (non-embedded) libraries seem to be there.  And pygtk is there.

A search on this forum reveals a version on zaurus.spy.org, in http://zaurus.spy.org/feeds/cacko/x11/feed/, but this was built against python 2.3 and RC12 uses python 2.4.  I actually extracted the version above and moved the libraries from /usr/lib/python2.3/site-packages to 2.4 by hand, and doing this works for some sample pyqt programs in the PyQt samples (analog clock etc) but e.g. fundamental stuff like widgets.py crashes, so I'm assuming there is some basic incompatibility between SIP in 2.3 and 2.4.

There's Mickey's very complete builds at vanille.de, but these seem to all be based on Qt/Embedded instead of Qt/X11 and this is obviously the whole point of pdaxrom.

I could take the trouble to build it myself I guess, but I'd prefer not to if someone has already gone about it, or has plans to in the near future.  This is the only thing keeping me on Cacko at the moment, and since my test-drive of RC12 has otherwise gone very well, I'd love to be able to switch.

2

Software / Kde-pim/pi 2.0.16 Release

« on: February 15, 2005, 03:34:55 pm »

You can select which buttons you want already (though you need to restart), and the arrow always increments by the number of days currently displayed (so it'll give you next week in week view, and month in month view, etc). I'm not sure I get what you want.

Nope.  From the week-within-month view the ">" button right above the view  (ie: right next to where it says "February '05") goes a month ahead, skipping over 3 or 4 weeks.  The ">" button in the top row (the one alongside the month, journal etc buttons) behaves correctly, going only a week ahead.  But the ones right on top of the view jump a month ahead even though you're viewing a week.  This is true both on the 2.0.6 version on my laptop as well as the 2.0.4 version on my Z.

What I'm after, besides fixing/rationalizing the button behavior, is to make the new nifty week view a fully-fledged view with its own viewing button rather than merely a state of the month view (which to me makes no sense).  It's basic human interface guidelines stuff that if you have a button at the top of the page that is for a "Month view" that when I click on it I always expect to view a month worth of dates.  But now if I've left it in the week view state and I want to see a month view, I have to (1) hit "M" or click on the month icon, and then (2) move the mouse/grab the stylus (no keyboard shortcut for toggling between week-of-month & month?) to the far right and click the tiny number "7" in order to toggle back to the full month view I wanted in the first place.

I didn't know you could select which buttons appeared, so that's good news.  Thanks.

3

Software / Kde-pim/pi 2.0.16 Release

« on: February 15, 2005, 01:52:49 pm »

Whoa...did I miss the stealth week view in the release notes?  I clicked on the week number on the left in the Month view, and I get a (Palm/Outlook)-style 2-column week view!  This is great!  It's not really highlighted in the release notes, or maybe I just glossed over it...

I'm thrilled just to have it, but now that I'm using it, it would probably work better as a first-class view (like day, workweek, month) with its own icon.  Switching back-and-forth from month-view-in-month-mode and month-view-in-week-mode is cumbersome.  When I hit the "month view" button and context-switch from some other mode (journal entry etc) I don't expect to see only a week's worth of events.  Plus the navigation metaphor is broken: the "<" and ">" buttons on top of the view take you to the next <b>month</b>, so from the week beginning Feb14 I get to the week beginning Mar 14.   Whereas the same buttons on the window toolbar go to next week and next month.  It's unintuitive and confusing.

While some people may find navigating to this-week-in-next-month useful, the most likely thing for a user to want to see is the next week and there's no button to do that.  In that sense there should be 3 buttons in week mode: ">" (next week), ">>" (next month) and ">>>" (next year).

So I'm lobbying for 1) making it an independent view with a button on top, and 2) allowing the user to select which buttons appear on the toolbar, since they already run out of room in portrait mode on my C860.  I never use the journal & list view buttons, for instance, which would allow me to see the navigation buttons without having to click through to the continuation dropdown menu.

Also in the suggestions category, I find the "dashed line" for the half-hour demarcation in the Week view a little disorienting/distracting.  (I'm an advocate for Tufte-style visual minimalism in UI design).  What would be nice is to have an option to set the line color, weight & style for the main grid and the 1/2 hour lines.  (Since you're presumably just setting Qt::PenStyle anyway to get the dashed lines this shouldn't be particularly burdensome.)

4

General Discussion / SL-C860 stylus-digitizer weirdness

« on: January 31, 2005, 12:14:09 pm »

That is because you're 860 is a PXA255, not a 250. I believe the SL-C700 is the only one of the C series with a PXA250 chip. If you run it at on the Default PXA250 you're underclocking the Z.

Aha.   This is the problem then: I don't think I ever knew what type of processor I had; all I knew was that I had never changed the clocking.  I was therefore assuming that since I'd never changed it, it was at the default.

So here is the problem: even after I change the clocking to PXA255, every once in a while (usu. after a suspend-resume) it reverts back to a PXA250.  I get this about once/day (may be happening more but it's only really noticeable in FreeNote, so I discover it only when I need to doodle).  This has to be some sort of bug...

5

General Discussion / SL-C860 stylus-digitizer weirdness

« on: January 24, 2005, 12:05:30 pm »

This is odd...

I experienced this jitter along the long axis for the first time this morning, after doing pretty much what I do every morning -- swapping the bluetooth CF card out for the WiFi, doing various synchronizations with my home machine (KOPI, sitescooper files, etc) and then putting the bluetooth card (Socket G) back in.

Next thing I know I'm making a note in FreeNote/Qt and the lines are super-jittery.

Weird thing is that I've never ever moved the clocking on my 860 from where Cacko defaults it ("Default (PXA250)").  I'd never heard of this jitter problem so after a brief moment of panic  I played with various levels of resort (reboot, power off and remove battery, etc) which did not fix the problem.

One thing I *did* notice though was that the jitter went from the occasional blip (drawing a straight line has one or two jaggies) to a chaotic mess (attempt to draw a straight line produces a 1-cm wide path of scribbles) when I had the bluetooth card in.  Perhaps the Socket G is putting the Z in some sort of powersave mode that exposes the bug?

Odd thing is I've been using the Z with this exact configuration for some time (on Cacko 1.21a and 1.22 since it's release) without incident, and AFAICT I didn't do/change/install anything else that would cause this to suddenly start happening.

Now that I've switched the clocking to "Normal" ("Overclocked" works as well) everything is fine, but when I go back to Default (PXA250) or "Power Saving" I get jitter, and now it happens whether or not the bluetooth card is inserted.  The only stable modes seem to be 'Normal', "Default (PXA255)" and "Overclocked".

6

Software / Anyone Using Their Zaurus With A Nokia Smartphone?

« on: December 17, 2004, 11:33:07 am »

I am using mine (Nokia 6230) with my Z over Bluetooth, mainly for the GPRS.  I haven't had time to experiment with OBEX, but ultimately I'd like to get the KO/PI suite syncing phone #s with the phone as soon as that code is a little more stable.

Setting up the GPRS was extremely easy, I would recommend caution for anyone thinking of using the 6230 for GPRS-over-Bluetooth, as it seems to have some sort of serious hardware flaw.  It can maintain a GPRS connection for low-bandwidth browsing like WAP, but the higher-throughput rates of real browsing & downloading appear to blow out the phone's UART in some sort of nasty way, which causes the phone to reboot itself, or sometimes just drop the GPRS connection.

A little Google searching suggests that this is a known problem, but Nokia USA level 2 data support swears up and down that it's the first they've heard of it from anybody. (Their first line of email support also claims that they "do not support connectivity through third party devices", which is somewhere between highly misleading and patently false given the language they use to market the phone.)  So I'm about to send in the phone to the service center for maintenance -- we'll see how that goes.

Otherwise I think it's an excellent little phone, although the plastic screen is kind of cheap and scratches easily/instantly.  It boots really quickly (and because of the above problem I see it reboot quite a bit).  I looked at the 6600 and went for the smaller form factor of the 6230 since to me the whole point of Bluetooth -- especially if you're a Z owner -- is that you don't need all that PDA functionality, or the screen real estate on your phone, because all of your browsing and PDA functionality can be done directly on your Z.  Between a BT headset (for voice calls) and the Z over GPRS (for browsing) why ever take the phone out of your pocket?

I was hoping to get a simple Bluetooth phone without silly complications like a camera, but pretty soon it seems it will be impossible to buy one.  It's hard enough to find a small BT phone that isn't a full-blown "Smartphone"/PDA-style device, since cordless syncing to a laptop/desktop, and wireless headsets, is all marketers seem to think BT is good for.

7

Sharp ROMs / Scp Not Working On Cacko 1.21b

« on: December 04, 2004, 12:05:18 am »

Amazingly enough if you're using Cacko there's still a copy in /usr/lib.rom even though you've blown away the business copy in /usr/lib.  Quite thoughtful of the rom designers.  So all you need to do is this (as root):

#cd /usr/lib
#mv libcrypto.so.0.9.7 libcrypto.so.0.9.7.bk
#ln -s /usr/lib.rom/libcrypto.so.0.9.7

(Obviously if you want a full-fledged copy instead of a softlink that works too.) This was suggested in another thread, but with the wrong advice about ldconfig, which you should not run after doing the above.  In fact you really should move the .bk file out of there entirely, because if you ever run 'ldconfig' it actually reinstigates the problem by re-softlinking the 0.9.7 to the 0.9.7.bk you just created, and you're back where you started!

The above fixes the scp problem for me, and the KOpieMail/Pi (which I believe is the culprit that writes over the rom's libcrypto, at least in my case) still runs.

This is great -- I was going nuts without scp.

8

Sharp ROMs / Scp Not Working On Cacko 1.21b

« on: December 02, 2004, 06:34:41 pm »

This is interesting ... I *just* started having this problem.  I recently reflashed with Cacko 1.21b to try to debug a bluetooth card issue, which more or less coincided with the beginning of the scp problem, but I could have sworn that 1) it didn't start happening the day after the reflash, and 2) that I reflashed with exactly the same downloaded rom image and hotfix 'B' that I used the first time, ie: nothing should have changed....

9

Sharp ROMs / Anycom Cf-300 Bluetooth On Cacko 1.21b

« on: December 02, 2004, 11:34:34 am »

Is there a solution? I also have this card and want to use it on an 860.

fir -- What my last post means is that it won't work right now with Cacko, or probably any other rom at the moment, because the bluecard_cs driver changes needed to support the card's initialization and its faster UART baud rate didn't make it into the linux kernel until 2.6.6rc2.  The Cacko kernel is based on the Sharp kernel, which in turn was based on 2.4.18 IIRC.

However the great thing about Linux is that it's open source, so the changes to the driver can probably be shoehorned into the Cacko kernel.  (They appear to be localized to one file.)  Since I can't use it I've donated my card to the Cacko project, so when maslovsky gets it he can incorporate & test the changes and they'll make their way into a new version of the rom at some point if all goes well.

So it depends on how long you think you can wait.  I'm impatient, so I ordered a Socket CF G Bluetooth card which arrived last night, and I'm up and running with GPRS through my Nokia 6230.  Woohoo.

Now all I need to do is get KOPI to sync with my laptop over the connection and I'm good.

10

Sharp ROMs / Anycom Cf-300 Bluetooth On Cacko 1.21b

« on: December 01, 2004, 04:01:16 pm »

I guess nobody had any ideas.  ;-)

For the record, to save anyone else the trouble: After banging my head against this for a while, I went back through the BlueZ site looking for clues and it seems that the bluecard_cs driver doesn't have support for the AnyCom CF-300 until kernel version 2.6.6-rc2 and beyond.  So you have to be careful with this: even if BlueZ says it's supported, you need concomitant support in your driver-kernel combo for this to work.   See:

http://www.holtmann.org/linux/bluetooth/bluecard.html

The comment in bluetooth/bluecard_cs.c in the revision to 2.6.6-rc2 says:

# The Anycom CF-300 compact flash card contains a new Bluetooth chip and
# thus it needs some special handling for the faster UART baud rate. This
# patch detects this new card and does the different initialization.

So, not going to work in Cacko unless they patch the kernel specifically to support it.

This would explain why the card gets a certain way through the initialization process (recognized by the Z as a bluetooth card and the LED goes on) and then craps out.

So, I've got a Socket card on order which arrived today, and I'm going to have another go...

Anybody with supported hardware wanna buy an otherwise new bluetooth card?  It's apparently very nice... :-(

11

Sharp ROMs / Anycom Cf-300 Bluetooth On Cacko 1.21b

« on: November 25, 2004, 01:18:42 am »

I'm having problems getting an AnyCom CF-300 bluetooth card to be recognized by Cacko 1.21b, on an 860.  I did a fresh install of the ROM (with the hotfix applied) just in case.  At first I was getting nothing at all when I inserted the card, but a related ZUG post (with no resolution, sadly) suggested adding the following lines to /etc/pcmcia/bluetooth.conf:

card "LSE139 Bluetooth Compact Flash Card"
  manfid 0x0264, 0x000b
  bind "bluecard_cs"

That improved things, and the card is recognized as a new CF Bluetooth card upon insertion, and the card light goes on (though it goes back off after a few seconds).  I thought I was homefree, but no dice.  Running hciconfig shows:

hci0:    Type: PCCARD
           BD Address: 00:00:00:00:00:00 ACL MTU: 0:0  SCO MTU: 0:0
           DOWN INIT RUNNING
           RX bytes:0 acl:0 sco:0 events:0 errors:0
           TX bytes:0 acl:0 sco:0 commands:1 errors:0

So the address is all zeros.  That seems to be the stumbling block.

cardctl ident gives:

product info: "BTCFCARD", "LSE139"
manfid: 0x0264, 0x000b

when I do an "sdptool browse" I get:

Inquiring...
Inquiry failed

But I assume that's because the address for the card is showing up as 0's, which is the root of the problem.

BlueZ compatibility page says this card is supported.  Any ideas?

12

6000 - Tosa / USB HD attached to Z!

« on: November 19, 2004, 03:14:11 pm »

I'd be interested to see someone reincarnate Toshiba's abortive "Bluetooth Pocket Server" (do a google search) idea from a couple of years ago -- one of these 5-10-20GB Toshiba HDDs with a small rechargeable battery, and Bluetooth.  I think they actually marketed a batch of these, but it flopped fairly quickly.  In principle it seems like a nice storage solution for a Bluetooth-equipped Z.  Then you just keep the thing in your backpack and presto -- lots of available storage.

There's a rumor that Apple (or one of it's competitors) is going to build something like this into the next version of the IPod, with stereo Bluetooth wireless headphones.  (Though don't hold your breath.)  Obviously the throughput would not be great, but probably good enough for reading audio (though not video, which would be part of the attraction).

Anybody know of such a device?  Seems like a natural extension to e.g. a digital camera (too slow to write directly, but camera could slowly migrate data from its primary storage card onto the remote HDD) but if Toshiba's experience is indicative it seems to be a product category that has already failed.

13

Software / KDE-Pim/Pi 1.9.6 Release

« on: October 15, 2004, 02:30:18 am »

zautrix:
Any plans to release a winblows version of 1.9.6? I'm forced to use it at work   and would love to be able to sync my address book when in windblows.
Thanks!
Jerry

No! :-(

But a version 1.9.7 will be available soon, for the Z and for Wintendo! :-)

It will have a really easy Kx/Pi to Kx/Pi syncing (via network) feature, such that people, who are too stupid to configure the Zaurus<->Window  Sync via ssh ( like me ;-)  )  can sync their Z with KO/Pi and KA/Pi on Windows.

And other useful features, like direct receiving of data via infrared and syncing with mobile phones ( most probably Nokia phones via infrared).

But I have to test the new features first, the mobile phone syncing is actually really complicated.
I am not sure, but maybe then the Zaurus will be the first PDA, which is able to sync with mobile phones.

For those, who don't want to sync is an "export to phone" feature in KA/Pi and KO/Pi.

If everything is working fine, KA/Pi and KO/Pi are more or less feature complete for me.

z.

zautrix --

While I am now quite addicted to kopi especially (I have a C860, a windows laptop for work and a SuSE workstation at home) the one feature I really miss from the vanilla KOrganizer is the ability to (re)parent ToDo's using drag-and-drop.  Right now I can't figure out how to do it at all in kopi without deleting the todo and re-creating it under the intended parent.  

Do you anticipate being able to add this (in the next version or whenever) or is it perhaps not feasable to implement?  Drag-and-drop is always kind of awkward on a PDA, but I believe it's there in Qt/Embedded anyway, and it would be super useful.