[Bitpim-devel] Prospects for the Samsubng VI-660?

[Eric S. Raymond]

I have a VI 660, which is a Samsung SPH-A660 with Sprint firmware and
paint job. I know it's not on the BitPim supported list. I believe, based
on some cable-manufacturer advertising, that it will take a VI 600 cable.

Does anyone have any rumors, educated guesses, or thoughts on what it
would take to get this puppy talking to BitPim? Have phone, have
m4d Python coding skillz, can easily get cable.

[Stephen Wood]

Eric:

Supporting that phone will certainly not be very difficult. There are
presently various levels of support for 4 Samsung phones, one of them
from Sprint (VGA1000). While the protocols for the these phones are
similar, the BitPim support is not well unified as a number of
developers jumped in at once. Over the next few weeks we will be
unifiying the support and start using BitPim's packet description
language (which is being upgraded to support the AT modem command
protocol that the Samsung phones use.) At that point it will probably
be a lot easier to add new Samsung phones.

In the mean time, it would be much appreciated if you could document
how your phone responds to various phonebook AT commands. With kermit
or such, send "AT#PMODE=1" to your phone to put it in phonebook mode.
Then send "AT#PBOKR=n" (where n is 1 to the max entry number) and see
what the response looks like. The file
bitpim/dev-docs/samsungnotes.txt in the BitPim CVS is where we have
been gathering information about various Samsung phones.

Stephen

[The Doctor]

Is there any similar info you might need for the VGA1000? I noticed
that 0.7.23 still contains no support to write the phonebook entries
to the VGA1000 and just wondered if research was required to complete
that item. Currently BitPim only supports the writing of Calendar
data to the phone.

Post by Stephen Wood
Supporting that phone will certainly not be very difficult. There are
presently various levels of support for 4 Samsung phones, one of them
from Sprint (VGA1000). While the protocols for the these phones are
similar, the BitPim support is not well unified as a number of
developers jumped in at once. Over the next few weeks we will be
unifiying the support and start using BitPim's packet description
language (which is being upgraded to support the AT modem command
protocol that the Samsung phones use.) At that point it will probably
be a lot easier to add new Samsung phones.
In the mean time, it would be much appreciated if you could document
how your phone responds to various phonebook AT commands. With kermit
or such, send "AT#PMODE=1" to your phone to put it in phonebook mode.
Then send "AT#PBOKR=n" (where n is 1 to the max entry number) and see
what the response looks like. The file
bitpim/dev-docs/samsungnotes.txt in the BitPim CVS is where we have
been gathering information about various Samsung phones.
Stephen
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bitpim-devel mailing list
https://lists.sourceforge.net/lists/listinfo/bitpim-devel

[Stephen Wood]

No information about the VGA1000 is needed, just some time. I expect
to have a bit more time over the next couple of weeks.

Stephen

[Eric S. Raymond]

Post by Stephen Wood
Supporting that phone will certainly not be very difficult. There are
presently various levels of support for 4 Samsung phones, one of them
from Sprint (VGA1000). While the protocols for the these phones are
similar, the BitPim support is not well unified as a number of
developers jumped in at once. Over the next few weeks we will be
unifiying the support and start using BitPim's packet description
language (which is being upgraded to support the AT modem command
protocol that the Samsung phones use.) At that point it will probably
be a lot easier to add new Samsung phones.

That's good to hear. Consider me an available beta-tester; my wife and
I both have these phones and want to be able to edit the phone-number
directories.

I have installed BitPim and all prerequisites, also acquired and tested the
proper cable. I can confirm that an A600/SPH-A600 cable makes the 660
visible to the USB subsystem.

Post by Stephen Wood
In the mean time, it would be much appreciated if you could document
how your phone responds to various phonebook AT commands. With kermit
or such, send "AT#PMODE=1" to your phone to put it in phonebook mode.
Then send "AT#PBOKR=n" (where n is 1 to the max entry number) and see
what the response looks like. The file
bitpim/dev-docs/samsungnotes.txt in the BitPim CVS is where we have
been gathering information about various Samsung phones.

OK, I've hit a bit of a wall here. lsusb confirms the device is present:

***@snark:/home/esr# lsusb
Bus 001 Device 008: ID 04e8:6601 Samsung Electronics Co., Ltd Z100 Mobile Phone
Bus 001 Device 001: ID 0000:0000

However, the phone is not accessible as /dev/ttyUSB0, which is what I
would have expected given there's only one USB device on the system.

***@snark:/home/esr# stty -F /dev/ttyUSB0 ispeed 4800 && cat </dev/ttyUSB0
stty: /dev/ttyUSB0: No such file or directory

How can I determine which serial device to aim minicom at? And what is
the correct baud rate?

[Stephen Wood]

Post by Eric S. Raymond
However, the phone is not accessible as /dev/ttyUSB0, which is what I
would have expected given there's only one USB device on the system.

Try the port browser in BitPim (Edit/Settings). But almost certainly
it is going to show up as an acm device, /dev/input/ttyACM0 on Redhat
distros. (Load the acm module if it doesn't autoload).

Stephen

[Eric S. Raymond]

Post by Stephen Wood

Post by Eric S. Raymond
However, the phone is not accessible as /dev/ttyUSB0, which is what I
would have expected given there's only one USB device on the system.

Try the port browser in BitPim (Edit/Settings). But almost certainly
it is going to show up as an acm device, /dev/input/ttyACM0 on Redhat
distros. (Load the acm module if it doesn't autoload).

Port browser says:

==== Ports not available ====
USB Device - Vendor Samsung Electronics Co., Ltd Product Z100 Mobile Phone (Interface #01)

-------------------------------------------------------------------------------
This port is active but not available for use

Now, this screen does not actually give a corresponding serial device --
there is no hint here that /dev/input/ttyACM0 is what I want. Closest
it comes to that is a line that says

name usb::001::009::1

I presume this means that an attempt to open the device failed, but it
doesn't show the error code from the open failure.

I'm guessing I might need to run as root...nope, that doesn't help.
Still active, but not available.

Suggestions for the port details screen:

1) It should include the open error code idf access failed

2) It should name the Unix serial device, if any, corresponding to the port.

[Stephen Wood]

On Fri, 2004-12-17 at 18:13, Eric S. Raymond wrote:
...

Post by Eric S. Raymond
1) It should include the open error code idf access failed

Roger, who wrote the port scanner, will have to answer if that makes
sense.

Post by Eric S. Raymond
2) It should name the Unix serial device, if any, corresponding to the port.

