Guest xangma Posted February 27, 2010 Report Posted February 27, 2010 Aha, so it's in the 1167 driver and not the 1319? Or whatever? I'm confused as to why we're not using 1319 anymore =/
Guest BigBearMDC Posted February 27, 2010 Report Posted February 27, 2010 (edited) Aha, so it's in the 1167 driver and not the 1319? Or whatever? I'm confused as to why we're not using 1319 anymore =/ We're using the 1167 because it is a multitouch driver :( Seems like Huawei already wrote a driver for Android 2.X+ and added it to the 1.5 kernel source. You can have a look at it, but by default the code for the second touch input is out-commented. I'm now comparing these two drivers, as I think they initialize the HW in a different way, and thats why android crashes when it tries to initialize the input device - but thats just a theory. And the 1167 driver works, what means that the problem is not the driver, what also means that we have multitouch :( Edit: The problem is that Huawei totally rewrote the synaptics driver, and added some things like gestures and whether a touch is a click or a slip... It would be difficult to combine both of these drivers so that the gestures AND multitouch works =/ Also, its possible that the edited their KeyInputQueue too for their gestures.... that would be a really heavy slap in the face... Greetings, BigBear Edited February 27, 2010 by BigBearMDC
Guest BigBearMDC Posted February 27, 2010 Report Posted February 27, 2010 (edited) I'm no onto creating a hybrid driver between 1319 and 1167. At the first look i recognized, that the two drivers communicate with the synaptics controller in different ways. While the 1167 driver uses printk([...]), the 1319 driver uses SYNAPITICS_DEBUG([...]). But both functions are called with the same parameters. Could be one reason that android crashes... Edit -> example: printk("synaptics_ts_probe: \n"); vs. SYNAPITICS_DEBUG(" In synaptics_ts_probe: \n");[/code] Greetings, BigBear Edited February 27, 2010 by BigBearMDC
Guest HunteronX Posted February 27, 2010 Report Posted February 27, 2010 Nope, but I'll upload the boot.img too, if you want :( But beware, if you flash that boot.img, you will end up in a boot-loop! Edit: Added boot.img to previous post. Greetings, BigBear Ok then. Thanks for telling me this! :(
Guest BigBearMDC Posted February 27, 2010 Report Posted February 27, 2010 Alright the hybrid driver is ready. All in all it has 278 lines of code more than the unmodified 1167 driver has. I'll recompile the kernel now. Greetings, BigBear
Guest BigBearMDC Posted February 27, 2010 Report Posted February 27, 2010 Kernel finished! I also added the modified driver if someone wants to have a look at it :( Greetings, BigBearboot.imgpatched_driver.zip
Guest BigBearMDC Posted February 27, 2010 Report Posted February 27, 2010 Damn it! That isn't working either :(
Guest onlyyouzl Posted February 27, 2010 Report Posted February 27, 2010 I am a Chinese customer, English is not good, 8220 in the country also has some people use, and we have a more detailed evaluation and a better synchronization software -91 assistants, but we lack the hardware and systems research, thank you Work! The above is translated by Google, forgive me, attached to our evaluation and synchronization software http://www.hiapk.com/bbs/thread-106968-1-1.html http://android.sj.91.com/content/2009-11-2...3530697,1.shtml
Guest BigBearMDC Posted February 27, 2010 Report Posted February 27, 2010 I am a Chinese customer, English is not good, 8220 in the country also has some people use, and we have a more detailed evaluation and a better synchronization software -91 assistants, but we lack the hardware and systems research, thank you Work! The above is translated by Google, forgive me, attached to our evaluation and synchronization software http://www.hiapk.com/bbs/thread-106968-1-1.html http://android.sj.91.com/content/2009-11-2...3530697,1.shtml :( no problem. Unfortunately my chinese is not that good :( But thanks! :( BTW new kernel compiled - I'll test it now. Greetings, BigBear
Guest onlyyouzl Posted February 27, 2010 Report Posted February 27, 2010 Thank you, according to national news that 8220 is running 2.1 there is slow, so there is no quick release Huawei rom, could go through in order to better streamline and optimize the use of
Guest BigBearMDC Posted February 27, 2010 Report Posted February 27, 2010 (edited) I tried everything I could imagine, but it still doesn't work :( I guess the problem occurs when the driver tries to get the coordinates of the second touch input. It can't obtain them, and then crashes :( ATM I don't have any clue how to bypass this. The last thing I could try is to calculate the coordinates of the second touch like this: x2 = x + 50; y2 = y + 50; What would also be possible is that the parent handle does not expect further touch inputs and crashes as it receives them (maybe input.c?). What we could try then is to only return the coordinates of the second touch, what would mean that multitouch works. Any help/advices would be greatly appreciated! Greetings, BigBear Edited February 27, 2010 by BigBearMDC
Guest onlyyouzl Posted February 27, 2010 Report Posted February 27, 2010 I am sorry, I can not help to you, at home most of the andriod users to use HTC's machines, 8220, and is not sold in the country to do publicity, few people know, but I will try to find some resources need to hope that Huawei Technologies will soon release an official The 2.1rom can give you inspiration
Guest BigBearMDC Posted February 27, 2010 Report Posted February 27, 2010 I am sorry, I can not help to you, at home most of the andriod users to use HTC's machines, 8220, and is not sold in the country to do publicity, few people know, but I will try to find some resources need to hope that Huawei Technologies will soon release an official The 2.1rom can give you inspiration Thanks anyway :( Yap when Huawei releases 2.1 mutltitouch should be integrated anyway. BTW I know edited the driver once more. Now it reads the coordinates of the second touch by default, and discards the coordinates of the first touch. Greetings, BigBear
Guest BigBearMDC Posted February 27, 2010 Report Posted February 27, 2010 Okay, that doesn't work either. Damn where is the buf[] array getting filled??? I think theres the problem. Greetings, BigBear
Guest BigBearMDC Posted March 2, 2010 Report Posted March 2, 2010 Hey guys! I got some awesome news! I'm in contact with Luke Hutchinson, the developer of the MT Hack for the G1! He sent me some code with which I'll patch the Huawei 1167 driver! Stay Tuned! Greetings, BigBear
Guest starkos Posted March 2, 2010 Report Posted March 2, 2010 Hey guys! I got some awesome news! I'm in contact with Luke Hutchinson, the developer of the MT Hack for the G1! He sent me some code with which I'll patch the Huawei 1167 driver! Stay Tuned! Greetings, BigBear Sounds promising, good luck mate :(
Guest Spooke Posted March 2, 2010 Report Posted March 2, 2010 Hey guys! I got some awesome news! I'm in contact with Luke Hutchinson, the developer of the MT Hack for the G1! He sent me some code with which I'll patch the Huawei 1167 driver! Stay Tuned! Greetings, BigBear I hope you all get it working :(, good luck and keep going, your doing great :(
Guest xangma Posted March 3, 2010 Report Posted March 3, 2010 Why are we using the 1167 driver now instead of the 1319 one?
Guest xangma Posted March 3, 2010 Report Posted March 3, 2010 Why are we using the 1167 driver now instead of the 1319 one?
Guest BigBearMDC Posted March 3, 2010 Report Posted March 3, 2010 Why are we using the 1167 driver now instead of the 1319 one? Because we need the MT driver if we want MT :( Greetings, BigBear
Guest xangma Posted March 3, 2010 Report Posted March 3, 2010 Because we need the MT driver if we want MT :( Greetings, BigBear But we were never using the 1167 in the first place? So i'm confused =/
Guest BigBearMDC Posted March 3, 2010 Report Posted March 3, 2010 But we were never using the 1167 in the first place? So i'm confused =/ Yap we used the 1319 driver. I tried it with the 1167 too, but that didn't work, and I thought the problem was that the driver communicates with the HW in a different way. Well, it does, but it seems like not that is causing the problems, but the input report with the information of the second touchpoint. So Luke Hutchinson sent me a piece of code which I'll patch into the 1167 driver. The major difference is, that he doesn't report 2 input events, but only one. Instead of 2 ivents, he returns the mean of these two points, and the distance between them. If you know that, you can catch this in your application and recreate the 2 coordinates out of it. (It could be that I made some mistakes in this eplanation, I only had a quick look at the code :( ) I'll patch the driver today and try it :( Greetings, BigBear
Guest xangma Posted March 3, 2010 Report Posted March 3, 2010 Yap we used the 1319 driver. I tried it with the 1167 too, but that didn't work, and I thought the problem was that the driver communicates with the HW in a different way. Well, it does, but it seems like not that is causing the problems, but the input report with the information of the second touchpoint. So Luke Hutchinson sent me a piece of code which I'll patch into the 1167 driver. The major difference is, that he doesn't report 2 input events, but only one. Instead of 2 ivents, he returns the mean of these two points, and the distance between them. If you know that, you can catch this in your application and recreate the 2 coordinates out of it. (It could be that I made some mistakes in this eplanation, I only had a quick look at the code :( ) I'll patch the driver today and try it :( Greetings, BigBear Nah I get all that =] I was just wondering why we're now going to use the 1167 driver =P
Guest BigBearMDC Posted March 3, 2010 Report Posted March 3, 2010 (edited) Hi guys Just to keep you updated: I'm now using the 1319 driver (yeah i know ..... AGAIN :( ). But things don't look good :( I patched the driver, and the synaptics_ts_work_func now looks like this: static void synaptics_ts_work_func(struct work_struct *work) { int i; int ret; int bad_data = 0; struct i2c_msg msg[2]; uint8_t start_reg; uint8_t buf[15]; uint16_t x, y; uint8_t z,w; uint8_t finger; uint8_t gesture; uint8_t magnitude; static uint16_t last_x = 0; static uint16_t last_y = 0; static bool is_first_point = true; int x2; int y2; int finger2_pressed; struct synaptics_ts_data *ts = container_of(work, struct synaptics_ts_data, work); msg[0].addr = ts->client->addr; msg[0].flags = 0; msg[0].len = 1; msg[0].buf = &start_reg; start_reg = 0x00; msg[1].addr = ts->client->addr; msg[1].flags = I2C_M_RD; msg[1].len = sizeof(buf); msg[1].buf = buf; SYNAPITICS_DEBUG("synaptics_ts_work_func\n"); for (i = 0; i < ((ts->use_irq && !bad_data) ? 1 : 3); i++) { ret = i2c_transfer(ts->client->adapter, msg, 2); if (ret < 0) { SYNAPITICS_DEBUG(KERN_ERR "synaptics_ts_work_func: i2c_transfer failed\n"); bad_data = 1; } else { bad_data = 0; x = buf[5] | (uint16_t)(buf[4] & 0x1f) << 8; /* x aixs */ y= buf[3] | (uint16_t)(buf[2] & 0x1f) << 8; /* y aixs */ z = buf[1]; /* pressure */ w = buf[0] >> 4; /* width */ finger = buf[0] & 7; /* numbers of fingers */ gesture = buf[6]; /* code of gesture */ magnitude = buf[7]; /* enhanced data of gesture */ x2 = buf[3+6] | (uint16_t)(buf[2+6] & 0x1f) << 8; /* x axis touch 2 */ y2 = buf[5+6] | (uint16_t)(buf[4+6] & 0x1f) << 8; /* y axis touch 2 */ finger2_pressed = finger > 1 && finger != 7; SYNAPITICS_DEBUG("x = %d y = %d z = %d w = %d finger = %d gesture = %x magnitude = %d\n", x, y, z, w, finger,gesture,magnitude); if (z) { if (!finger2_pressed) { /* No multitouch -- force width to zero */; w = 0; } if (finger2_pressed) { /* Multitouch -- use midpoint between points as x,y */ int32_t dx, dy; /* (x,y) coords for multitouch are at midpt between fingers */ dx = x - x2; dy = y - y2; x = (x + x2) / 2; y = (y + y2) / 2; /* We only need absolute distances */ if (dx < 0) dx = -dx; if (dy < 0) dy = -dy; /* We have 24 points of mantissa in a float (which * ABS_TOOL_WIDTH gets converted into in a MotionEvent.size * field). Use 12 for each of dx and dy. We assume the * device never gives values larger than its reported * max_x and max_y values. */ dx = ((1 << 12) - 1) * dx / TS_X_MAX; //max_x dy = ((1 << 12) - 1) * dy / TS_Y_MAX; //max_y w = (dx << 12) + dy; //input_report_abs(ts->input_dev, ABS_HAT0X, pos[1][0]); //input_report_abs(ts->input_dev, ABS_HAT0Y, pos[1][1]); } /* * always report the first point whether slip or click */ if (is_first_point) { input_report_abs(ts->input_dev, ABS_X, x); input_report_abs(ts->input_dev, ABS_Y, 5880-y); last_x = x; last_y = y; is_first_point = false; } else { /* * except the first point, also report the following points * 1) x aixes is 3 larger or smaller than the last reported point * 2) y aixes is 3 larger or smaller than the last reported point. * */ if ((( x - last_x) >= TS_X_OFFSET) || ((last_x - x) >= TS_X_OFFSET) || ((y - last_y) >= TS_Y_OFFSET) || ((last_y - y) >= TS_Y_OFFSET)) { input_report_abs(ts->input_dev, ABS_X, x); input_report_abs(ts->input_dev, ABS_Y, 5880-y); last_x = x; last_y = y; } } } else /* * The next point must be first point whether slip or click after * this up event */ is_first_point = true; input_report_abs(ts->input_dev, ABS_PRESSURE, z); input_report_abs(ts->input_dev, ABS_TOOL_WIDTH, w); input_report_key(ts->input_dev, BTN_TOUCH, finger); input_sync(ts->input_dev); } } if (ts->use_irq) { enable_irq(ts->client->irq); SYNAPITICS_DEBUG("enable irq\n"); } }[/code] If you don't want to compare it with the unmodified driver on your own, I'll tell you what I did: I extended the buf array from 8 to 15 bytes. Then I call the function i2c_transfer. The buf array then points to a memory block where the data we need is stored. Next, I initialize x2, y2 and finger2_pressed. You can see how I did this in the source above. So when 2 fingers are on the screen, we return the midpoint and store the distance between this two points in the ABS_TOOL_WIDTH variable (or int w). If there's only one finger on the screen, we force the ABS_TOOL_WIDTH to zero and return the normal coordinates of the point. Sounds promising, doesn't it? To make it short: Thats the least modified version I can imagine. and it still doesn't work :( The error has to occur between i2c_transfer and finger2_pressed = [...]. But ret > 0, so I don't get an error massage, what means that the i2c_transfer - or at least one of the two transfers - succeeds. That's getting difficult now. We nearly reached the HW level. I hope there's a genius out there who takes a look at the code and laughs about it, because the mistake I made is so obvious :( Greetings, BigBear Edited March 3, 2010 by BigBearMDC
Guest tux880 Posted March 3, 2010 Report Posted March 3, 2010 i dont think i have ever posted yet just reading the forums getting my info just wonted to say keep up the work mate, it takes people like you to make the phone a success, and if there is anything us none programers can do just post. and thanks again for the work you have put in, loads of your free time now i bet.
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now