How is Android actually ported to work on the Vogue?
Are you guys literally taking the source code, changing things, compiling & releasing it?
How have you guys learned how to do it?
I'm really interested in helping out and would like to learn more, so any info is great!
Still interested. If any developers could chime in I'd really appreciate it.
Even if you just post a link to some resources I could read.
I googled...I found..
http://www.kandroid.org/android_pdk/index.html
It may be old IDK....Have fun
Thanks!
If anyone has anything else.. please post!
http://cs-alb-pc3.massey.ac.nz/vogue/
^A bit of info about how the project came to be and progressed
Thank you for the reply!
So, when it comes to myn and plemen releasing their builds, what exactly are they doing? Are they getting the source code from Google and completely customizing it, or are they customizing a source that has already been ported for the Vogue? Or... what?
To summarize:
The brunt of the porting effort is in the kernel (the heart of Linux) - a kernel which supports the Vogue hardware needed to be constructed, and the Android-specific extensions added and made to support the hardware. Martin (dzo) did most of the work on that.
Then, there are some core user-space libraries in Android which interface with the hardware and kernel (audio and radio being the big two, with lights, GPS, camera, etc. following). These also needed to be created and updated to support the Vogue hardware. Each time a new Android version comes out, these libraries tend to change and parts need to be rewritten to keep up with Android. A lot of people were and are instrumental in this process.
Then comes the questions you're asking, the "userland" pieces of the build: porters can start from an AOSP (Android Open Source Project) build, which is built ground-up from the released Android sources, a build from another phone (Tattoo, Hero, Droid, etc.), or an SDK emulator build (which is usually not preferred because SDK builds have extra debugging and are missing features for real hardware). To "port" a build, the Vogue libraries are copied in and init scripts and build properties are updated to support the Vogue's screen resolution and hardware initialization. Some porters go an extra mile and unpack, modify, and repack application data to support 320x240 better or to add new themes. For the most part, this is what people like myn and plemen do.
Builds can also be "zipaligned" (package files are aligned to match cache and block boundaries, so they're loaded faster), and image files downsized or removed to enhance speed.
* Large WVGA screen with a single aspect ratio (which means BlackBerry-style devices won't be readily available to begin with)
* Five specific hardware buttons required: Start, back, search (a dedicated Bing button), camera button, and power -- no more, no less
* Capacitive multitouch
* CPU and GPU requirements (beginning with Qualcomm's Snapdragon as the go-to processor)
* WiFi
* AGPS
* Accelerometer
* FM radio
* High resolution camera
Well does the hd2 have these ?
Well does this forum has 1000 topics going on about this issue?
this requirements are the latest and most reliable to be official. So i wanted to share them Source Engadget.
HD2 meets all requirements and runs WP7 perfectly.
I'm not going to give you any evidence of this, just believe it or not. If you don't, well, sorry.
Ok, before the HD2 android rom scene completely explodes with loads of releases, can chefs ensure (or bug cotulla ) to get a kernel that supports iptables / netfilter for Froyo-based roms?
This is needed for apps like Droidwall (an android firewall) and "Wireless Tether" to work... thanks
Apps like Droidwall is esp. useful for those of us who aren't on unlimited data plans and don't want every app they have installed getting on the internet without explicit permissions.
I second this
Me third
Sent from my HD2 using smoke signals
me forth
Why bug others while you can do it on your own?
to compile your own kernel check
http://htc-linux.org/wiki/index.php?title=QuickDeveloperStartGuide#Kernel
use htc-msm-2.6.32 branch and htcleo_defconfig
various recent power management features and other things found in recent Cotulla zImages not included because he does not want to show the code yet. but to try routing stuff (guess you want to see access 3g wifi point?) it's good to go.
dcordes said:
Why bug others while you can do it on your own?
to compile your own kernel check
http://htc-linux.org/wiki/index.php?title=QuickDeveloperStartGuide#Kernel
use htc-msm-2.6.32 branch and htcleo_defconfig
various recent power management features and other things found in recent Cotulla zImages not included because he does not want to show the code yet. but to try routing stuff (guess you want to see access 3g wifi point?) it's good to go.
Click to expand...
Click to collapse
Cause I am dumb as a brick when it comes to Linux stuff??? And it's just a notion to the devs (like yourself) to implement it in the near future
dcordes said:
Why bug others while you can do it on your own?
to compile your own kernel check
http://htc-linux.org/wiki/index.php?title=QuickDeveloperStartGuide#Kernel
use htc-msm-2.6.32 branch and htcleo_defconfig
various recent power management features and other things found in recent Cotulla zImages not included because he does not want to show the code yet. but to try routing stuff (guess you want to see access 3g wifi point?) it's good to go.
Click to expand...
Click to collapse
I don't mind trying it out and compiling my own, but as always if someone's already working on something it's probably faster for them to get the changes made than starting from scratch... hence the request.
thxn. teşekkürler.
Hello XDA developers,
As you know, Atmel maXTouch touchscreen controllers are used in a large percentage of Android phones and tablets out there.
I wanted to let you know that the latest patches for the official Atmel maXTouch Linux driver are available on GitHub. This will allow you to get the latest up to date changes before they make it into the mainline kernel.
On GitHub, search for user "atmel-maxtouch"
Happy hacking
Best regards,
Sherif
Product Marketing Manager - Atmel
thank u for ur valuable information, well can u pls post what are the latest changes and updates. that will help the devs much more.
Hi showlyshah,
The latest updates include the following:
- Support for Atmel's mXT224E, mXT768E, and mXT540E chipsets
- Support for both protocol A and protocol B reporting
- Support for kernel 3.0 in addition to kernel 2.6.35
More details are available on GitHub in the release notes.
Regards,
Sherif
Is https://github.com/atmel-maxtouch the correct URL?
Unfortunately, if it is, the drivers in this repository are structured completely differently from the ones included in many vendor source drops, and unfortunately this causes great negative impact on their usefulness.
See, for example:
https://github.com/Entropy512/linux_kernel_sgh-i777/tree/master/drivers/input/touchscreen - This includes the mxt224 drivers as implemented by Samsung on their device (Galaxy S II)
https://github.com/atmel-maxtouch/linux/tree/master/drivers/input/touchscreen - mxt224_u1.c is completely missing, indicating that the driver here is incomplete or structured very differently from the one used by Samsung, making it very difficult to use. Also, the few files there that do pertain to Atmel MXT such as atmel_mxt_ts.c in there appear identical to the mainline Linux repo.
Entropy512 said:
Is https://github.com/atmel-maxtouch the correct URL?
Unfortunately, if it is, the drivers in this repository are structured completely differently from the ones included in many vendor source drops, and unfortunately this causes great negative impact on their usefulness.
Click to expand...
Click to collapse
But it's not Atmel who are to blame. Atmel are doing a great job working directly with upstream so that all the users of mainline linux can benefit. I have been using the drivers from the vanilla kernel for quite a while on both my tegra tablet (with chromium kernel) and galaxy s2, and they work just fine, supporting multitouch in xorg in ubuntu.
The problem is OEMs who do crap like hardcoding/hacking drivers instead of using platform data, use machine-specific hacks, custom interfaces and a lot of copy-paste. That's the essence of modern consumer electronics business - no one cares for quality, only about releasing early.
Entropy512 said:
Unfortunately, if it is, the drivers in this repository are structured completely differently from the ones included in many vendor source drops, and unfortunately this causes great negative impact on their usefulness.
See, for example:
linux_kernel_sgh-i777/tree/master/drivers/input/touchscreen - This includes the mxt224 drivers as implemented by Samsung on their device (Galaxy S II)
atmel-maxtouch/linux/tree/master/drivers/input/touchscreen - mxt224_u1.c is completely missing, indicating that the driver here is incomplete or structured very differently from the one used by Samsung, making it very difficult to use. Also, the few files there that do pertain to Atmel MXT such as atmel_mxt_ts.c in there appear identical to the mainline Linux repo.
Click to expand...
Click to collapse
I think you're looking at the unchanged mainline branch: the driver releases are as tags.
The advantage of these drivers is that they are generic for all chips in the maxtouch series. mxt224_u1.c is just a renamed atmel_mxt_ts.c, it contains lots of mxt224 specific configuration and it's unlikely that it will go upstream.
You will also find some user-space tools for extracting config files in a format the kernel driver can load, on the same github account.
Missed the tags, thanks for the additional info!
I'll look into maybe playing with this when ICS time rolls around. It's getting late in the game to do a major driver rework on the Gingerbread kernel I maintain.
sherifhanna said:
Hi showlyshah,
The latest updates include the following:
- Support for Atmel's mXT224E, mXT768E, and mXT540E chipsets
- Support for both protocol A and protocol B reporting
- Support for kernel 3.0 in addition to kernel 2.6.35
More details are available on GitHub in the release notes.
Regards,
Sherif
Click to expand...
Click to collapse
Hi Sherif,
I found the project in Github, but am not able to find the the release notes. Does this driver support the Atmel mXT336S at this time?
Thank you
Hi omaha64,
Support for mXT336S is in progress.
Regards,
Sherif
Question,
I am trying to back-port the 2.6.35.7 driver to 2.6.32. I have mostly succeeded, but probe() fails because of missing platform_data. Digging through the driver code, I found the platform data structure in include/linux/i2c/atmel_mxt_ts.h:
Code:
struct mxt_platform_data {
unsigned long irqflags;
u8(*read_chg) (void);
};
So I assume that in my board file (where my i2c_board_info arrays live) I would want to create a static instance of the above struct and store a pointer to it in the .platform_data member of the i2c_board_info struct, right? But what is the preferred initialization, and what is read_chg supposed to actually do? What's the consequences of just setting it to NULL? (I know it won't crash because the driver checks it before calling it)
Need atmel mxt224 driver for Windows embedded compact 7
sherifhanna said:
Hello XDA developers,
As you know, Atmel maXTouch touchscreen controllers are used in a large percentage of Android phones and tablets out there.
I wanted to let you know that the latest patches for the official Atmel maXTouch Linux driver are available on GitHub. This will allow you to get the latest up to date changes before they make it into the mainline kernel.
On GitHub, search for user "atmel-maxtouch"
Happy hacking
Best regards,
Sherif
Product Marketing Manager - Atmel
Click to expand...
Click to collapse
Hi,
Can you please send me the multi touch driver for ATMEL MXT224(Stream interface PDD layer) for Windows Embedded compact 7.
Thanks in Advance,
Rag
Android Driver Initialization
Hi,
I would like to use MaxTouch mxt224 on a TI am335x-evm board running Android ICS, I'm looking for documentation on how to initialize mxt224 driver from board's configuration file. Can someone help me?
Thanks.
ceskobassman said:
Hi,
I would like to use MaxTouch mxt224 on a TI am335x-evm board running Android ICS, I'm looking for documentation on how to initialize mxt224 driver from board's configuration file. Can someone help me?
Thanks.
Click to expand...
Click to collapse
.
I don't know if there's such documentation to tell you how to initialize. At least a sample exists; look here:
arch/arm/mach-exynos4/mach-nuri.c
The values in "mxt_init_vals" come from Atmel's mxt224 datasheets/manual, so you'll have to find those. I would be surprised if you could not find these by Googling. When I was trying to get the mxt224 to work on an Omap4 board, I had to hack up the driver a little to handle the reset going to the IC, and to handle the /READY line from the IC to the host. Also, for ICS, you will need to have an IDC file in your root file system. Just Google for "Android Input Device Configuration File" (I'm new here and cannot post links yet).
Without that IDC file, Android considers the touch device to be a pointing device (like a mouse).
Good luck
Atmel Mxt768e Driver details
Hi Sherif & All,
Can you please share the atmel MaxTouch mxt768e driver link, I would also request you to share the driver which has the implementation for fIrmware upgrade.
Thanks,
Balaji S
Is there some place I can learn to understand and modify these? I've never done driver development before. Before I waste any time with this, can someone confirm if the input lag in most devices is because of filtering in the driver or because of the Atmel hardware?
KurianOfBorg said:
Is there some place I can learn to understand and modify these? I've never done driver development before. Before I waste any time with this, can someone confirm if the input lag in most devices is because of filtering in the driver or because of the Atmel hardware?
Click to expand...
Click to collapse
I don't think you'll be able to find a single place that describes the driver. Luckily, these drivers are small, the mxt224 is just a single C file. I've looked at the mxt224/mxt336, so the following info is specific to those. Some high level info for you to get started:
* The driver allows the exchange of "objects" between the touch IC and the host processor. To understand what the objects are, you'll need to find the datasheets/manual for the chip you're using. Just try Googling for it. Objects from the host to the IC are typically configuration data, and objects from the IC are probably touch data
* In the case of the mxt224/336, the driver needs the I2C driver
* The driver has a structure that needs to be setup from your board file (example arch/arm/mach-omap2/board-???.c). This structure has some configuration data needed by the driver
* Typically, there's a reset line that has to be pulled high on the board. May need pinmuxing to set the functionality of the pin correctly.
* The IC will also have a /CHG line that will go low when it has data to send to host. You will need to set up pinmuxing for this pin as well.
* The driver has an interrupt routine handling the /CHG line. When a touch/drag happens, objects will be sent to the driver to process. The driver formats the data and forward that up to the user space via the input subsystem.
* If you're doing this for Android, you'll need an .idc file in your root file system. Info: {link removed because I'm new. Just google Android IDC }
* The driver will look for a config file in /system/vendor/firmware, upon starting up
I can't comment too much on the lag you're talking about because I don't know the nature of the lag you're seeing. But I can tell you that the Atmel touch IC needs a "tuning" process where the internal parameters have to be adjusted to operate properly.
If you find more info on this subject, please post it here.
omaha64 said:
I can't comment too much on the lag you're talking about because I don't know the nature of the lag you're seeing. But I can tell you that the Atmel touch IC needs a "tuning" process where the internal parameters have to be adjusted to operate properly.
If you find more info on this subject, please post it here.
Click to expand...
Click to collapse
The "lag" is because the touchscreen does not recognise fast taps. You must press and hold your finger on the screen for several milliseconds before it actually recognises a touch. If it was purely a latency, then even a fast tap would be recognised after a delay. In this case, only a continuous press of a minimum duration is recognised. This makes the screen unresponsive and useless for games that need taps.
Is this something that can be resolved in the driver? I have a feeling this is coded in the firmware blob that gets uploaded to the touchscreen on initialisation.
KurianOfBorg said:
The "lag" is because the touchscreen does not recognise fast taps. You must press and hold your finger on the screen for several milliseconds before it actually recognises a touch. If it was purely a latency, then even a fast tap would be recognised after a delay. In this case, only a continuous press of a minimum duration is recognised. This makes the screen unresponsive and useless for games that need taps.
Is this something that can be resolved in the driver? I have a feeling this is coded in the firmware blob that gets uploaded to the touchscreen on initialisation.
Click to expand...
Click to collapse
I believe that if the issue you're describing is due to the IC's noise rejection algorithm, then you may be able to alter that in the driver. There are params in the chip such as number of valid ADC samples for the touch to be recognized as a true touch, that you can play with. But I don't know if you can change these parameters on the fly, or has to be done at start up. I haven't played with these params. See if you can grab hold of a "Protocol Guide" for the touch controller that you're working with. That shows all the params that you can change. In fact, you may be able to alter some of these params without having to touch the driver; search for mxt_app in github. I've used mxt_app to load configuration and change T9 object before, but that's the extent of my use of it.
Thanks for your help. Time to start reading. Some of the mach-* initialisation params can be changed at runtime such as the Vitalij value.
What is the real world best case input latency of these controllers? Can the Galaxy S2's touchscreen actually be made as good as the iPhone 5 or are the iPhone controllers simply superior?