Android OS Forum banner
41 - 60 of 109 Posts

·
Android Dev
Joined
·
61 Posts
Discussion Starter · #41 ·
scifan said:
In the Aurora kernel set - from Kconfig
config TOUCHSCREEN_CY8C_TS
tristate "Cypress TMA300-TMG200 based touchscreens"
depends on I2C
default n
help
Say Y here if you have a Cypress TMA300/TMG200 based touchscreen.
TMA300 is a multi-touch screen which can report upto 10
touches at a time. TMG200 supports 2 touches.

If unsure, say N.

To compile this driver as a module, choose M here: the
module will be called cy8c_ts.

config TOUCHSCREEN_CYTTSP_I2C
tristate "Cypress TTSP based touchscreens"
depends on I2C
default n
help
Say Y here if you have a Cypress TTSP based touchscreen.
TMA300 is a multi-touch screen which can report upto 10
touches at a time.

If unsure, say N.

To compile this driver as a module, choose M here: the
module will be called cyttsp-i2c.

The Palm Kernel has both of those, but adds a 3rd one:

config TOUCHSCREEN_CY8CTMA395
tristate "Cypress TMA395 capacitive touchscreen controller"
default n
help
Say Y here if you have a CY8CTMA395 based touchscreen controller

If unsure, say N.

To comile this driver as a module, choose M here: the module
will be called cy8ctma395

...

Looks like cy8ctma395 is the one to use...

However, this one references an include that's located in a different area of the palm kernel source (include/linux/cy8ctma395.h)

Not sure if that's useful or not, but it seems like it should be...

This would plug into the aurora kernel source...
well, should...

:)
Did some research at the Aurora GIT hub and found some interesting stuff:
Check this change history out:
https://www.codeaurora.org/gitweb/q...f42439e8a516;hb=refs/heads/android-msm-2.6.35

Then this commit:
https://www.codeaurora.org/gitweb/q...it;h=1bb15c9a431c55b3d81fa7b0ecd9f720bfa38237

I think this is the commit that added in the HP's Touchscreen support.
Check out this diff:
https://www.codeaurora.org/gitweb/q...;hpb=cb3ca5afc0a26c7f7c94ff382078de16080654ab

and this one:
https://www.codeaurora.org/gitweb/q...;hpb=cb3ca5afc0a26c7f7c94ff382078de16080654ab

and this one:
https://www.codeaurora.org/gitweb/q...;hpb=cb3ca5afc0a26c7f7c94ff382078de16080654ab

TecKnight
 