It does, at least if the devices exist where it looks for them. It
looks for acm devices in /dev/usb/acm/* and /dev/input/ttyACM*. See
_comscanlinux in bitpim/comscan.py for more info.

What kind of system are you running? How is /dev, or wherever your
device files are kept, managed?

Stephen

[Eric S. Raymond]

Post by Stephen Wood

Post by Eric S. Raymond
2) It should name the Unix serial device, if any, corresponding to the port.

It does, at least if the devices exist where it looks for them. It
looks for acm devices in /dev/usb/acm/* and /dev/input/ttyACM*. See
_comscanlinux in bitpim/comscan.py for more info.

Ah. There's no /dev/usb on my system; both ttyUSB and ttyACM devices seem to
show up directly under /dev. There is a /dev/input, but it's thinly populated:

***@snark:/home/esr/cvs/bitpim# l /dev/input
event0 event1 mice mouse0

Post by Stephen Wood
What kind of system are you running? How is /dev, or wherever your
device files are kept, managed?

Fedora Core 3, device files managed by udev. This is a common enough
case that BitPim ought to handle it. Looks to me like some trivial
additions to the port scanner's path list might do.

Right now, though, I'm going to take my wife and a friend
from out of town to see "House of Flying Daggers". I'll take a look
at the portscan code later tonight.

[Roger Binns]

Post by Eric S. Raymond
Ah. There's no /dev/usb on my system; both ttyUSB and ttyACM devices seem to

udev keeps the /dev filesystem pretty clean. Until udev, it was
normal for there to be many many device nodes corresponding to
USB devices even when no corresponding device was plugged in
which is why the scanner didn't them all.

Post by Eric S. Raymond
Fedora Core 3, device files managed by udev. This is a common enough
case that BitPim ought to handle it.

I did commit looking for /dev/ttyACM? a short while ago.

Roger

[Roger Binns]

If you hit save at the bottom and post the HTML we'll have a better
idea of what you are seeing.

Post by Eric S. Raymond
Now, this screen does not actually give a corresponding serial device --
there is no hint here that /dev/input/ttyACM0 is what I want.

There is no corresponding serial device. Your phone can only be
accessed by whatever name the USB ACM driver is bound to. Using
libusb (which uses the USB filesystem) I can find out what devices
are attached. However there is no way for me to work out what
name they can be accessed as (if any). So BitPim just scans
various device names and sees what can be opened. You can find the
code in comscan.py in the comscanlinux function. The list tried is:

("/dev/cua", "Standard serial port", "serial"),
("/dev/ttyUSB", "USB to serial convertor", "serial"),
("/dev/ttyACM", "USB modem", "modem"),
("/dev/usb/ttyUSB", "USB to serial convertor", "serial"),
("/dev/usb/tts/", "USB to serial convertor", "serial"),
("/dev/usb/acm/", "USB modem", "modem"),
("/dev/input/ttyACM", "USB modem", "modem")

(I just added the 3rd line as that is where udev defaults to these
days)

Often the same major/minor is available in several locations so the
code remembers that.

BitPim can also talk to some devices using libusb directly. However
it does not implement the USB modem protocol (aka ACM) since every
operating system already includes it. Your phone can only be
accessed by this protocol, so whatever device node the driver appears
as has to be used.

Post by Eric S. Raymond
Closest it comes to that is a line that says
name usb::001::009::1
I presume this means that an attempt to open the device failed, but it
doesn't show the error code from the open failure.

Your presumption is incorrect. That is the pseudo-filename used
for devices accessed via libusb. (The libusb library just
uses bus, device and interface numbers so there is no filesystem
name as such which is why this pseudo one is used).

Post by Eric S. Raymond
1) It should include the open error code idf access failed

When I wrote the code, you got back 3 possibilities. EPERM
if you didn't have permission to open the device node (that
is independent of the driver actually existing, someone else
having it open etc). The second possibility was success,
and the last one was EACCESS.

I just tried again on my 2.6.9 system and you now get EINVAL
if the driver doesn't exist, and it lets multiple processes
open the device concurrently which it didn't use to.

Post by Eric S. Raymond
2) It should name the Unix serial device, if any, corresponding to the port.

There isn't one.

Quite simply a "normal" Linux system has tens of device names that
could be the relevant phones. I can spot if the device is connection
via libusb, but there is no way to work out what the corresponding
device node is. So the code just tries everything. However failures
to open are not listed since there would be so many.

Linux is also the only operating system that when the person logged
into the console plugs in a USB device does not give permissions
to that device to that user. (There are various reasons for and
against doing that, and we have to live with this).

If you can come up with a better way of doing this I would love to know.

BTW the doc will normally tell you what is normal. For example
see the Sanyo information:

http://bitpim.org/testhelp/phones-sanyo-cables.htm

The Samsung doc hasn't been written yet. (Hint hint Joe and Vic :-)

Roger

[Eric S. Raymond]

Post by Roger Binns
(I just added the 3rd line as that is where udev defaults to these
days)

cvs update isn't getting me this one yet.

Post by Roger Binns

Post by Eric S. Raymond
I presume this means that an attempt to open the device failed, but it
doesn't show the error code from the open failure.

Your presumption is incorrect. That is the pseudo-filename used
for devices accessed via libusb. (The libusb library just
uses bus, device and interface numbers so there is no filesystem
name as such which is why this pseudo one is used).

Thanks, I'm still struggling with how libusb works.

Post by Roger Binns

Post by Eric S. Raymond
1) It should include the open error code idf access failed

When I wrote the code, you got back 3 possibilities. EPERM
if you didn't have permission to open the device node (that
is independent of the driver actually existing, someone else
having it open etc). The second possibility was success,
and the last one was EACCESS.

Would it be possible for the code to save that status on a failed open
and display it in the details screen? This would be a big help in
troubleshooting.

Post by Roger Binns
If you can come up with a better way of doing this I would love to know.

Confirms that I need to be running as root. No big surprise there.

[Roger Binns]

Post by Eric S. Raymond
cvs update isn't getting me this one yet.

Unfortunately SourceForge has the anonymous CVS servers lag the
real CVS by around 5 hours (that is the claim - it sometimes
seems longer).

Just add this line in the list in the Linux bit of comscan.py:

("/dev/ttyACM", "USB modem", "modem"),

You can also just type in the device name on the main settings
dialog. It should be /dev/ttyACM0

Post by Eric S. Raymond
Thanks, I'm still struggling with how libusb works.

In your case, libusb is of no use. We can tell via libusb that
the device is present on a USB bus. However we cannot tell
if there is a driver loaded, or what device node to use. And
for devices such as yours, the kernel based acm driver has to
be used, which means libusb can't be used!

Post by Eric S. Raymond
Would it be possible for the code to save that status on a failed open
and display it in the details screen? This would be a big help in
troubleshooting.

I did consider it, but then it would have to show every single
device that it tried to access. A normal system (pre-dating udev,
or ones where /dev was saved before udev was installed) will have
around 30 or 40 candidates.

Post by Eric S. Raymond

Post by Roger Binns
If you can come up with a better way of doing this I would love to know.

Confirms that I need to be running as root. No big surprise there.

Actually it confirms you need to read the doc :-)

http://bitpim.org/testhelp/howto-linuxusb.htm

The vendor and product ids for your phone are 0x04e8 and 0x6601
respectively.

I did consider making the install for Linux automatically do
the necessary hotplug magic. But, as is usually the case, no
two Linux distros can agree on where the files actually go
and exactly how they get hooked in.

Roger

[Eric S. Raymond]

Post by Roger Binns

Post by Eric S. Raymond
cvs update isn't getting me this one yet.

Unfortunately SourceForge has the anonymous CVS servers lag the
real CVS by around 5 hours (that is the claim - it sometimes
seems longer).

I'm synced up now.

Post by Roger Binns
Actually it confirms you need to read the doc :-)
http://bitpim.org/testhelp/howto-linuxusb.htm
The vendor and product ids for your phone are 0x04e8 and 0x6601
respectively.

Does this look like success?

***@snark:~/cvs/bitpim$ python bp.py
setting windows/ConfigDialog to position 321, 665
setting windows/MainWin to position 255, 446 - size 722 x 625
handling url bpuserimage:Select:;width=123;height=146
handling url bpimage:ringer.png;width=24;height=24
icon size requested
<com_othercdma.Profile instance at 0xf668250c>

Post by Roger Binns
I did consider making the install for Linux automatically do
the necessary hotplug magic. But, as is usually the case, no
two Linux distros can agree on where the files actually go
and exactly how they get hooked in.

Perhaps a scanning sequence analogous to the way you pick up devices could
address this.

[Roger Binns]

Post by Eric S. Raymond
Does this look like success?

Yes.

Post by Eric S. Raymond
Perhaps a scanning sequence analogous to the way you pick up devices could
address this.

It is an installation time issue. I would need to put the
right files in some directory below /etc/hotplug or whatever
variant the distro is using (that turns into 3 or 4 possibilities).
And I would have to edit one file and do all this without
trashing whatever the user already had.

And the rpm packaging format has a huge gaping hole in that
it doesn't have the equivalent of installf like you get for
for pkgadd so I wouldn't be able to integrate the changes
correctly for the packaging system of the user's machine.
(I don't think dpkg does either.)

So ultimately I decided to just write the doc instead instead :-)
If someone does want to persue automating this, I'll help them
come up with a patch.

Roger