Database Users

Learning how to program for Windows Mobile?

I've done some searching, and I know Windows CE uses Win32, which I know to an extent. I was curious if there are any good free resources for learning WinCE-Win32, or if I should simply use my existing books for MFC/Win32. Microsoft's site kinda sketchy, and MSDN not being very useful. I did get Microsoft Embedded Visual C++ working and compiled a test app which worked on my MDA and on the emulator.

i would just start coding
miniMFC and compact .net framework is soo close it's only
some controls and options you dont have
ortherwise it's the same thing
learning by doing and having ones fingers down and dirty
into the code is where you learn the most

Yep, that's just how I learned when I switched to coding for PPCs.
Any way here are a few major differences to start you off:
1) All API's that use strings are in UNICODE. ASCII versions were removed.
2) For most API's that have an 'ext' version the regular version was removed. Example: ExtTextOut - yes, TextOut - no.
3) When dealing with files, all paths must be absolute. No '..\file.x' and 'file.x' will give you the file in device root and not the app directory.
And here is a nice site for pocket PC specific apps:
www.pocketpcdn.com
Has articles on just about everything from making dialogs not full screen to writing today plug-ins.

levenum said:
Yep, that's just how I learned when I switched to coding for PPCs.
Any way here are a few major differences to start you off:
1) All API's that use strings are in UNICODE. ASCII versions were removed.
2) For most API's that have an 'ext' version the regular version was removed. Example: ExtTextOut - yes, TextOut - no.
3) When dealing with files, all paths must be absolute. No '..\file.x' and 'file.x' will give you the file in device root and not the app directory.
And here is a nice site for pocket PC specific apps:
www.pocketpcdn.com
Has articles on just about everything from making dialogs not full screen to writing today plug-ins.
Click to expand...
Click to collapse
I knew about how everything was Unicode. Is there an easy way to create unicode strings? I remember there was something in MFC macro like TEXT() that did something like that, but the specifics are missing. I remember there was a knowledge base article on this, but I can't find it.
Also, what's the difference between the Ext version and the non-ext versions of an app?
EDIT: Unless I'm mistaken, I just need to put my strings in _T("*string*")

Yes, you're right, this is how you write strings in your code:
Code:
WCHAR uniStr[] = L"Unicode string";
or if you are using MFC:
Code:
CString uniStr = _T("Unicode string");
and if you have a ASCII string you want converted to UNICODE
use mbstowcs function. (CString class has a built in conversion)
As for the 'ext' API's they just give you more parameters to better control the result of whatever they are doing. In desktop windows if you didn't want to call a function with 10 parameters you usually had a simpler version of it where some things were default.
Example:
Code:
BOOL TextOut(
HDC hdc, // handle to DC
int nXStart, // x-coordinate of starting position
int nYStart, // y-coordinate of starting position
LPCTSTR lpString, // character string
int cbString // number of characters
); //5 parameters
BOOL ExtTextOut(
HDC hdc, // handle to DC
int X, // x-coordinate of reference point
int Y, // y-coordinate of reference point
UINT fuOptions, // text-output options
CONST RECT *lprc, // optional dimensions
LPCTSTR lpString, // string
UINT cbCount, // number of characters in string
CONST INT *lpDx // array of spacing values
); // 8 parameters

what would be your suggestion for a newbie to learn programming for PPC?
I'm beggining to have interest in doing this but have absolutely no idea where to start.
thanks for any advise.

For complete newbies, I wrote this post a while back:
http://forum.xda-developers.com/viewtopic.php?p=209136#209136
V

[APP][updated 25/08/2008 - Ver 0.4] YABGBT - Yet Another Ball Game Based on Tilt

Hy Guys,
Here is my first dev for the touch Diamond.
It is a kind of juggle ball game using tilt sensor SDK and XFlib.
It is just a test for me, so I don't kown if i will had time to improve it.
Ver 0.4.1 [11/01/2009]:
Added : Suport for Touch HD
Ver 0.4 [25/08/2008]:
Added : Now the backlight is allways on
Added : about screen
Ver 0.3.1 [22/08/2008]:
Added : You can chose if the camera follow the ball or the base
Added : Sound when ball hit the base
Ver 0.3 [21/08/2008]:
Added : Biggest playing aera
Ver 0.2 [10/08/2008]:
Added : Menu to select difficulty level
p.s. the game is also playable with stylus, so it is not reserved to the diamond

Hey, that plays quite allright!
First things to polish up would be a higher ball res, a nice background and another cooler paddle image. Bouncesound ?
But gameplay is pretty great already, well done !! Got it bouncing for about 5 minutes and enjoyed it

Awsome gonna chek it out after the Dammm JOb!
Cheers and thanks!