·
Android Lover
Joined
·
238 Posts
TecKnight said:
Scifan,
Good stuff.
I am on it now.
Thanks,
TecKnight
One thing that concerns me is that I'm not seeing anything referencing the driver being loaded in dmesg... lsmod doesn't show it as a module - I'm assuming something that critical you wouldn't want to build as a module anyway... the stuff in dmesg appears to be related to a usb driver from cypress... (of course, I also don't get where the config file is stored in the aurora configuration info... ) **I know enough about linux to not be enough for android**
 

·
Android Lover
Joined
·
238 Posts
TecKnight said:
When I was checking, I noticed that the cy8* files that existed in both the patched palm kernel and the aurora code were the same... the only difference appeared to be the 395 files... and I know my config file from my tablet points to the 395 drivers...

Not sure...

Here's the driver files I'd identified as different...
 

·
Android Dev
Joined
·
61 Posts
scifan said:
When I was checking, I noticed that the cy8* files that existed in both the patched palm kernel and the aurora code were the same... the only difference appeared to be the 395 files... and I know my config file from my tablet points to the 395 drivers...

Not sure...

Here's the driver files I'd identified as different...
Looking at the cy8ctma395.c in the zip you sent, it almost looks like it could be useful to setup a small program for testing that includes this code and try calling:


cy8ctma395_device_probe(struct platform_device *pdev)
and maybe
port_acquire(struct device *dev, u32 *id, u8 *rev)



A chunk of the port_acquire code starting immediately after local_irq_enable(); is bracketed by the functions:

CPUFREQ_HOLD_SYNC();
and​

CPUFREQ_UNHOLD();

I suspect the bracketed code is timing critical code that would have serious issues if the CPU slowed down to try saving power or the like. Looks to me like it is reading and writing directly to the touchscreen device registers.

Looks like cy8ctma395.c needs cy8ctma395.h as well. I don't seem to have that file anywhere.

This is a driver apparently sent out from Cypress within the last day or two by a Cypress representative:

[url]http://hp-kryptonite.info/docs/KT/CY8CTMA395_Android_Drivers/[/URL]

Notice the email states:
Betreff: WG: CY8CTMA395 Android Drivers
Anlagen: CY_I2CDRIVER_v11.zip

Hi, xxx
In fact before HP refreshing their webOS image, all HP touchpad TSP controller board were used Android to run the MFG procedure. Attached file is the latest TMA395 Android driver. The significant difference is that the HP touchpad TSP controller firmware has no bootloader support so when you want to bring up the device with this driver a little effort need be cost take care of this difference. This job has been done by HP software team before.

Best regards
Luther
The Cypress rep indicates that ALL touchpads were initially loaded with Android prior to being imaged with webOS.
How interesting.

TecKnight
 

·
Android Beginner
Joined
·
12 Posts
TecKnight said:
The Cypress rep indicates that ALL touchpads were initially loaded with Android prior to being imaged with webOS.
How interesting.

TecKnight
Now if only they could supply that image..!
 

·
Android Apprentice
Joined
·
22 Posts
benny said:
Now if only they could supply that image..!
Doubt they could supply anything but the driver, since the email mentioned that using it in the Boot-loader was done before by HP engineers, so HP probably wouldn't want it out to the public, as it will enable android to replace webOS which they want to keep, plus they make money from apps.

That is unless hp is abandoning the whole thing, then maybe people should ask hp itself to release the whole build!
 

·
Android Beginner
Joined
·
12 Posts
LimitBreak said:
Doubt they could supply anything but the driver, since the email mentioned that using it in the Boot-loader was done before by HP engineers, so HP probably wouldn't want it out to the public, as it will enable android to replace webOS which they want to keep, plus they make money from apps.

That is unless hp is abandoning the whole thing, then maybe people should ask hp itself to release the whole build!
I highley doubt HP would give anyone the build, but I presume someone will have asked them already?
 

·
Android Dev
Joined
·
61 Posts
Discussion Starter · #49 ·
benny said:
I highley doubt HP would give anyone the build, but I presume someone will have asked them already?
You bring up an interesting point. I imagine that nobody even considered asking HP, presuming the obvious negative response.

I'm not even sure to whom you would make such a request, and of course it would almost definitely be denied, but depending on how you asked (I personally would recommend an open letter "public" type of request), emphasizing that HP has discontinued the touchpad and in order to provide value/support for touchpad owners would HP please release their source. It actually would score HP some serious props with their future customers, in my opinion, offsetting much of the negativity they have received lately from the IT community, but again, I seriously doubt they would release it.
TecKnight
 

·
Android Apprentice
Joined
·
22 Posts
TecKnight said:
You bring up an interesting point. I imagine that nobody even considered asking HP, presuming the obvious negative response.

I'm not even sure to whom you would make such a request, and of course it would almost definitely be denied, but depending on how you asked (I personally would recommend an open letter "public" type of request), emphasizing that HP has discontinued the touchpad and in order to provide value/support for touchpad owners would HP please release their source. It actually would score HP some serious props with their future customers, in my opinion, offsetting much of the negativity they have received lately from the IT community, but again, I seriously doubt they would release it.
TecKnight
Lets start an open letter asking hp to fix all known bugs with 3.0.2 including the browser; which are plenty otherwise enable the consumers through developers to make alternatives and that would be by supplying android drivers bootloader images that were used to make the TouchPad!
Without future support for a discontinued product consumers need to be self reliant!
 

·
Android Beginner
Joined
·
10 Posts
TecKnight said:
You bring up an interesting point. I imagine that nobody even considered asking HP, presuming the obvious negative response.

I'm not even sure to whom you would make such a request, and of course it would almost definitely be denied, but depending on how you asked (I personally would recommend an open letter "public" type of request), emphasizing that HP has discontinued the touchpad and in order to provide value/support for touchpad owners would HP please release their source. It actually would score HP some serious props with their future customers, in my opinion, offsetting much of the negativity they have received lately from the IT community, but again, I seriously doubt they would release it.
TecKnight
But HP are not dropping WebOS are they, they are just dropping their hardware and splitting WebOS off to another company. Having spent $1.2billion on Palm to get hold of WebOS, I think they will be inclined to try and make a go of it on someone else's hardware. You can ask if they will supply it but I doubt it very much.
 

·
Android Lover
Joined
·
238 Posts
the tar.gz file I linked should have had both .c and .h files... If not let me know and I'logic and upload.

so, all of these were loaded with android...

(sometimes I hate autocorrect)
 

·
Android Dev
Joined
·
61 Posts
Discussion Starter · #53 ·
scifan said:
the tar.gz file I linked should have had both .c and .h files... If not let me know and I'logic and upload.

so, all of these were loaded with android...

(sometimes I hate autocorrect)
Yes, apparently the units found with Android loaded were simply never overwritten with webOS.
 

·
Android Dev
Joined
·
61 Posts
Discussion Starter · #54 ·
scifan said:
the tar.gz file I linked should have had both .c and .h files... If not let me know and I'logic and upload.
Of course, I neglected to check the "include" folder. It is there of course.
 

·
Android Lover
Joined
·
238 Posts
Yeah, HP decided to put it in there instead...

I did include the Kconfig... not sure if I included the Makefile though... you may want to double check...

I noticed in the palm config, that there's a usb gadget file for novaterm... not sure if you wanted those... (some of the support files seemed to head down a bad path...)
 

·
Android Lover
Joined
·
238 Posts
TecKnight said:
Yes, apparently the units found with Android loaded were simply never overwritten with webOS.
So... two thoughts on this comment... if this is the case... (and we had someone on here who was visible previously with such a unit)... if they were knowledgeable enough, they could boot into recovery, and DD copies of the boot partition and system partitions and output them into files on the data partition... would be a challenge to do the data partition since there's no SDcard hardware to put it out on...

I've heard that there are 17 partitions on the unit that had the factory load on it...

I tend to wonder if the boot volume's the same... and if so, do they use LVM, and if so, what the LVM configuration looks like...

Lets hope the Aurora code base is close enough to make things happy...
 

·
Android Lover
Joined
·
238 Posts
oh yeah, I was poking around last night and noticed that the boot partition is /mmcblk0p13 which is ext3 format.

There are 14 partitions defined, but it appears they're part of some wonky LVM configuration...

The LVM group is named store (I think)

and then there's several partition's created in that under a different block device...

Interesting configuration... IF I understand things correctly, as long as the boot partition it's self isn't fubar'd, you can actually completely flatten the LVM partition/configuration and still recover things....

I thought I saw at one point where they were mounting via UUID rather than /dev/devicename nomenclature... but I could be wrong on that. I have noticed that the log files are wrapped at a fairly small amount of info... the dmesg log gets punted pretty quickly... though mine looks very similar to the one someone else posted on here...
 

·
Android Dev
Joined
·
61 Posts
scifan said:
oh yeah, I was poking around last night and noticed that the boot partition is /mmcblk0p13 which is ext3 format.

There are 14 partitions defined, but it appears they're part of some wonky LVM configuration...

The LVM group is named store (I think)

and then there's several partition's created in that under a different block device...

Interesting configuration... IF I understand things correctly, as long as the boot partition it's self isn't fubar'd, you can actually completely flatten the LVM partition/configuration and still recover things....

I thought I saw at one point where they were mounting via UUID rather than /dev/devicename nomenclature... but I could be wrong on that. I have noticed that the log files are wrapped at a fairly small amount of info... the dmesg log gets punted pretty quickly... though mine looks very similar to the one someone else posted on here...
Yes SciFan...
You DO NOT want to mess with partitions 1-13.
I know for a fact one of the Touchdroid devs made a brick by messing with partition 6 and I have been told not to mess with any part < 14.
You can play with part 14 or create new partitions w/o issue.
TecKnight
 

·
Android Dev
Joined
·
61 Posts
Discussion Starter · #59 ·
I've heard that there are 17 partitions on the unit that had the factory load on it...
Yes I heard this as well. So far all we have are .img files from the TP with Android.

TecKnight
 

·
Premium Member
Joined
·
1,812 Posts
if you unpack the webos Dr restore file, there is a file (topaz.xml) that describes in detail the partition structure.
 
41 - 60 of 109 Posts
Top