[BitPim-devel] Adding BitPim support for LG-VX3200

[a***@schurmann.org]

All,

I have submitted a tarball to Roger with the barebones bits to support
the LG-VX3200 in BitPim. I also submitted a very basic writeup with the
special challenges that this phone presented in this effort. Roger
requested that I post this writeup for your perusal. Enjoy . . .

I have done the work to add basic LG-VX3200 support (wallpapers, ringers
and reading the phonebook) to BitPim.

I am submiting the core set of code updates that I believe will add
LG-VX3200 support to BitPim. As you probably already know the
LG-VX3200 is a very basic phone. Apparently what LG did to develop
this phone was to start with a more full-featured version and then
started hacking at the code to reduce functionality in certain
areas. Unfortunately this "hack" approach on their part causes some
problems with the consistent, well thought out internals in BitPim.

Here I will call out the shortcuts that LG took to develop this phone
and what I chose to do in BitPim to provide some useful support to the
end users.

Ringers
-------
The good news is that LG really kept most of this intact. They use the
basic Index approach and it works. The bad news is that the phone
supports mp3 and midi ringers but insists on the media file having a
".mid" extension in the phone's filesystem. Sheesh - what a pain.

I decided that I did not want the BitPim user to have to know or care
about this peculiarity. The way I did this is that when the Index is
read from the phone I intercept this, "sniff" the media file to
determine it's true type, and then rename the file if need be in the
BitPim internalized index. When media files are written to the phone I
reverse this file extension munging to make sure the phone always has
".mid" files.

The BitPim user has the luxury of full midi/mp3 support offered by
BitPim and can upload/download these file types with no knowledge of
what is happeing behind the scenes.

All of this finagling is constrained to:
Phone.getindex()
Phone.getmedia()
Phone.savemedia()
in com_lgvx3200.py

The rest of BitPim is blissfully ignorant of this filename mangling
and works seemlessly for ringers.

Wallpapers
----------
Unfortunately LG did a real hack job here. They have an images related
index file in the phone but it is completely unused. Second, because
they do not use an indevx mechanism there is no way to download
wallpapers to the phone that the user can then choose from. The only
mechanism that I could get to work is to replace wallpapers already
selected by the user with custom versions via BitPim. Finally, the
wallpaper image format is proprietary to LG which requires further
finessing in BitPim.

The actual fiddling with index files and indexes is constrained to:
Phone.getindex()
Phone.getmedia()
Phone.savemedia()
in com_lgvx3200.py

I have added support in conversions.py for converting between this LG
proprietary format and BMP files. (Side note - I only support 128x128
24BPP BMP files. The LG files are 128x128 16BPP-R5G6B5 format.)

fileinfo.py has been extended to support the proprietary BIT file
format but this extension is not actually used in any of my
changes. It is simply there for symmetry reasons.

Phonebook
---------
It looks like the LG-VX3200 actually has real phonebook that is very
close to the one used in the 4400/4500. I have gotten the reading of
the phonebook apparently working in BitPim. I have done zero work so
far to really test this nor have I done anything yet to test writing
it. I have enabled reading in BitPim but currently writing is not
suppported. This will be my next major step in development.

Calendar
--------
I have not spent one second looking at this. I hope to get to it soon
and I hope that it will just work! ;-)

Autodetect
----------
I have put the necessary info in com_lgvx3200.py in support of
autodetect.

Help
----
I have provided the necessary BitPim Help files to support the
capabilities I am providing. The new help files will obvisouly need
valid Index numbers inserted.


Let me know what I am missing for this Rev 0 release.

Thanks,
Bruce Schurmann
Austin, TX
***@users.sourceforge.net

[Roger Binns]

Post by a***@schurmann.org
I have submitted a tarball to Roger with the barebones bits to support
the LG-VX3200 in BitPim.

The patches have been applied. I made one change which is to call
the format "lgbit" rather than plain "bit". You can double check
what I did at http://bitpim.org/cvslog/ and the help on the main
site has been updated with your content as well.

Currently the phone will only show up when running from CVS. When
you are sure the code has been correctly patched then post here
and I'll move it to the production section.

Some comments:

- I really don't like the SimpleFileCache class.
com_brew.BrewProtocol.DirCache almost does what you need.
It would be appreciated if you can update that class and
change your code to use it. My suggestion is to add a
parameter to the constructor that turns on caching file
contents as well as the directory entries.

- I also don't like doing file format conversions in the
communications thread. There is no chance to interact
with the user if anything goes wrong. The file formats
should just be displayed by BitPim. You can look at
how BCI (Brew Compressed Image) is handled.

