This document describes only things that I came across when testing my phone. I am not in any way affiliated to Motorola and I would not gain anything by appreciating or criticizing the phone. What ever worked and whatever did not work was for me, I might be wrong and would take no responsibility if they do not work for you. This document is 'freely' available under the GNU Free Documentation License. Visit www.gnu.org/licenses/licenses.html for more information on the GNU licenses.
To help anyone who is interested in testing a Motorola A768i or any subsequent Motorola Linux based smartphones. Also to keep record of how and what can be done by my phone for future reference ;) and above all these things, bridge the gap - inability to communicate with the mobile phone should not be a reason to use windows!
All the experiments that I conducted are based on many other similar 'free' documents that are available on the internet. Links to all such documents are available in the resources section. Bárány updated me on his experiments with synchronization
The phone in India costs around Rs.23,000/- (about USD500). When delivered to me the package contained
This section describes the GNU/Linux environment under which I tested my phone. Go on... nothing complicated and is very easy to setup. Though my primary environment was based on a P4 desktop with Debian installed on it, all the procedures described should be valid for other hardware and distributions too.
Hardware relevant to the experiments conducted.
A regularly updated Debian unstable (Sarge) installation with the following relevant packages. Find the list of repositories I use in section 10.1
This chapter describes the observations I made when trying to establish communication between my phone and my GNU/Linux box (desktop). Apart from using USB, bluetooth and IrDA to connect to my phone I also tried to explore possible ways of using the established connections.
USB was the first method I used to communicate with the phone. The USB cable
that was part of the package made this straight forward. After connecting my
phone to the desktop lsusb gives the following when USBLAN is disabled in
the phone settings.
================================================================= Bus 005 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 003 Device 002: ID 04b3:310b IBM Corp. Bus 003 Device 001: ID 0000:0000 Bus 002 Device 003: ID 22b8:3802 Motorola PCS C330 GSM Phone Bus 002 Device 001: ID 0000:0000 Bus 001 Device 001: ID 0000:0000 =================================================================
So that was my phone connected to the USB. Everything looked fine
except for the phone's model number. As far as I understand C330 was
one of the Motorola's earliest phones to be GPRS enabled and that
probably was the reason for this. Given below is the relevant
information from proc/bus/usb/devices
================================================================= T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=02(comm.) Sub=00 Prot=00 MxPS=16 #Cfgs= 1 P: Vendor=22b8 ProdID=3802 Rev= 0.01 S: Manufacturer=Motorola Inc. S: Product=Motorola Phone C:* #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr= 2mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=cdc_acm E: Ad=85(I) Atr=03(Int.) MxPS= 8 Ivl=10ms I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms =================================================================
cdc_acm module makes the usb devices act as serial
devices. As expected after loading the module and putting the phone in USB
Modem mode the phone was visible as a serial modem on /dev/ttyACM0.
Now when I enabled USBLAN on my phone, lsusb had something different...
================================================================= Bus 005 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 003 Device 002: ID 04b3:310b IBM Corp. Bus 003 Device 001: ID 0000:0000 Bus 002 Device 004: ID 22b8:600c Motorola PCS Bus 002 Device 001: ID 0000:0000 Bus 001 Device 001: ID 0000:0000 =================================================================
I was not able to test this on my debain because Belcarra is yet to provide a driver for the 2.6 Linux kernels. However, I used the drivers provided by Belcarra for the 2.4 kernels to test USBLAN on RedHat 8.0. The following is what I had to do to install the drivers
modprobe usblan vendor_id=0x22b8 product_id=0x600c================================================================= 1.0.0 sl@belcarra.com, tbr@belcarra.comXXX usblan.c: 1.0.0 sl@belcarra.com, tbr@belcarra.com usblan.c: Linux USBLAN driver usbdnet_modinit: vendor_id: 22b8 product_id: 600c usbdnet_modinit: vendor_id: 22b8 product_id: 600c inserted into table usb.c: registered new driver usbdnet hub.c: USB new device connect on bus1/2, assigned device number 4 probe: probe Checked device class idp_search: look for idVendor: 22b8 idProduct: 600c idp_search: looking at idVendor: 12b9 idProduct: f001 idp_search: looking at idVendor: 22b8 idProduct: 600c idp_search: MATCH IDP search done verify_no_claimed_interfaces: verify_no_claimed_interfaces: bNumInterfaces: 1 verify_no_claimed_interfaces: ok No claimed interfaces Created private find_valid_configuration[0] bConfigurationValue: 0 bNumInterfaces: 1 find_valid_configuration: interface(s) 1 find_interface_mdlm: class: 2 subclass: 10 endpoints: 3 find_interface_mdlm: dded54a0 extralen: 35 bLength: 05 bDescriptorType: 24 bDescriptorSubType: 00 find_interface_mdlm: CS bDescriptorSubType: 00 find_interface_mdlm: dded54a5 extralen: 30 bLength: 15 bDescriptorType: 24 bDescriptorSubType: 12 find_interface_mdlm: CS bDescriptorSubType: 12 find_interface_mdlm: FUNCTIONAL bGUID 74 f0 3d bd 1e c1 44 70 find_interface_mdlm: FUNCTIONAL bGUID a3 67 71 34 c9 f5 54 37 find_interface_mdlm: dded54ba extralen: 1b bLength: 07 bDescriptorType: 24 bDescriptorSubType: 13 find_interface_mdlm: CS bDescriptorSubType: 13 find_interface_mdlm: DETAIL bGuidDescriptorType find_interface_mdlm: BLAN bmDataCapabilities: 01 find_interface_mdlm: dded54c1 extralen: 14 bLength: 0d bDescriptorType: 24 bDescriptorSubType: 0f find_interface_mdlm: CS bDescriptorSubType: 0f find_interface_mdlm: dded54ce extralen: 07 bLength: 07 bDescriptorType: 24 bDescriptorSubType: 0a find_interface_mdlm: CS bDescriptorSubType: 0a find_interface_mdlm: found 0 0 verify_blan_interface: found bmDataCapabilities: 01 bPad 00 find_valid_configuration: mdlm Found valid configuration probe: configuration_number: 0 bConfigurationValue: 1 probe: setting configuration bConfigurationValue: 1 /hotplug/net.agent: invoke ifup usb0 usb_control/bulk_msg: timeout probe: BLAN probe: claiming data interface: configuration: 0 interface: 0 probe: tx_size: 64 rx_size: 64 probe: tx_ep : 2 rx_ep : 1 probe: success 1.0.0 probe: return de818000 =================================================================wait a minute... did I say it worked straight away? Actually the log always said the following before the driver refused to recognize/connect to my phone!
================================================================= verify_blan_interface: found bmDataCapabilities: 01 bPad 00 find_valid_configuration: mdlm Found valid configuration probe: configuration_number: 0 bConfigurationValue: 1 probe: setting configuration bConfigurationValue: 1 /hotplug/net.agent: invoke ifup usb0 usb_control/bulk_msg: timeout probe: caught unregister probe: unregister probe: free priv probe: return NULL usb.c: USB device 3 (vend/prod 0x22b8/0x600c) is not claimed by any active driver. =================================================================I had to make a few minor modifications to make it work. If you have a similar problem, the same modifications might help you. Heres a patch :)
=================================================================
--- usblan.c 2003-10-31 16:49:53.000000000 +0530
+++ newusblan.c 2004-11-21 20:44:45.014989128 +0530
@@ -2272,7 +2272,8 @@
printk(KERN_INFO"%s: setting comm interface bInterfaceNumber: %d bAlternateSetting: %d\n", __FUNCTION__,
priv->comm_bInterfaceNumber, priv->comm_bAlternateSetting);
- THROW_IF (usb_set_interface(usbdev, priv->comm_bInterfaceNumber, priv->comm_bAlternateSetting), unregister);
+ usb_set_interface(usbdev, priv->comm_bInterfaceNumber, priv->comm_bAlternateSetting), unregister;
+// THROW_IF (usb_set_interface(usbdev, priv->comm_bInterfaceNumber, priv->comm_bAlternateSetting), unregister);
if (priv->nodata_bInterfaceNumber >= 0) {
printk(KERN_INFO"%s: setting nodata interface bInterfaceNumber: %d bAlternateSetting: %d\n", __FUNCTION__,
=================================================================
After successfully connecting, I had to reselect "on" from the USBLAN combo
inorder to get the ipaddress assigned to the phone. It was 192.168.1.1
so I did a ifconfig usb0 192.168.1.2 to assign 192.168.1.2 to my desktop
system. To verify I did a ping 192.168.1.1 and the phone responded well.
Now, the best of USBLAN - I did a telnet 192.168.1.1 and I could
login to the phone as a root user and explore each and every part of the
phones filesystem. The phone had quite a few files from the /etc, /bin
, /usr/bin, /proc and /sbin. It was a very good experience exploring
the phones filesystem. Another thing - the phone also exports the "/" file system
and another read-write folder using the SMB interface! To summarize here are a few things
that I found -
After I did a telnet to the phone I tried a few commands like ls, ps and cat - but
that was not all, I also tried a reboot which put my phone into a strange state where
the phone neither rebooted nor was responding to anything. I had to remove the battery and put it
back to get my phone back to normal! Me along with
bunny
will try to explore more on Motorola a768i hacking and writing applications with Qt/Embedded.
Not sure how possible this is, but will give it a try - hope I won't end up buying another
A768i or a Motorola A780!
The next method I tried to establish a connection between the desktop and phone was bluetooth. Having already tried sharing a lot of images and ringtones with other friends over bluetooth, I tried to do the same sharing with a GNU/Linux box.
I inserted the bluetooth dongle and did a lsusb which gave the following output...
================================================================= Bus 005 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 003 Device 002: ID 04b3:310b IBM Corp. Bus 003 Device 001: ID 0000:0000 Bus 002 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle Bus 002 Device 001: ID 0000:0000 Bus 001 Device 001: ID 0000:0000 =================================================================
It was only after seeing the above I knew that my bluetooth dongle is
based on the CSR chipset. Just to check if the module got loaded, I did a
lsmod which confirmed that the module bluetooth module was
already loaded! The next step was to get some applications use bluetooth.
After a bit of googling I came across the bluez project and as always the
debian unstable had all the packages from this project. The command hciconfig,
which is part of the bluez-utils package gave no output... the problem seemed
a bit obvious - missing hci module? I loaded the hci_usb module with a
modprobe hci_usb and that did the trick... hciconfig now said
=================================================================
hci0: Type: USB
BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0
DOWN
RX bytes:0 acl:0 sco:0 events:0 errors:0
TX bytes:0 acl:0 sco:0 commands:0 errors:0
=================================================================
everything seemed fine, except for the 'DOWN' string. Further reading
suggested that I should start sdpd and hcid after which my
usbdongle was up and active!
Time to pair up with my phone. I powered up bluetooth in my phone and
put the phone in "Find Me" mode. After a hcitool inq which
reported the address of a near by bluetooth device (obviously my phone) as
"00:0A:28:68:C2:06" I did a hcitool cc 00:0A:28:68:C2:06 to
connect to the phone and when prompted for pin I entered '0000' on both
phone and my GNU/Linux box. That established a bluetooth bond between my phone
and the desktop system. A l2ping 00:0A:28:68:C2:06 now gave me the
following output:
================================================================= Ping: 00:0A:28:68:C2:06 from 00:08:1B:81:8C:0B (data size 20) ... 0 bytes from 00:0A:28:68:C2:06 id 200 time 29.48ms 0 bytes from 00:0A:28:68:C2:06 id 201 time 38.76ms 0 bytes from 00:0A:28:68:C2:06 id 202 time 28.88ms 0 bytes from 00:0A:28:68:C2:06 id 203 time 31.85ms 0 bytes from 00:0A:28:68:C2:06 id 204 time 27.69ms 0 bytes from 00:0A:28:68:C2:06 id 205 time 42.68ms =================================================================
To use the phone as a bluetooth modem, I put the phone in bluetooth modem
mode and then made my bluetooth connection to the phone visible as a
comm interface using the rfcomm module. I did this using
rfcomm bind rfcomm0 00:0A:28:68:C2:06 1. That brought up bluetooth
and bonded my phone with the desktop.
To summarize... here are the commands I had to execute to get my bluetooth up.
================================================================= modprobe bluetooth # I did not need this. Added it to make it easy for others modprobe hci_usb hcid sdpd hcitool inq # This listed the address of my phone as 00:0A:28:68:C2:06 hcitool cc 00:0A:28:68:C2:06 # Opened a connection to phone l2ping 00:0A:28:68:C2:06 # Ensured that the bond was established # Open channel one of my phone as /dev/rfcomm0 for modem rfcomm bind rfcomm0 00:0A:28:68:C2:06 1 =================================================================
Apart from running the above commands, I had to make a changes in a few of the configuration files. These changes are not compulsory but might be required.
security to user in /etc/bluetooth/hcid.confpin_helper to the one supplied by kdebluetooth package in /etc/bluetooth/hcid.confauth in the device section of /etc/bluetooth/hcid.confrfcomm profile in /etc/bluetooth/rfcomm.confNow it was the turn of Infrared. I replaced the bluetooth dongle with a IrDA dongle.
lsusb now said this...
===================================================================== Bus 005 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 003 Device 002: ID 04b3:310b IBM Corp. Bus 003 Device 001: ID 0000:0000 Bus 002 Device 003: ID 066f:4200 SigmaTel, Inc. STIr4200 IrDA Bridge Bus 002 Device 001: ID 0000:0000 Bus 001 Device 001: ID 0000:0000 ====================================================================
So this is a STIr4200. Getting my IrDA dongle up was not very complicated... the following is what I had to do...
==================================================================== modprobe stir4200 modprobe uhci_hcd modprobe irda modprobe irtty_sir modprobe ircomm_tty irattach irda0 -s ====================================================================
After executing the above commands, a ifconfig confirmed that
my IrDA is up with this...
====================================================================
eth0 Link encap:Ethernet HWaddr 00:09:6B:6F:88:22
inet addr:172.19.58.94 Bcast:172.19.255.255 Mask:255.255.0.0
inet6 addr: fe80::209:6bff:fe6f:8822/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:13734 errors:0 dropped:0 overruns:0 frame:0
TX packets:9864 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:15485593 (14.7 MiB) TX bytes:1070683 (1.0 MiB)
irda0 Link encap:IrLAP HWaddr 30:3a:30:38
UP RUNNING NOARP MTU:2048 Metric:1
RX packets:308 errors:4 dropped:4 overruns:0 frame:0
TX packets:2282 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:8
RX bytes:10003 (9.7 KiB) TX bytes:34440 (33.6 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:15 errors:0 dropped:0 overruns:0 frame:0
TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1432 (1.3 KiB) TX bytes:1432 (1.3 KiB)
====================================================================
After I put the phone with the shell open in front of the IrDA dongle
the irdadump command confirmed the presence of my phone in front
of the IrDA dongle.
Output of irdadump was a bit like this... ----------------------------------------- 11:51:08.135052 xid:rsp 140129e9 < ebbcb90f S=6 s=4 Motorola Phone hint=c120 [ PnP LAN Access IrOBEX ] (31) 11:51:08.249779 xid:cmd 140129e9 > ffffffff S=6 s=* prasad hint=0400 [ Computer ] (22) The samething after putting the phone in IrDA modem mode was... --------------------------------------------------------------- 11:52:35.120549 xid:rsp 140129e9 < ebbcb90f S=6 s=4 Motorola Phone hint=c124 [ PnP LAN Access IrCOMM IrOBEX ] (31) 11:52:35.236555 xid:cmd 140129e9 > ffffffff S=6 s=* prasad hint=0400 [ Computer ] (22)
The first line in the output of irdadump given above shows the various
protocols supported by the phone over IrDA. The following is the list of
protocols supported
The first one "LAN Access" is based on the "IRLAN"
protocol. After inserting the "irlan" module with modprobe irlan and
doing a ifconfig irlan0 10.0.0.1 netmask 255.255.255.0 broadcast 10.0.0.255
my desktop took the '10.0.0.1' ip for the irlan0 device. However, I could not
proceed any further because I could not do the same ifconfig on my phone :(
Motorola probably has this configured to some IP but I dont know how to get to
the necessary details. Can someone help me with this?
The next thing, "IrCOMM", visible only when phone is in "IrDA Modem" mode
was visible as a serial modem on /dev/ircomm0. The modem responded
well for the modem commands.
The last protocol supported over IrDA, the IrOBEX was tested and is documented in the next section - "Sharing Ringtones/Files".
Sharing over USB is not allowed in the phone. All the "Share via..." menus only have Bluetooth, IrDA, MMS and EMail. However, on windows one of the applications given by Motorola allowed me to transfer files to the phone over USB. Am still looking for ways to do it from a GNU/Linux box.
After trying my hand at getting OpenOBEX applications to work with my bluetooth dongle, I realized that A768i only supported Object Push and this was probably the reason why obexftp failed with a strange looking error (I am new to bluetooth, so every error seemed strange to me). A bit of googling helped me find a howto on obex with bluetooth, which I did not try (wanted to keep the setup simple - no compilations, use only binary distributions kind).
Then, I came across a project called kdebluetooth... installed the Debian
package and executed kbluetoothd. That did all the magic. A click on
the icon in KDE system tray helped me discover all the bluetooth
devices around and the context menu let me transfer files from
GNU/Linux box to my A768i phone! Ringtones or files everything worked
perfectly fine :)
Receiving files from the phone was equally easy. With kbluetoothd
running I tried to share a file from my phone. I was immediately asked for
the pin on the phone and at the other end, on my desktop system, the file was
received by kbtobexsrv which prompted me for the filename to save the
recieved file as.
I tried sharing files over IrOBEX using the OpenOBEX utilities. Inspite
of a little struggle I could not use obexftp here too. I found obex_test
which helped me out quite well. As you can see from the session below,
I could only send files to the phone using obex_test, but could not get
files from the phone. Heres the obex_test session...
==================================================================== prasad:~# obex_test -irda Using IrDA transport OBEX Interactive test client/server. > c Connect OK! Version: 0x11. Flags: 0x00 > put /home/tux/a768i.html PUT file (local, remote)> a768i.html name=/home/tux/a768i.html, size=20582 Going to send 20582 bytes Made some progress... Made some progress... Made some progress... Made some progress... Made some progress... Made some progress... Made some progress... Made some progress... Made some progress... Made some progress... Made some progress... Made some progress... Made some progress... Made some progress... Made some progress... Made some progress... Made some progress... Made some progress... Made some progress... Made some progress... PUT successful! > get GET File> a768i.html GET failed 0x44! > get a768i.html GET File> GET failed 0x44! > d Disconnect done! > quit prasad:~# ====================================================================Motorola A768i as with the bluetooth probably only supported the PUT. It always failed with the get. However, the phone can do a PUT to other OBEX servers.
As suggested in a similar experiment by Raj Mathur, I tested receiving files from
phone (sharing from phone) using the squirt_getfile_big test program that comes
with the eSquirt source distribution (I had to compile the source). On completion
of the file transfer from my phone to the GNU/Linux desktop, the squirt_getfile_big
displayed the following message...
====================================================================
Waiting for e-Squirts over Obex...
Skipped header c3
Got a e-Squirt or Beacon !!!
-> label = []
-> url = []
-> type = []
-> length = [20582:d]
-> xml = [<Too Big>]
-> filename = [a768i.html.html] (ASCII)
-> seq = [0x0]
with options : xml=undefined ; model=undefined
protocol=Obex ; transport=IrDA
Obex IAS=[OBEX] ; Obex session=Yes
Obex Target=undefined
Version : squirt_common v2.6 - 24/5/1
====================================================================
Address book sharing was very much similar to sharing files. All the
contacts that were sent from the phone were received in VCard format. This
is true both in case of IrDA and Bluetooth. The only difference between
IrDA and bluetooth being the applications that handle the incoming request.
kbtobexsrv handled the bluetooth while squirt_getfile_big handled the IrDA.
The tasks were also sharable and were in the VCalendar format.
The phone did not support sharing of SMS messages and EMail messages. The messages can probably be copied to the desktop system only via synchronization mechanisms.
Sending of addressbook entries and tasks to the phone was again identical to sending
the files. A file with extension .vcf was parsed as a VCard and a
file with the extenstion .vcs was parsed as a VCalendar. The VCards and VCalendars
when sent to the phone were not properly handled by the phone until they had the DOS
style line terminators. That can be achieved using the unix2dos command.
I have tried a few tools like kpilot and gnome-pilot with no success. I have not yet finished exploring all the possibilities, but as of now there is no success with regard to synchronization. Would be glad to hear from anyone who has successfully done this.
UPDATE: Balázs Bárány has tried sync and was successful using the sync4j package. He logged his experiences at tud.at. Thanks Bárány for the update.
I tried to get a few applications interact with my phone most of which were synchronization, bluetooth and IrDA related applications. A few worked and many did not.
/dev/ircomm0
for testing the IrCOMM modem, /dev/rfcomm0 to test the bluetooth
modem and /dev/ttyACM0 to test the usb modem. I only tested a few
initialization and dialing commands from the ETSI set which worked fine.
However, I had problems when actually connecting to the GPRS network from
my desktop system - probably a mis-configuration at my end.
The Java virtual machine on A768i supports the MIDP-2.0 standard. When I tried writing small applications, there were a few APIs that would have made my experience more rich and satisfactory - they are the Filesystem and Addressbook access APIs. I have asked for the same to the motocoder.com support but here is what I got in reply...
=================== mail from motocoder support ==================== Filesystem API is licensee only API, see answer below for access licensee API. And when you will get javadoc when you got a business relationship with Motorola. Only developers with a business relationship with Motorola can access closed (or licensee only) APIs. To be evaluated for a business relationship with Motorola please refer to the below. Dear Developer, Thank-you for contacting Motorola with regards to working with us on our Mobile Devices. At this stage we need to refer you to our Business Development group. Please note that as there is not a Non-Disclosure Agreement (NDA) in place between yourself/company and Motorola all material you share with Motorola must not contain confidential material. We would like to invite you to send an email outlining the following, for evaluation. 1. What is your application (Game, Enterprise, etc) in 1000 words maximum. 2. Who is the target audience for this application 1000 words maximum. 3. What is the location and size of your company? 4. What quality control has this application already undertaken? 5. Do you have localisation available for this application? 6. Is this application already deployed on other Manufacturers platforms? 7. Website URL for your Companies information and Application Demonstration. Please place in the Subject Heading of the email either "Game", "Enterprise", "Location", "Other". Send your material to xxxxxx@motorola.com for evaluation. Please allow 4-6 weeks for evaluation. If successful you will be contacted in this period to progress this request. Regards, Business Development. =====================================================================
Inspite of having a good support to J2ME, not many applications available out there on the Internet run properly on this phone. The main reason for that is the absence of a proper keypad. A768i does not have a keypad, instead a virtual keypad on the touchscreen is all it has.
FloydSSH did not work on the a768i because of the missing physical keypad. When executed, the application showed a menu and asked me to press a number to select the task which was not possible! However, after a little searching I found MidpSSH which is based on FloydSSH but has a different implementation of the menu.
If you are familiar with j2me, porting the applications to a virtual keypad should be easy. I have not tried it but am ready to support anyone who wants to do it.
PICSEL - The best small sized document reader I have seen till date. It also has a html browser thats quite good - It rendered my homepage almost as perfect as mozilla does it.
VOICE RECOGNITION - Unlike many other phones in the past, A768i recognizes voice commands that are not already recorded. Apart from voice recognition it can read messages to you too. If you use the phone's memory to its capacity voice recognition fails to load :(
LINUX - For those like me, Linux is good enough a reason to buy this phone. If you still don't know... the Motorola A768i runs Linux. The user interface is provided by trolltech's Qt/Embedded.
PDA - Though I would not recommend replacing your palm with this phone, the PDA functionality that comes with this phone is impressive.
PHYSICAL KEYPAD - A768i would have been a much better phone if it had a physical keypad. The still-to-be-released Motorola A780 has it.
CAMERA - The camera on A768i is a low resolution CIF camera. I think cameras on phones are not meant to be used for anything other than collecting photo-ids for your addressbook, in which case the camera is good enough. But for people who consider buying this phone for the camera, you might be left disappointed. Just to add the Motorola A780 is coming with a mega pixel camera.
NO EXTERNAL MEMORY - The 52MB of user memory on the phone is all you have. This is a big leap when compared with the 8MB on its predecessor (the A760), but 52MB is still a limit. Motorola A780 has a memory slot for external memory!
J2ME Filesystem API
Sync tools for GNU/Linux
Belcarra USBLAN drivers for Linux-2.6.x
I am happy with this phone. With regard to the few drawbacks listed above... When A760 was released, it had a few problems which are kind of addressed in A768. Most problems of A768i are solved in the upcoming model A780, which could have its own problems. The technology changes every day and there is always a better phone in the pipeline. Its up to you to strike a balance between technology and need.
# Debian Stable deb http://debian.uchicago.edu/debian/ stable main non-free contrib deb-src http://debian.uchicago.edu/debian/ stable main non-free contrib deb http://non-us.debian.org/debian-non-US stable/non-US main contrib non-free deb-src http://non-us.debian.org/debian-non-US stable/non-US main contrib non-free deb http://debian.crosslink.net/debian/ stable main non-free contrib deb-src http://debian.crosslink.net/debian/ stable main non-free contrib deb http://security.debian.org/ stable/updates main contrib non-free # Testing repository deb http://debian.uchicago.edu/debian/ testing main non-free contrib deb-src http://debian.uchicago.edu/debian/ testing main non-free contrib deb http://non-us.debian.org/debian-non-US testing/non-US main contrib non-free deb-src http://non-us.debian.org/debian-non-US testing/non-US main contrib non-free deb http://debian.crosslink.net/debian/ testing main non-free contrib deb-src http://debian.crosslink.net/debian/ testing main non-free contrib deb http://security.debian.org/ testing/updates main contrib non-free # Unstable repository deb http://debian.uchicago.edu/debian/ unstable main non-free contrib deb-src http://debian.uchicago.edu/debian/ unstable main non-free contrib deb http://non-us.debian.org/debian-non-US unstable/non-US main contrib non-free deb-src http://non-us.debian.org/debian-non-US unstable/non-US main contrib non-free deb http://debian.crosslink.net/debian/ unstable main non-free contrib deb-src http://debian.crosslink.net/debian/ unstable main non-free contrib # kdebluetooth repository deb http://www.stud.uni-karlsruhe.de/~uddw/debian ./