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
On Aug 11, 2012, at 5:15 PM, Zach Pfeffer <
zach.p...@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 <
chrisland...@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-porti...@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