- The audio filename munging is also unfortunate. I think it
may be better to just completely remove it when coming off
the phone and add it back on when writing back. (This is
part of the reason fileinfo was written - we need to understand
the actual format rather than what the extension is.)
If the extension is removed then we have a problem giving
the files to other programs on the same operating system.

However that isn't a bad thing. It is about time
we moved to a model of storing media stuff in numbered
files in our data directory and showed names in the UI
appropriate for the phone etc. Any interactions that
need to be done with the OS can be done by creating
a copy of the file with whatever naming and extensions
make sense for the OS. This scheme will let us do
synchronization of media etc and is analogous to the
phone book except we don't store the actual file contents
in the database.

- The existing function in vx4400 that deals with media
sucks (it is large, convoluted, uses many short variable
names etc). Maybe someone can simplify and refactor it.

Roger

[Bruce S]

Did a fresh grab of the the repository. All of my changes appear to be in
and working including the Help.

All of your comments below are great. I need a little time to look at each
one and respond. Just wanted to let you know that the patches are intact.

Bruce

Post by a***@schurmann.org
I have submitted a tarball to Roger with the barebones bits to support
the LG-VX3200 in BitPim.

The patches have been applied. I made one change which is to call the
format "lgbit" rather than plain "bit". You can double check what I
did at http://bitpim.org/cvslog/ and the help on the main
site has been updated with your content as well.
Currently the phone will only show up when running from CVS. When you
are sure the code has been correctly patched then post here
and I'll move it to the production section.
- I really don't like the SimpleFileCache class.
com_brew.BrewProtocol.DirCache almost does what you need.
It would be appreciated if you can update that class and
change your code to use it. My suggestion is to add a
parameter to the constructor that turns on caching file
contents as well as the directory entries.
- I also don't like doing file format conversions in the
communications thread. There is no chance to interact
with the user if anything goes wrong. The file formats
should just be displayed by BitPim. You can look at
how BCI (Brew Compressed Image) is handled.
- The audio filename munging is also unfortunate. I think it
may be better to just completely remove it when coming off
the phone and add it back on when writing back. (This is
part of the reason fileinfo was written - we need to understand the
actual format rather than what the extension is.)
If the extension is removed then we have a problem giving
the files to other programs on the same operating system.
However that isn't a bad thing. It is about time
we moved to a model of storing media stuff in numbered
files in our data directory and showed names in the UI
appropriate for the phone etc. Any interactions that
need to be done with the OS can be done by creating
a copy of the file with whatever naming and extensions
make sense for the OS. This scheme will let us do
synchronization of media etc and is analogous to the
phone book except we don't store the actual file contents
in the database.
- The existing function in vx4400 that deals with media
sucks (it is large, convoluted, uses many short variable
names etc). Maybe someone can simplify and refactor it.
Roger
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit
http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
BitPim-devel mailing list
https://lists.sourceforge.net/lists/listinfo/bitpim-devel

[Roger Binns]

Post by Bruce S
Did a fresh grab of the the repository. All of my changes appear to be in
and working including the Help.

The VX3200 has now been enabled and the versionhistory updated.

Thanks,

Roger

[Will Smith]

It's really good, thanks for your work!

Post by Roger Binns

Post by Bruce S
Did a fresh grab of the the repository. All of my changes appear to be in
and working including the Help.

The VX3200 has now been enabled and the versionhistory updated.
Thanks,
Roger
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
BitPim-devel mailing list
https://lists.sourceforge.net/lists/listinfo/bitpim-devel

[Roger Binns]

Post by a***@schurmann.org
Unfortunately LG did a real hack job here. They have an images related
index file in the phone but it is completely unused.

They seem to drag code from phone to phone, each of which is worked
on by different developers who for some reason are never allowed to
talk to each other.

Post by a***@schurmann.org
Finally, the
wallpaper image format is proprietary to LG which requires further
finessing in BitPim.

I believe that format is also used on the other phones as well.
When you select an image as your wallpaper then the .bit file
is created from the selected file contents.

Post by a***@schurmann.org
I have added support in conversions.py for converting between this LG
proprietary format and BMP files. (Side note - I only support 128x128
24BPP BMP files. The LG files are 128x128 16BPP-R5G6B5 format.)

That BMP format is probably what the vx4500 uses then. We have
been trying quite hard to figure it out. It would be really useful
if you could write code that takes any sized 24 bit BMP and converts
to the same sized 16 bit BMP.

Post by a***@schurmann.org
it. I have enabled reading in BitPim but currently writing is not
suppported. This will be my next major step in development.

On all the other LG phones you can take a filesystem backup of the
pim directory, and then go ahead and do your development. When
you want things back to how they were, restore the pim directory
and reboot the phone.

