Have you successfully made your touchscreen response yet? For the touchscreen device name of my device (wm97xx AC97 with PXA310) is set on the selected line in http://sourceforge.net/p/ipaq214android/kernel/ci/fe841ee62cb6cff394a38565f390a5223a879b27/tree/drivers/input/touchscreen/wm97xx-core.c#l648 If you see the commit history you'll find I changed a space to a hyphen because space doesn't work properly.
My patches to InputReader can be found here http://sourceforge.net/p/ipaq214android/android/ci/HEAD/tree/ and my .idc file is here http://sourceforge.net/p/ipaq214android/android/ci/HEAD/tree/ipaq214/wm97xx-touchscreen.idc?force=True You see the filename is the same as the device name stated in the kernel. Note that the 5pt calibration data is obtained by tslib calibration program first, then for the first 6 values in pointercal file is divided by the 7th value (65536) and placed there in order. (My value there is specialised for that ts placed upside down and some extra calibration.) You can test the touchscreen by using the "Pointer Location" tool in "Dev Tools". I had thought of improving the calibration mechanism and provide a proper calibration program. I don't have a good idea though. (Calibration data should be placed in the userdata partition and fed into InputReader by some mechanism, but probably not directly reading the file.) Hope I can help. :) P.S. I am really sorry for those repeated messages previously sent. candrsn1973於 2012年8月12日星期日UTC+8上午10時17分20秒寫道： > > That's definitely a possibility. I am also looking at our power > management, trying to disable suspend via /sys/power/wake_lock..... AIB > looks great though. > > Chris L. Anderson > Senior Software Engineer > OnCue Technologies LLC > Mobile Tel. 704-207-7849 > Email. cand...@oncuegroup.com <javascript:> > > On Aug 11, 2012, at 5:15 PM, Zach Pfeffer <zach.p...@linaro.org<javascript:>> > wrote: > > > You may actually like the "Android Input Bridge" that Romain Perier > > put together. It lets you control Android from a host mouse. May help > > you debug. > > > > On 10 August 2012 16:53, candrsn1973 <chrisland...@gmail.com<javascript:>> > wrote: > >> Hi all, > >> > >> As of Monday, 8/6, we had booted a generic build of Android 2.3.7 to > the > >> desktop on a Marvell PX168 platform, following the procedure of a > generic > >> boot tested with Froyo > >> > >> Out of the box, of course, the touchscreen would not respond. On a > >> subsequent boot up, the screen locked. We then unlocked it using > >> adb and the input keyevent 82 command, plus key events to access > various > >> settings, etc. > >> > >> However, the touchscreen will not respond after an unlock. After > further > >> investigation, I discovered that we needed to provide an .idc > configuration > >> file > >> in system/usr or other directories and we did this. Now, it appears (I > >> emphasize appears) that InputManager.java's "try" function does respond > to > >> touches, since > >> an initial tap on the screen will reveal that no > >> /sys/board_properties/virtualkeys.<devicename> is no being provided by > the > >> kernel. We saw this as an optional/informational message simply > checking > >> for any virtual keys, which we do not (currently) implement. > >> > >> Further checking via logcat revealed that EventHub does recognize > >> /dev/input/event0. Using cat /dev/input/event0 from dab reveals that > >> /dev/input/event0 is being read, as characters show up on the adb > terminal. > >> It's important to note, as well, that the idc file has the exact same > device > >> name as exported by the wm97xx touchscreen driver (Wolfson) we are > using. > >> > >> Questions: > >> > >> 1. Will implementing TSLIB somehow connect the dev/input/event0 events > to > >> the InputManager.java functions? (With Froyo, we had exported > >> /dev/input/event0 from TSLIB in root/init.rc.) and TSLIB had been > >> implemented within the AvengerLite source tree by Marvell. > >> 2. Or, Do we need to implement a special handler within > InputManager.java? > >> > >> I am not too worried about calibration at the moment. I simply need to > >> understand the (possibly) many reasons why the Android system/UI will > not > >> recognize /dev/input/event0 even when InputManager.java seems to > respond. I > >> am hoping that someone can provide a basic handler for touch events, > one > >> that I could maybe > >> use to at least place debug messaging code. A skeleton outline of what > I > >> need to provide within InputManger.java would help, as well. > >> > >> Regards, > >> > >> Chris > >> > >> -- > >> unsubscribe: android-porti...@googlegroups.com <javascript:> > >> website: http://groups.google.com/group/android-porting > > > > > > > > -- > > Zach Pfeffer > > Android Platform Team Lead, Linaro Platform Teams > > Linaro.org | Open source software for ARM SoCs > > Follow Linaro: http://www.facebook.com/pages/Linaro > > http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog > -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting
