Also "absolute device that needs a pointer" is not a concept the Android platform understands. It assumes that an absolute device is a touch screen, and interprets it appropriately. You will need to modify the window manager's low-level input code in KeyInputQueue.java to interpret your devices correctly. (And most likely need to define now device classes and generate them from EventHub.cpp for KeyInputQueue to process them).
On Sun, Jun 27, 2010 at 8:26 AM, Subramani Venkatesh <[email protected]>wrote: > Hi, > On Android platform, keyinput events are read by EventHub.cpp code > which opens new input device and record's keyevents into a queue. > you might have to check the code in the path given below for more > information, there are so much define.. > framework/base/core/libs/ui/Eventhub.cpp > framework/base/core/libs/ui/KeyCharaterMap.cpp > framework/base/services/java/com/android/server/KeyInputQueue.java > > Regards, > Subbu > > On Sat, Jun 26, 2010 at 5:55 PM, Henk Kok <[email protected]> wrote: > > Dear group, > > > > I am part of a team that is developing a pointing device which we want > > to get to work on Android-x86. Actually, Android seems to be the first > > linux flavour that will allow our full-blown version to function. We > > happen to have a rather elaborate HID descriptor, which under Windows > > will result in 10 HID devices in the device manager. Many linux > > kernels seem to trip over the fact that by default we do absolute > > pointing, but we also have optional relative pointing available. These > > kernels see that we can produce relative pointing reports and > > therefore silently ignore the absolute reports, but the kernel from > > Android-x86 doesn't :). Other than that, we can also produce > > multitouch reports, MCE (system control, vendor control and the other > > one that seems to have slipped my mind for now ;) ) and HID keyboard > > reports. Needless to say, I was very happy to see that on Android-x86 > > our absolute pointing messages end up in userspace through /dev/ > > mice. :) > > > > The real bummer is, that in the main view, the mouse cursor does not > > respond. Apparently, somewhere in the event-pipeline, the absolute > > messages are discarded. I have been digging in the source code for a > > while, but I am unable to figure out which libraries or binaries are > > responsible for e.g. reading the mouse devices. My first guess was to > > look at libsdl, which is prebuilt in the source tree, but I cannot > > find any makefile which uses it, and I could still happily build > > everything after removing libsdl.a from the source tree. I have made > > many guesses after this, but with all of them I seem to run into a > > dead end. > > > > It appears my knowledge of how the GUI of Android works is very > > limited, and what I find on the web is either information about > > android phones, or a big haystack where I am not even sure that the > > needle is hidden in. > > > > Can anyone perhaps enlighten me? How do the events from /dev/mouseX > > or /dev/mice end up in the framework? > > > > FYI, I am using the donut-x86 branch from the sourceforge git archive, > > where I took the latest version from (a couple of times, yesterday was > > the most recent) > > > > Regards, > > > > - Henk Kok. > > > > -- > > unsubscribe: > > [email protected]<android-porting%[email protected]> > > website: http://groups.google.com/group/android-porting > > > > -- > unsubscribe: > [email protected]<android-porting%[email protected]> > website: http://groups.google.com/group/android-porting > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- unsubscribe: [email protected] website: http://groups.google.com/group/android-porting