cool...will try it out asap

Pretty cool little app. Good work

Stupid question... But how to play?

potiron4o said:
Stupid question... But how to play?
Click to expand...
Click to collapse
the scene is view by the top.. so move your phone to juggle with the ball

Video of the game here.
http://wmpoweruser.com/?p=621
Great game.
May I suggest to the developer that he may want to also make the square bigger and smaller based on the height of the ball, and further make the background dynamic, so that it e.g. moves in the opposite direction to the ball, to exploit the paralax effect and give the user a feeling they are actually looking into a 3 dimensional box.
Surur

tanks for the video and the review.
I will think about adding paralax effect in the next weeks !

update
update 0.3 (21/082008)
new playing aera !

update 0.3.1 (22/082008)
Now you can chose if the camera will follow the ball or if it will follow the base!
I Need Help :
I hope some Dev will read this,
this game use the Tilt sensor, so the game goes to standby mode after few seconds because we don't touch screen. I don't kown how to prevent the standby mode, so if someone got an idea.....
(i use C language)
edit : the forum got a new section, so i guess my game is not in the right one, so moderator could you move this thread ! thanks

great work

hellgod said:
update 0.3.1 (22/082008)
Now you can chose if the camera will follow the ball or if it will follow the base!
I Need Help :
I hope some Dev will read this,
this game use the Tilt sensor, so the game goes to standby mode after few seconds because we don't touch screen. I don't kown how to prevent the standby mode, so if someone got an idea.....
(i use C language)
edit : the forum got a new section, so i guess my game is not in the right one, so moderator could you move this thread ! thanks
Click to expand...
Click to collapse
this is c# - should work on c, too... found it on msdn and there should be an example for c, too... I just don't find the URL, so google may help (just enter something from below ;-))
public enum CEDevicePowerState
{
D0 = 0, //Full on
D1, //Low on
D2, //Standby
D3, //Sleep
D4, //Off
}
[DllImport("coredll.dll", SetLastError = true)]
static extern IntPtr SetPowerRequirement(string device, CEDevicePowerState ceDevicePowerState, uint deviceFlags, IntPtr systemState, ulong stateFlags);
[DllImport("coredll.dll", SetLastError = true)]
static extern int ReleasePowerRequirement(IntPtr handle);
[DllImport("coredll.dll", SetLastError = true)]
static extern void SystemIdleTimerReset();
on the onload i do following:
IntPtr handle = SetPowerRequirement("BKL1:", CEDevicePowerState.D0, 1, IntPtr.Zero, 0);
to release it, try the 2nd handle...
I use a timer which ticks every 10 seconds and performs this:
SystemIdleTimerReset();
I don't know if it's necessary, but I think so... hope that helps...

Thanks a lot Ageye !! it works !!
for information here is the code :
main.c :
Code:
...
...
#define POWER_DLL L"coredll.dll"
typedef enum _CEDEVICE_POWER_STATE {
PwrDeviceUnspecified = -1,
D0 = 0,
D1=1,
D2=2,
D3=3,
D4=4,
PwrDeviceMaximum=5
} CEDEVICE_POWER_STATE, *PCEDEVICE_POWER_STATE;
typedef HANDLE (WINAPI * PFN_SetPowerRequirement)(PVOID,CEDEVICE_POWER_STATE,ULONG,PVOID,ULONG);
PFN_SetPowerRequirement pfnSetPowerRequirement;
typedef DWORD (WINAPI * PFN_ReleasePowerRequirement)(HANDLE);
PFN_ReleasePowerRequirement pfnReleasePowerRequirement;
const int POWER_NAME = 0x00000001;
const int POWER_FORCE = 0x00001000;
HMODULE hPowerlib;
...
...
...
int main(void){
...
...
hPowerlib= LoadLibrary(POWER_DLL);
pfnSetPowerRequirement = (PFN_SetPowerRequirement)GetProcAddress(hPowerlib, L"SetPowerRequirement");
pfnReleasePowerRequirement = (PFN_ReleasePowerRequirement)GetProcAddress(hPowerlib, L"ReleasePowerRequirement");
HANDLE IntPtr = pfnSetPowerRequirement(TEXT("BKL1:"), D0, POWER_NAME | POWER_FORCE,NULL, 0);
...
...
pfnReleasePowerRequirement(IntPtr);
return0;
}

you're welcome!

I am very thanks.............

Awsome. thanks!

I have a problem with this game.
I copy it in the SD, and I execute it, but it has a problem.
The game doesn't work, and it enables the screen to send a report to microsoft.
I don't understand why it happens this.
Thanks a lot.
(sorry, my english is very bad).

