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. cander...@oncuegroup.com On Aug 11, 2012, at 5:15 PM, Zach Pfeffer <zach.pfef...@linaro.org> 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 <chrislanderson1...@gmail.com> 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-porting+unsubscr...@googlegroups.com >> 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