Post by a***@schurmann.org
I have not spent one second looking at this. I hope to get to it soon
and I hope that it will just work! ;-)

The VX4400 calendar code and hence all the models that inherit from
it do not work correctly at the moment.

Post by a***@schurmann.org
I have put the necessary info in com_lgvx3200.py in support of
autodetect.

[Bruce S]

Great comments - here are just some quick replies - I will chew on the
others for awhile.

1. Below where I said "The LG files are 128x128 16BPP-R5G6B5 format." what
I meant to say is "The LG files are 128x128 BIT 16BPP-R5G6B5 format.". I
think you interpreted what I said is that the wallpaper on the LG-VX3200
is some sort of BMP file. The format actually is:

2 bytes - width
2 bytes - height
width x height 16bit R5G6R5 image data

Lean and mean. The final image file, e.g. wallpaper.bit, is therefore
128*128*2 + 4 bytes or 32772 bytes for a 128x128 image. As an aside the
image in a BIT file is also flipped about the x-axis compared to a BMP
file.

I will attempt to make the LGBIT related defs in fileinfo.py and
conversions.py more general purpose.

2. Auto-detect is not working. The problem appears to be related to
exactly what you describe below, i.e. the port I am using (COM3) has
class='serial' and not 'modem' therefore is it not used in the phone
detection process.

This is from my log:

12:49:15.920 coms:
[{'available': True,
'driverdate': (2001, 7, 1),
'description': 'Communications Port (COM1)',
'driverprovider': 'Microsoft',
'driverversion': '5.1.2600.0',
'hardwareinstance': 'ROOT\\*PNP0501\\PNPBIOS_12',
'driverdescription': 'Communications Port',
'active': True,
'class': 'serial',
'name': 'COM1'},
{'available': False,
'driverdate': (1999, 11, 14),
'description': 'Communications Port (COM2)',
'driverprovider': 'Microsoft',
'driverversion': '5.0.2183.1',
'hardwareinstance': 'ROOT\\*PNP0501\\PNPBIOS_16',
'driverdescription': 'Communications Port',
'active': False,
'class': 'serial',
'name': 'COM2'},
{'available': True,
'driverdate': (2002, 4, 9),
'description': 'Prolific USB-to-Serial Comm Port (COM3)',
'driverprovider': 'Prolific',
'driverversion': '1.5.0.0',
'hardwareinstance': 'USB\\VID_067B&PID_2303\\4&1217B47&0&1',
'driverdescription': 'Prolific USB-to-Serial Comm Port',
'active': True,
'class': 'serial',
'name': 'COM3'}]
12:49:15.936 Available ports: ['COM1', 'COM3']
12:49:15.950 Available modem ports: []

Post by a***@schurmann.org
Unfortunately LG did a real hack job here. They have an images related
index file in the phone but it is completely unused.

They seem to drag code from phone to phone, each of which is worked on
by different developers who for some reason are never allowed to talk to
each other.

Post by a***@schurmann.org
Finally, the
wallpaper image format is proprietary to LG which requires further
finessing in BitPim.

I believe that format is also used on the other phones as well.
When you select an image as your wallpaper then the .bit file
is created from the selected file contents.

Post by a***@schurmann.org
I have added support in conversions.py for converting between this LG
proprietary format and BMP files. (Side note - I only support 128x128
24BPP BMP files. The LG files are 128x128 16BPP-R5G6B5 format.)

That BMP format is probably what the vx4500 uses then. We have
been trying quite hard to figure it out. It would be really useful if
you could write code that takes any sized 24 bit BMP and converts to the
same sized 16 bit BMP.

Post by a***@schurmann.org
it. I have enabled reading in BitPim but currently writing is not
suppported. This will be my next major step in development.

On all the other LG phones you can take a filesystem backup of the pim
directory, and then go ahead and do your development. When
you want things back to how they were, restore the pim directory
and reboot the phone.

Post by a***@schurmann.org
I have not spent one second looking at this. I hope to get to it soon
and I hope that it will just work! ;-)

The VX4400 calendar code and hence all the models that inherit from it
do not work correctly at the moment.

Post by a***@schurmann.org
I have put the necessary info in com_lgvx3200.py in support of
autodetect.

[Roger Binns]

Post by Bruce S
2. Auto-detect is not working. The problem appears to be related to
exactly what you describe below, i.e. the port I am using (COM3) has
class='serial' and not 'modem' therefore is it not used in the phone
detection process.

That is correct. 'modem' is never the correct type for LG phones.
Sometimes 'serial' is actually a modem, but only with phones using
a USB to serial connection. I will be updating the LG detection code
at some point and all this will end up working right.

Roger