skynetent said:
I have a problem with this game.
I copy it in the SD, and I execute it, but it has a problem.
The game doesn't work, and it enables the screen to send a report to microsoft.
I don't understand why it happens this.
Thanks a lot.
(sorry, my english is very bad).
Click to expand...
Click to collapse
Did you use a touch Diamond ?

Oh sorry. I didn't mention it.
I use a HTC touch HD (blackstone)
Thanks.

HTC Sensors (HTCSensorSDK.dll)

Hi, I've seen some sensor implementations and some of them are not good written I think. I've disassembled HTCSensorSDK.dll file to help developers who use HTC sensors. You can look at it to know how it is done.
PF2009

I'm not a developer, but isn't this the same like this?

No, HTCSensorSDK.dll is SDK library from HTC which is used by this. 'Unified Sensor API' imports only some of HTCSensorSDK.dll functions. The author doesn't know how it was implemented. So there are some useless parts e.g.:
enum HTCSensor : uint
{
Something = 0, <--
GSensor = 1,
Light = 2,
Another = 3, <--
}
or signaling events:
// note: I noticed in Scott's code, on the shutdown he fires the "HTC_GSENSOR_SERVICESTART" event again.
// I am guessing that is a bug in his code.
// My theory is the service start/stop manage a reference count to the service.
// Once it hits 0, the service is stopped.
IntPtr hEvent = CreateEvent(IntPtr.Zero, true, false, "HTC_GSENSOR_SERVICESTOP");
SetEvent(hEvent);
CloseHandle(hEvent);

Awesome! You are correct, my implementation of the HTC sensor contains a lot of debug/instrumentation code. But it is private and unused, so it is really just benign code (such as the enum).
The only particular spot I wasn't sure was being done properly was the sensor cleanup; as indicated in my code comment. The only real outstanding issue then is the signaled events. I actually think that is used to start the HTC service that changes the orientation setting in the registry. So that is probably legitimate code. Unless you know otherwise?
The Samsung implementation was a lot easier, because I had a .h file to work with.

accelerometer(lg gm750) method signatures

attached the.dll of the lg gm750 in case they serve of something
USER iamspv
First take a look at the Unified Sensor Api at codeplex.
My solution is based on the Samsung sensor class, modified to meet the peculiarities of the LG GM750.
First of all, the import of the DeviceIoControl in NativeMethods.cs must be modified such way dwIoControlCode is type uint, and the buffers are byte:
Code:
[DllImport("coredll", CharSet = CharSet.Auto, SetLastError = true)]
public static extern bool DeviceIoControl(IntPtr hDevice, uint dwIoControlCode, [In] byte[] inBuffer, int nInBufferSize, [Out] byte[] outBuffer, int nOutBufferSize, ref int pBytesReturned, IntPtr lpOverlapped);
After a long time dissassembling the accelsensor.dll and and a lot of trial and error testing I came to this conclusion that works:
The constant that starts/stops data output becomes:
Code:
const uint ACCOnRot = 0x1014EE8;
const uint ACCOffRot = 0x1014EE8;
and for reading values:
Code:
const uint ACCReadValues = 0x1014F10;
The difference between start and stop comes from the input given in DeviceIoControl method as follows:
Code:
Code:
public static LGAccSensor Create()
{
DeviceIoControl(ACCOnRot, new byte[1] {1}, new byte[4] );
return new LGAccSensor();
}
protected override void Dispose(bool disposing)
{
base.Dispose(disposing);
DeviceIoControl(ACCOffRot, new byte[1] {0}, new byte[1] );
}
The DeviceIoControl inside the accelerometer class becomes
Code:
Code:
public static void DeviceIoControl(uint controlCode, byte[] inBuffer, byte[] outBuffer)
{
IntPtr file = NativeMethods.CreateFile("ACC1:", 0, 0, IntPtr.Zero, ECreationDisposition.OpenExisting, 0, IntPtr.Zero);
if (file == (IntPtr)(-1))
throw new InvalidOperationException("Unable to Create File");
try
{
int bytesReturned = 0;
int inSize = sizeof(byte) * inBuffer.Length;
int outSize = sizeof(byte) * outBuffer.Length;
if (!NativeMethods.DeviceIoControl(file, controlCode, inBuffer, inSize, outBuffer, outSize, ref bytesReturned, IntPtr.Zero))
throw new InvalidOperationException("Unable to perform operation.");
}
finally
{
NativeMethods.CloseHandle(file);
}
}
Note that the accelerometer device is called ACC1:.
Further the method that returns the three component vector becomes
Code:
Code:
public override GVector GetGVector()
{
byte[] outBuffer = new byte[4];
DeviceIoControl(ACCReadValues, new byte[1] {1}, outBuffer);
GVector ret = new GVector();
int accx = outBuffer[2];
if (accx <=31)
ret.X = accx/2.17;
else
ret.X = (accx-64)*0.47;
ret.X = -ret.X;
int accy = outBuffer[1] ;
if (accy <=31)
ret.Y = accy/2.17;
else
ret.Y = (accy - 64) * 0.47;
int accz = outBuffer[0] ;
if (accz <=31)
ret.Z = accz/2.17;
else
ret.Z = (accz - 64) * 0.47;
double somefactor = 1; return ret.Scale(somefactor);
}
Note that the when called with AccReadValues parameter, the DeviceIoControl returns three bytes each of them containing a signed 6 bit 2's complement value.Basicly there are values on 6 bit ranging from -32 to +31. In the docs below there are tables that put in correspondence these values with acceleration in range -1.5g +1.5g which are the limits of the device. The code I wrote returns acceleration in meters/second2 where 1g=9.8 m/s2. That information I extracted from the technical specifications of the MMA7660FC accelerometer, as found at(try a google search). Also, the type of the accelerometer circuit is found in the service manual (I only found the service manual for LG GM730 which is pretty close).The same thing I also posted at codeplex.
Reply With Quote
It already works! There is nothing more to do about it than use the code in your applications (I speak as a programmer and for programmers). I only showed everyone interested in developing for LG GM750 the steps to modify the SamsungGSensor class from "Unified Sensor Api" at codeplex to work with a LG. Just get the rest of the code from there and put it toghether.
Now there are two directions:
Direction #1
If you want to develop applications that aim to be portable between HTC, Samsung, LG, Toshiba, etc, and you want to use Unified Sensor Api then..
the person responsible for the unified api project at codeplex should make the update to the library as soon as possible such way the library should keep compatibility with the adressed devices. I'm just contributing with some results. That's because the initial code was not very general (ie. the initial parameter types to deviceiocontrol invoked from coredll didn't work with this solution) I had to make some modifications to the code that work with the LG but affect other devices' sensor classes. Now, if the update doesn't come up soon, no problem, anyone just gets the code from codeplex, adds a new class for LG, copies code from Samsung, renames Samsung with LG, adds my modifications, corrects syntax errors, compiles, et voila . . the library is updated to support LG GM750.
Direction #2
If you develop only for LG, just write a LG class as presented above and don't care about other devices.
If you don't know how to use your new class, the project at codeplex has some examples and you'll easily see inside the code how to instantiate sensors, how to read data at certain moments using a timer, and how to capture screen rotation events.
And for your long awaited joy to see it working, I attached the sensor test program along with a version of sensors.dll compiled by me, that works for GM750.
Now get your fingers toghether on the keyboard and start developing for LG
now should work in an emulator as that one of htc in omnia splitting of what we arrange

great work!
thanks much!

htcemu v0.91 /sensors.dll Problems
Hello all,
when I last November asked for a htcemu for LG750, I have not expected that there will be a emu dll so soon.
Thanks to iamspv and others, we now can use g-sensor apps as normal.
Nearly - some apps does not work or crash.
So my favorite alarm clock, klaxon crashes when alarm is activated. Waterlevel also does not work. It looks that both apps use the managed code dll sensors.dll. Even if I exchange the original dll with the one posted here from beginning of february, it does not work. Does anybody has a solution for this ?
For using landscape mode in app I now got best results with changescreen which works almost perfect. It is also possible to exclude some programs like some LG apps which do not support landscape mode.

how did you make other apps work? on my layla only test works and nothing else

creative232 said:
attached the.dll of the lg gm750 in case they serve of something
Click to expand...
Click to collapse
Did you create a running VS 2008 solution for this?. I'm interested.
Will this work on other LG's?

[DEV]Porting Nexus S touchscreen drivers to HTC phones for ICS

EDIT:
A better fix has been found for touchscreens using HTCs driver allowing us to actually use the original driver instead of porting another (although porting did seem to work mostly, this seems more ideal).
http://forum.xda-developers.com/showthread.php?p=19047963
Guess I'll leave this all here though in case someone ever looks it up again.
Ok, since I've been getting so many requests for information about how I did this, I decided to start a thread dedicated to it.
With Ice Cream Sandwich, Google seems to have changed the way it expects the touchscreen drivers to behave. Many of the HTC phones (starting with the Evo and Inc) all the way up to current HTC phones utilize some version of HTC's driver (drivers/input/touchscreen/atmel.c) written for the Atmel maXTouch touchscreen. This driver doesn't work at all on ICS. Many people will say its only the SDK port we're working with, but I have a good feeling some adjustments will need to be made to get the HTC driver working when the source is released anyways.
The few drivers that do work are:
synaptics-i2c-rmi.c - for Synaptics TS
---> Nexus One, Desire...possibly others that utilize this driver
mxt224.c - for Atmel maXTouch
---> Samsung Nexus S and most likely other Samsung phones
elan8232-i2c.c for elan TS
---> HTC Leo/HD2
From what I can tell, the only real big different that jumps out at me between these drivers and ours is the way the driver WRITES to the i2c bus. The Samsung and elan drivers both use i2c_master_send to write to the i2c bus. The Synaptics driver does it a little differently, using i2c_smbus_write_byte_data, which appears to do something similar, but needs to be used more often to accomplish the same thing.
The HTC driver uses i2c_transfer, which according to what I've found online, is not the preferred method of writing to the bus and i2c_master_send should be used instead.
It would seem like it would be easier to just modify the existing HTC driver to incorporate the newer method, but I didn't realize that until after I had already gotten the Samsung driver working! It should be possible, but I'm not sure I have the expertise to do this as it would require tweaking a lot of code in the driver.
Anyways, on to what I actually did.
I was able to compile the Samsung driver into cuviper's CM7 kernel, but the driver kept hanging on reading the i2c bus from what I could see. I figured it'd have this problem with writing to it as well, so I changed both methods at the same time.
Here's the original read and write methods from HTC's atmel.c driver
Code:
int i2c_atmel_read(struct i2c_client *client, uint16_t address, uint8_t *data, uint8_t length)
{
int retry;
uint8_t addr[2];
struct i2c_msg msg[] = {
{
.addr = client->addr,
.flags = 0,
.len = 2,
.buf = addr,
},
{
.addr = client->addr,
.flags = I2C_M_RD,
.len = length,
.buf = data,
}
};
addr[0] = address & 0xFF;
addr[1] = (address >> 8) & 0xFF;
for (retry = 0; retry < ATMEL_I2C_RETRY_TIMES; retry++) {
if (i2c_transfer(client->adapter, msg, 2) == 2)
break;
mdelay(10);
}
if (retry == ATMEL_I2C_RETRY_TIMES) {
printk(KERN_ERR "i2c_read_block retry over %d\n",
ATMEL_I2C_RETRY_TIMES);
return -EIO;
}
return 0;
}
int i2c_atmel_write(struct i2c_client *client, uint16_t address, uint8_t *data, uint8_t length)
{
int retry, loop_i;
uint8_t buf[length + 2];
struct i2c_msg msg[] = {
{
.addr = client->addr,
.flags = 0,
.len = length + 2,
.buf = buf,
}
};
buf[0] = address & 0xFF;
buf[1] = (address >> 8) & 0xFF;
for (loop_i = 0; loop_i < length; loop_i++)
buf[loop_i + 2] = data[loop_i];
for (retry = 0; retry < ATMEL_I2C_RETRY_TIMES; retry++) {
if (i2c_transfer(client->adapter, msg, 1) == 1)
break;
mdelay(10);
}
if (retry == ATMEL_I2C_RETRY_TIMES) {
printk(KERN_ERR "i2c_write_block retry over %d\n",
ATMEL_I2C_RETRY_TIMES);
return -EIO;
}
return 0;
}
And here's Samsung's methods from their mxt224.c driver
Code:
static int read_mem(struct mxt224_data *data, u16 reg, u8 len, u8 *buf)
{
int ret;
u16 le_reg = cpu_to_le16(reg);
struct i2c_msg msg[2] = {
{
.addr = data->client->addr,
.flags = 0,
.len = 2,
.buf = (u8 *)&le_reg,
},
{
.addr = data->client->addr,
.flags = I2C_M_RD,
.len = len,
.buf = buf,
},
};
ret = i2c_transfer(data->client->adapter, msg, 2);
if (ret < 0)
return ret;
return ret == 2 ? 0 : -EIO;
}
static int write_mem(struct mxt224_data *data, u16 reg, u8 len, const u8 *buf)
{
int ret;
u8 tmp[len + 2];
put_unaligned_le16(cpu_to_le16(reg), tmp);
memcpy(tmp + 2, buf, len);
ret = i2c_master_send(data->client, tmp, sizeof(tmp));
if (ret < 0)
return ret;
return ret == sizeof(tmp) ? 0 : -EIO;
}
You can see they're very similar. Anyways, for some reason, cpu_to_le16 function either doesn't work correctly with the Snapdragon, or the build isn't linking them right, even though I made sure it had all the right files and #includes. So I took them out. And replaced them with part of the functions from the HTC driver. And after a couple failed attempts at booting, I came up with this:
Code:
static int read_mem(struct mxt224_data *data, u16 reg, u8 len, u8 *buf)
{
int ret;
uint8_t addr[2];
struct i2c_msg msg[] = {
{
.addr = data->client->addr,
.flags = 0,
.len = 2,
.buf = addr,
},
{
.addr = data->client->addr,
.flags = I2C_M_RD,
.len = len,
.buf = buf,
},
};
addr[0] = reg & 0xFF;
addr[1] = (reg >> 8) & 0xFF;
ret = i2c_transfer(data->client->adapter, msg, 2);
if (ret < 0)
return ret;
return ret == 2 ? 0 : -EIO;
}
static int write_mem(struct mxt224_data *data, u16 reg, u8 len, const u8 *buf)
{
int ret;
uint8_t addr[len + 2];
addr[0] = reg & 0xFF;
addr[1] = (reg >> 8) & 0xFF;
memcpy(addr, buf, len);
ret = i2c_master_send(data->client, addr, sizeof(addr));
if (ret < 0)
return ret;
return ret == sizeof(addr) ? 0 : -EIO;
}
After those changes, I was able to use the touchscreen in CM7 just like I had with the HTC driver. Very responsive, no problems whatsoever. Also works fine in the ICS SDK ports. It only works in pointer mode in ICS currently, but that isn't a driver issue I don't think and can be fixed by changing a couple of the configuration files.
The only other things I had to change where in my board init file, but that was simply adding and deleting some of the touchscreen init functions and replacing them with similar ones from the Samsung driver. As well as populating the config info with HTC's values (although they also seemed to work fine with the stock ones from the Samsung build).
Anyways, if you have any questions, or more information please let me know. I could be totally wrong about the i2c bus thing, but as of right now it seems to make sense to me!
Here's my github for anyone that wishes to look at my changes.
Edit: atmel.c is the correct name of the driver source file. I got it mixed up with the way the HTC driver identifies itself in the kernel, which is atmel-touchscreen. Sorry for the confusion. Thanks to the_platypus to catching this.
Also, just wanted to reiterate this should work with just about any HTC phone using the maXTouch sensor. Just grab mxt224.c and .h and put them in the correct spot, modify the Kconfig file for touchscreens, and edit your board init file accordingly.

To clear up some confusion and so I don't have to answer too many PMs, I'm going to add some details about how to get this to work.
First of all, grab mxt224.c, Kconfig, and Makefile from drivers/input/touchscreen/, and place them in your build folder in the same place.
Then do the same with mxt224.h, which is under include/linux/input/.
Go to arch/arm/mach-msm and grab my board-incrediblec.c. Compare it to whatever yours is (i.e. board-supersonic.c).
You'll need to change the name of the power init function for the touchscreen, and do something similar with the config data that I added to my init file. Make sure you scroll alllll the way down until you find the section about virtual keys. Make sure you change the name of "virtualkeys.atmel-touchscreen" to "virtualkeys.mxt224_ts_input" (I think thats correct, I'll check in a bit and correct if I'm wrong).
A note about the config data section for initializing the touchscreen:
I took the values from the original struct that was there from HTC, for my touchscreen revision. Normally, there are multiple hardware revisions of the touchscreen it seems, and upon booting, the kernel checks which one you have, and picks the correct one. I took this out since I was only trying to get it to work on my phone. Now that I know it works, I'm going to go back and readd the code to check the rev so it'll get the right config data.
This also means there's a good chance you need to copy the values from the original HTC init functions and put them into the struct I made. It can be a pain in the ass kind of, but it'll ensure your touchscreen works correctly. I want to note that mine worked fine with the actual Samsung values, but was kind of wonky.
Also, you'll have to edit your .config if you already have one. Go in there and put a big ol # in front of the line about atmel-touchscreen or whatever and save it. When you make your build it'll tell you about a great new driver that it found (surprise!) and ask if you want to enable it. Say yes, obviously. The first part is only important if you already have a .config or if your config wants to use atmel.c by default. Cause you don't. You ARENT using the HTC driver anymore. You want to use mxt224!
Sorry for being confusing, I'm not always the best at explaining things

Hey guys, I see this has about a thousand views. I'm not demanding a response but I'm curious if anyone else was able to get this working. If you did, please post!
Sent from my ADR6300 using xda premium

After porting the driver on Thunderbolt, I do get a log of the init, but there is no getevent data and it is currently unresponsive. I think it is related to my specific functions and the way they are translated, but in theory it does recognize the new driver.
Sent from my ADR6400L using Tapatalk

Interesting...
Would you mind posting a logcat (from cold boot) and a dmesg dump?
Also, are you using the kernel on ICS or some other ROM? I found it helpful to test my kernel changes in CM7 until I got it working, only because I was more sure of what would work.
I'm actually trying to tweak the original HTC driver now to use the newer i2c_master_send method, which is proving somewhat difficult. It actually works using i2c_master_send instead of i2c_message, but its god awfully slow. I'm chalking that up to the ridiculous amount of i2c_writes (only 1 byte each!) the HTC driver wants to do individually to modify touch settings on the fly. I'm trying to see if there's a better way to do this and group them together to make less writes on the bus. The Samsung driver seems to do this pretty well...

swm5126 said:
Interesting...
Would you mind posting a logcat (from cold boot) and a dmesg dump?
Also, are you using the kernel on ICS or some other ROM? I found it helpful to test my kernel changes in CM7 until I got it working, only because I was more sure of what would work.
I'm actually trying to tweak the original HTC driver now to use the newer i2c_master_send method, which is proving somewhat difficult. It actually works using i2c_master_send instead of i2c_message, but its god awfully slow. I'm chalking that up to the ridiculous amount of i2c_writes (only 1 byte each!) the HTC driver wants to do individually to modify touch settings on the fly. I'm trying to see if there's a better way to do this and group them together to make less writes on the bus. The Samsung driver seems to do this pretty well...
Click to expand...
Click to collapse
I really think HTC takes everything 1 byte at a time. Look at how many devices they have released and they are still using almost the same size battery they had in the G1. Anyway, back to the topic at hand.
For anyone else, here are the commands to get those files if you need to post them:
Code:
adb shell logcat -d > logcat.txt
adb shell dmesg > dmesg.txt
And mine are included with this post. I didn't try running it on CM7 because my daily driver is a Sense ROM. Even I don't understand why I run Sense when I use SPB launcher and disable most of the Sense features anyway.

swm5126 said:
Hey guys, I see this has about a thousand views. I'm not demanding a response but I'm curious if anyone else was able to get this working. If you did, please post!
Sent from my ADR6300 using xda premium
Click to expand...
Click to collapse
I am working on porting it to the G2 but am having problems getting it to init. got the kernel to build, and boot but no joy with the ts... let me get the logcat and i will post
http://www.mediafire.com/?jpt3estxqxs4i - logcat and dmesg

Is there any way to just edit the kernel and ROM instead of using the Source Code?

twistedumbrella said:
I really think HTC takes everything 1 byte at a time. Look at how many devices they have released and they are still using almost the same size battery they had in the G1. Anyway, back to the topic at hand.
For anyone else, here are the commands to get those files if you need to post them:
Code:
adb shell logcat -d > logcat.txt
adb shell dmesg > dmesg.txt
And mine are included with this post. I didn't try running it on CM7 because my daily driver is a Sense ROM. Even I don't understand why I run Sense when I use SPB launcher and disable most of the Sense features anyway.
Click to expand...
Click to collapse
Looks like the touchscreen never actually gets to power on for some reason...probably something in your board init file I would think, but I'm not sure. Wish I had more devices to test this out on. If you can, I'd try the latest CM7 for the Tbolt, and grab the kernel from whoever maintains it and build that one and see if it works, since that's how I had success so far.
OdiemanSAM said:
I am working on porting it to the G2 but am having problems getting it to init. got the kernel to build, and boot but no joy with the ts... let me get the logcat and i will post
http://www.mediafire.com/?jpt3estxqxs4i - logcat and dmesg
Click to expand...
Click to collapse
Sounds like you have about the same issue as twisted does. Try CM7 and adding it to the current kernel for your device, unless that's what you've already done.

swm5126 said:
Looks like the touchscreen never actually gets to power on for some reason...probably something in your board init file I would think, but I'm not sure. Wish I had more devices to test this out on. If you can, I'd try the latest CM7 for the Tbolt, and grab the kernel from whoever maintains it and build that one and see if it works, since that's how I had success so far.
Sounds like you have about the same issue as twisted does. Try CM7 and adding it to the current kernel for your device, unless that's what you've already done.
Click to expand...
Click to collapse
I'm on CM7 and not sure what ts i have... the desire z/g2???? anyone... I tried changing it to the synaptics i2c rmi and the init file to synaptics_i2c_rmi_ts_input... is that right???
EDIT: I found it... it is synaptics-rmi-touchscreen

OdiemanSAM said:
I'm on CM7 and not sure what ts i have... the desire z/g2???? anyone... I tried changing it to the synaptics i2c rmi and the init file to synaptics_i2c_rmi_ts_input... is that right???
EDIT: I found it... it is synaptics-rmi-touchscreen
Click to expand...
Click to collapse
Well you have the Atmel maXTouch, just like the Incredible and many other HTC phones. You shouldn't need to change any files other than your board init file and adding the mxt224.c/.h to their respective directories. It's a little more than renaming functions in the board init file, by the way. And it should be mxt224_ts_input. The synaptics stuff doesn't relate to our phones, only the Nexus One, Desire, and maybe earlier models.

djpbx said:
Is there any way to just edit the kernel and ROM instead of using the Source Code?
Click to expand...
Click to collapse
Uhh... well we are editing the kernel. That's what we're doing. You can't edit much of anything at all in a kernel once it's built, that's why I modified the source.

swm5126 said:
Looks like the touchscreen never actually gets to power on for some reason...probably something in your board init file I would think, but I'm not sure. Wish I had more devices to test this out on. If you can, I'd try the latest CM7 for the Tbolt, and grab the kernel from whoever maintains it and build that one and see if it works, since that's how I had success so far.
Sounds like you have about the same issue as twisted does. Try CM7 and adding it to the current kernel for your device, unless that's what you've already done.
Click to expand...
Click to collapse
I grabbed CM7 just after making that post. The kernel built for CM7 is a port from other devices, modified to work. The version I am using is a newer replacement CM7 kernel made from the source for the Tbolt. I am pretty sure the same results happened with the CM "port" kernel that was being tested.
I remember hearing about the issue when they ported gingerbread. Let me see if I can find the info.

swm5126 said:
Well you have the Atmel maXTouch, just like the Incredible and many other HTC phones. You shouldn't need to change any files other than your board init file and adding the mxt224.c/.h to their respective directories. It's a little more than renaming functions in the board init file, by the way. And it should be mxt224_ts_input. The synaptics stuff doesn't relate to our phones, only the Nexus One, Desire, and maybe earlier models.
Click to expand...
Click to collapse
ok so my init file is board-vision.c???? right??? what else do i need to change??? besides the virtualkeys.mxt224_ stuff????

I'd like to help out but you'll have to give me until later tonight or tomorrow. I'd like to see if I can get the HTC driver working in ICS with some changes, thus eliminating the confusion of getting the Samsung driver to work people seem to be having.
If its not possible to fix the HTC driver I'll post a step by step guide on how to apply what I've done with the Samsung driver to a kernel.
Sent from my ADR6300 using xda premium

twistedumbrella said:
I grabbed CM7 just after making that post. The kernel built for CM7 is a port from other devices, modified to work. The version I am using is a newer replacement CM7 kernel made from the source for the Tbolt. I am pretty sure the same results happened with the CM "port" kernel that was being tested.
I remember hearing about the issue when they ported gingerbread. Let me see if I can find the info.
Click to expand...
Click to collapse
Ok. I actually just compiled the Tbolt kernel for someone else, I don't have the download link handy but I'll post it here in a few hours.
Sent from my ADR6300 using xda premium

swm5126 said:
Ok. I actually just compiled the Tbolt kernel for someone else, I don't have the download link handy but I'll post it here in a few hours.
Sent from my ADR6300 using xda premium
Click to expand...
Click to collapse
Lol. **** you. Bust my *** and you just sneeze and make the thing. Haha. Thanks. I am curious what the difference was that I didn't catch. I will have to post my board c file if you want to take a glance at it, but the driver file should be exactly the same because I was comparing Incredible to Tbolt and the atmel config and such were word for work. The big difference was the init method. Everything else matched up.

twistedumbrella said:
Lol. **** you. Bust my *** and you just sneeze and make the thing. Haha. Thanks. I am curious what the difference was that I didn't catch. I will have to post my board c file if you want to take a glance at it, but the driver file should be exactly the same because I was comparing Incredible to Tbolt and the atmel config and such were word for work. The big difference was the init method. Everything else matched up.
Click to expand...
Click to collapse
Yeah didn't mean to make you do work for nothing, I had just done it for someone on a whim using a different source than you were using and I'm not sure if it worked or not yet.
He said it was working under CM7 for sure though, he just PMed me.
http://www.mediafire.com/?avcb4ev5k31indm
Sent from my ADR6300 using xda premium

swm5126 said:
Yeah didn't mean to make you do work for nothing, I had just done it for someone on a whim using a different source than you were using and I'm not sure if it worked or not yet.
He said it was working under CM7 for sure though, he just PMed me.
http://www.mediafire.com/?avcb4ev5k31indm
Sent from my ADR6300 using xda premium
Click to expand...
Click to collapse
I'll have to try it out against my setup. It is good I did it either way because I am sure more changes will be needed down the road. I just couldn't help giving you a hard time
Sent from my ADR6400L using Tapatalk

Didn't seem to work in ICS. No getevent data, and no touch response. Making sure I properly added in the zimage just in case, but it should be right.