hi,how to use mouse in Android
jian qin
hedwin
Hedwin
On Wed, Dec 16, 2009 at 4:02 AM, jian qin <qinjia...@gmail.com> wrote:
> I want know how to use mouse in Android,please help me.
>
> unsubscribe: android-porti...@googlegroups.com
> website: http://groups.google.com/group/android-porting
Yi Sun
changes from android-x86.org for the mouse support. Check the git logs
in frameworks/base and frameworks/policy/base. You will be abel to find
the changes
And, yes, you need to enabled your mouse driver in the kernel first.
Yi
Android-x86
www.android-x86.org
hedwin
worked without any change to android.
But then again was using the mips android so not sure yet if specific
changes were made there that makes it work.
Hedwin
Yi Sun
--
Android-x86
http://www.android-x86.org
hedwin
place in android?
Hamilton Vera
have touchscreen yet.
Here I am using hardware and keyboard with an imx51, freescale did not
send the LCD and TS yet, so I am using the DVI video output.
In fact it may also be helpfull to automotive ends, to use a keyboard
with touchpad
[]'s
Hamilton Vera
--
Hamilton Vera
int Administrator (char Network[],char ComputationalSystems[])
http://hvera.wordpress.com
Yi Sun
BTW-- In my implementation, there are no such an event called mouse to
dispatch since none of the application will know such a event. So I
picky back on the touch events.
jian qin
hedwin
Reason it did work is because android thinks the screen is off.
Hedwin
hedwin
Will provide the details when I am back home.
Hedwin
Yi Sun
your source code for your android-x86?
Yi
hedwin
Reason it doesn't work is that android thinks the screen is off.
Issue 62 contains the solution to get it working.
Hedwin
Yi Sun
your kernel config (you posted a file instead of a diff).
I'm using a usb mouse with my PC and my mouse works inside qemu without
any issues.
Yi
> +unsub...@googlegroups.com
> > >>> >>>> > website:
> http://groups.google.com/group/android-porting
> > >>> >>>>
> > >>> >>>> --
> > >>> >>>> unsubscribe: android-porting
> +unsub...@googlegroups.com
> > >>> >>>> website:
> http://groups.google.com/group/android-porting
> > >>> >>>
> > >>> >>>
> > >>> >>> --
> > >>> >>> Android-x86
> > >>> >>> www.android-x86.org
> > >>> >>>
> > >>> >>> --
> +unsub...@googlegroups.com
> > >>> >>> website:
> http://groups.google.com/group/android-porting
> > >>> >>
> > >>> >> --
> > >>> >> unsubscribe: android-porting
> +unsub...@googlegroups.com
> > >>> >> website:
> http://groups.google.com/group/android-porting
> > >>> >
> > >>> >
> > >>> >
> > >>> > --
> > >>> > Android-x86
> > >>> > http://www.android-x86.org
> > >>> >
> > >>> > --
> +unsub...@googlegroups.com
> > >>> > website:
> http://groups.google.com/group/android-porting
> > >>>
> > >>> --
> > >>> unsubscribe: android-porting
> +unsub...@googlegroups.com
> > >>> website: http://groups.google.com/group/android-porting
> > >>
> > >> --
> > >> unsubscribe: android-porti...@googlegroups.com
> > >> website: http://groups.google.com/group/android-porting
> > >
> >
>
> > --
>
> > unsubscribe: android-porti...@googlegroups.com
> > website: http://groups.google.com/group/android-porting
>
>
> --
> Android-x86
> www.android-x86.org
>
> --
> unsubscribe: android-porti...@googlegroups.com
> website: http://groups.google.com/group/android-porting
>
>
>
Yi Sun
what really went wrong. Would it possible for you to find out why the
Android thinks that the screen is not on in your case. We may have a bug
somewhere else.
boolean screenIsOn() {
synchronized (mLocks) {
+ mPowerState |= SCREEN_ON_BIT;
return (mPowerState & SCREEN_ON_BIT) != 0;
}
}
On Sat, 2009-12-26 at 19:13 +0100, hedwin wrote:
> > >>> >>>> > unsubscribe: android-porting
> +unsub...@googlegroups.com
> > >>> >>>> > website:
> http://groups.google.com/group/android-porting
> > >>> >>>>
> > >>> >>>> --
> > >>> >>>> unsubscribe: android-porting
> +unsub...@googlegroups.com
> > >>> >>>> website:
> http://groups.google.com/group/android-porting
> > >>> >>>
> > >>> >>>
> > >>> >>> --
> > >>> >>> Android-x86
> > >>> >>> www.android-x86.org
> > >>> >>>
> > >>> >>> --
> > >>> >>> unsubscribe: android-porting
> +unsub...@googlegroups.com
> > >>> >>> website:
> http://groups.google.com/group/android-porting
> > >>> >>
> > >>> >> --
> > >>> >> unsubscribe: android-porting
> +unsub...@googlegroups.com
> > >>> >> website:
> http://groups.google.com/group/android-porting
> > >>> >
> > >>> >
> > >>> >
> > >>> > --
> > >>> > Android-x86
> > >>> > http://www.android-x86.org
> > >>> >
> > >>> > --
> > >>> > unsubscribe: android-porting
> +unsub...@googlegroups.com
> > >>> > website:
> http://groups.google.com/group/android-porting
> > >>>
> > >>> --
> > >>> unsubscribe: android-porting
> +unsub...@googlegroups.com
> > >>> website: http://groups.google.com/group/android-porting
> > >>
> > >> --
> > >> unsubscribe: android-porti...@googlegroups.com
> > >> website: http://groups.google.com/group/android-porting
> > >
> >
>
> > --
>
> > unsubscribe: android-porti...@googlegroups.com
> > website: http://groups.google.com/group/android-porting
>
>
> --
> Android-x86
> www.android-x86.org
>
> --
> unsubscribe: android-porti...@googlegroups.com
> website: http://groups.google.com/group/android-porting
>
>
>
hedwin
Hedwin
Yi Sun
FYI-- in my env, I did not really add "-serial stdio -usb -usbdevice
mouse" for my usb mouse to work with qemu. I'm not sure why you need it.
I may have to check on the qemu manual.
Yi
hedwin
I use a slight older qemu, the one supplied with fedora. Newer qemu versions use usb per
default. That might be the reason why you did no have to provide the usb arguments.
Hedwin
Yi Sun
Yi
hedwin
Dug a little deeper now.
Handling mouse movement indirectly depends on the power state of android. Eh what ????
Mouse events are handled by the InputDeviceReader. This thread calls method 'preprocessEvent' in the WindowManagerService. The method itself then calls mPowerManager.screenIsOn. This method returns false for reason I explain later. This eventually results in preprocessEvent to return 0 and as a result the mouse movement events are not handled. Therefor not moving mouse pointer.
Ok
Now to the why screenIsOn return false. When android starts it will eventually execute initInThread in PowerManagementService. At the end setPowerState(ALL_BRIGHT) is called. So far
so good. The method setPowerState will call Power.setScreenState(true). Still going ok. Power.setScreenState is a function implemented in /base/core/jni/android_os_power.cpp.
The function Power.setScreenState will eventually call function set_screen_state implemented in /hardware/libhardware_legacy/power/power.c. The function set_screen_state will at the begining
call initialize_fds. And here is where it goes wrong because initialize_fds cannot open the files mentioned in the array OLD_PATHS and NEW_PATHS. The reason why it cannot
open the files is because the filesystem properties are set to 660 in init.rc. For this reason the power change never takes places and indirectly prevents the move movement events from
being handled.
When I change the sys file properties of the files in OLD_PATHS and NEW_PATHS to 666 mouse movement events are processed. What??? yes
(OLD_PATHS and NEW_PATHS are defined in /hardware/libhardware_legacy/power/power.c)
So I wonder how can this work anyway on any machine or is it just QEMU ..............
Hedwin
Yi Sun
> When I change the sys file properties of the files in OLD_PATHS and
> NEW_PATHS to 666 mouse movement events are processed. What??? yes
> (OLD_PATHS and NEW_PATHS are defined
> in /hardware/libhardware_legacy/power/power.c)
>
for the system group. It should be able to be accessed by power.c
BTW-- on all the x86 systems I ever used, I did not see OLD_PATHS in
sysfs. Do you see it in your env?
> So I wonder how can this work anyway on any machine or is it just
> QEMU ..............
No, it seems that only you have the problem.
Really, I only seen the same problem when we did not enable the wakelock
driver in the kernel. And that was 10 months ago.
Yi
hedwin
Would also assume it to work as well. Will try VirtualBox see if it does the same or different.
Hedwin
hedwin
So I know that a working mouse depends on being able to open the files in '/sys/power'.
After further looking a QEMU I noticed that the ownership of the /sys/power files are changed to what is indicated in init.rc but if I monitor these over
time that after a while all of the ownership of the '/sys/power' files change to root:root ownership thus preventing android from being allowed to read
these files and as a result the mouse doesn't work anymore.
Also tried VirtualBox and this one doesn't seem to have this problem mouse works fine.
Hedwin
Yi Sun
>
> So I know that a working mouse depends on being able to open the files in
> '/sys/power'.
>
access to /sys/power. The reason for the mouse events get dropped is
the PM said screen is off and WM drops the mouse event based on the
predefined policy. It has nothing to do with mouse. If your screen is
off, there are not reason to process the mouse event.
> After further looking a QEMU I noticed that the ownership of the /sys/power
> files are changed to what is indicated in init.rc but if I monitor these
> over
> time that after a while all of the ownership of the '/sys/power' files
> change to root:root ownership thus preventing android from being allowed to
> read
> these files and as a result the mouse doesn't work anymore.
>
faked some ACPI or PM events that triggered the problem.
> Also tried VirtualBox and this one doesn't seem to have this problem mouse
> works fine.
As expected.
--
Android-x86
http://www.android-x86.org
Yi Sun
hedwin
Hedwin
hedwin
On Tue, Jan 5, 2010 at 1:29 PM, hedwin <hedwin...@gmail.com> wrote:No, the mouse is always working. A correct PM state is based on the
>
> So I know that a working mouse depends on being able to open the files in
> '/sys/power'.
>
access to /sys/power. The reason for the mouse events get dropped is
the PM said screen is off and WM drops the mouse event based on the
predefined policy. It has nothing to do with mouse. If your screen is
off, there are not reason to process the mouse event.
Was just a statement to indicate the relationship. Btw the PM doesn't say the screen is off it tries to set
to screen to on but it fails due to not being able to access the /sys/power files.
> After further looking a QEMU I noticed that the ownership of the /sys/powerSounds like a driver refreshed these file entries. Maybe your QEMU
> files are changed to what is indicated in init.rc but if I monitor these
> over
> time that after a while all of the ownership of the '/sys/power' files
> change to root:root ownership thus preventing android from being allowed to
> read
> these files and as a result the mouse doesn't work anymore.
>
faked some ACPI or PM events that triggered the problem.
For QEMU I followed the recipy on the android-x86 website.
DANtheMAN
I have Android working on a mini2440 FriendlyARM board [1]. I am
attempting to get a USB pen mouse to work under the OS. Out of the
box the mouse 'sort of' works. I am able to move the highlighting
around the screen and left click launches applications. However, the
movement of the highlighter is overly sensitive and not quite what I
am looking for. I would appreciate any guidance.
Thanks,
Dan Moore
On Jan 5, 4:44 pm, Yi Sun <beyo...@gmail.com> wrote:
> BTW--, please help to remove the ticket.
> Thanks
> Yi
>
>
>
> On Tue, Jan 5, 2010 at 1:44 PM, Yi Sun <beyo...@gmail.com> wrote:
> > On Tue, Jan 5, 2010 at 1:29 PM, hedwin <hedwin.kon...@gmail.com> wrote:
>
> >> So I know that a workingmousedepends on being able to open the files in
> >> '/sys/power'.
>
> > No, themouseis always working. A correct PM state is based on the
> > access to /sys/power. The reason for themouseevents get dropped is
> > the PM said screen is off and WM drops themouseevent based on the
> > predefined policy. It has nothing to do withmouse. If your screen is
> > off, there are not reason to process themouseevent.
> >> After further looking a QEMU I noticed that the ownership of the /sys/power
> >> files are changed to what is indicated in init.rc but if I monitor these
> >> over
> >> time that after a while all of the ownership of the '/sys/power' files
> >> change to root:root ownership thus preventing android from being allowed to
> >> read
> >> these files and as a result themousedoesn't work anymore.
>
> > Sounds like a driver refreshed these file entries. Maybe your QEMU
> > faked some ACPI or PM events that triggered the problem.
>
> >> Also tried VirtualBox and this one doesn't seem to have this problemmouse
> >> works fine.
> > As expected.
>
> >> Hedwin
>
> >> On Wed, Dec 30, 2009 at 9:47 PM, hedwin <hedwin.kon...@gmail.com> wrote:
>
> >>> No, don't see OLD_PATHS either. Also searched the kernel nothing there as
> >>> well. Guess power.c never got cleaned up
>
> >>> Would also assume it to work as well. Will try VirtualBox see if it does
> >>> the same or different.
>
> >>> Hedwin
>
> >>> On Wed, Dec 30, 2009 at 9:24 PM, Yi Sun <beyo...@gmail.com> wrote:
>
> >>>> > When I change the sys file properties of the files in OLD_PATHS and
> >>>> > NEW_PATHS to 666mousemovement events are processed. What??? yes
> >>>> > (OLD_PATHS and NEW_PATHS are defined
> >>>> > in /hardware/libhardware_legacy/power/power.c)
>
> >>>> The power.c runs as system I think, and the files in /sys/power has rw
> >>>> for the system group. It should be able to be accessed by power.c
>
> >>>> BTW-- on all the x86 systems I ever used, I did not see OLD_PATHS in
> >>>> sysfs. Do you see it in your env?
> >>>> > So I wonder how can this work anyway on any machine or is it just
> >>>> > QEMU ..............
> >>>> No, it seems that only you have the problem.
> >>>> Really, I only seen the same problem when we did not enable the wakelock
> >>>> driver in the kernel. And that was 10 months ago.
>
> >>>> Yi
> >>>> On Wed, 2009-12-30 at 20:49 +0100, hedwin wrote:
> >>>> > Hi,
>
> >>>> > Dug a little deeper now.
>
> >>>> > Handlingmousemovement indirectly depends on the power state of
> >>>> > android. Eh what ????
>
> >>>> >Mouseevents are handled by the InputDeviceReader. This thread calls
> >>>> > method 'preprocessEvent' in the WindowManagerService. The method
> >>>> > itself then calls mPowerManager.screenIsOn. This method returns false
> >>>> > for reason I explain later. This eventually results in preprocessEvent
> >>>> > to return 0 and as a result themousemovement events are not handled.
> >>>> > Therefor not movingmousepointer.
>
> >>>> > Ok
>
> >>>> > Now to the why screenIsOn return false. When android starts it will
> >>>> > eventually execute initInThread in PowerManagementService. At the end
> >>>> > setPowerState(ALL_BRIGHT) is called. So far
> >>>> > so good. The method setPowerState will call
> >>>> > Power.setScreenState(true). Still going ok. Power.setScreenState is a
> >>>> > function implemented in /base/core/jni/android_os_power.cpp.
> >>>> > The function Power.setScreenState will eventually call function
> >>>> > set_screen_state implemented
> >>>> > in /hardware/libhardware_legacy/power/power.c. The function
> >>>> > set_screen_state will at the begining
> >>>> > call initialize_fds. And here is where it goes wrong because
> >>>> > initialize_fds cannot open the files mentioned in the array OLD_PATHS
> >>>> > and NEW_PATHS. The reason why it cannot
> >>>> > open the files is because the filesystem properties are set to 660 in
> >>>> > init.rc. For this reason the power change never takes places and
> >>>> > indirectly prevents the move movement events from
> >>>> > being handled.
>
> >>>> > When I change the sys file properties of the files in OLD_PATHS and
> >>>> > NEW_PATHS to 666mousemovement events are processed. What??? yes
> >>>> > (OLD_PATHS and NEW_PATHS are defined
> >>>> > in /hardware/libhardware_legacy/power/power.c)
>
> >>>> > So I wonder how can this work anyway on any machine or is it just
> >>>> > QEMU ..............
>
> >>>> > Hedwin
>
> >>>> > On Sat, Dec 26, 2009 at 8:55 PM, Yi Sun <beyo...@gmail.com> wrote:
> >>>> > If you use the latest qemu, would you still need these
> >>>> > changes?
> >>>> > Yi
>
> >>>> > On Sat, 2009-12-26 at 20:14 +0100, hedwin wrote:
> >>>> > > The serial is just added to see the kernel boot an have
> >>>> > access to the
> >>>> > > console later on.
> >>>> > > I use a slight older qemu, the one supplied with fedora.
> >>>> > Newer qemu
> >>>> > > versions use usb per
> >>>> > > default. That might be the reason why you did no have to
> >>>> > provide the
> >>>> > > usb arguments.
> >>>> > >
> >>>> > > Hedwin
> >>>> > >
> >>>> > > On Sat, Dec 26, 2009 at 7:39 PM, Yi Sun <beyo...@gmail.com>
> >>>> > wrote:
> >>>> > > Thanks for the help.
> >>>> > > FYI-- in my env, I did not really add "-serial stdio
> >>>> > -usb
> >>>> > > -usbdevice
> >>>> > > mouse" for my usbmouseto work with qemu. I'm not
> >>>> > sure why
> >>>> > > you need it.
> >>>> > > I may have to check on the qemu manual.
> >>>> > > Yi
> >>>> > >
> >>>> > > On Sat, 2009-12-26 at 19:32 +0100, hedwin wrote:
> >>>> > > > agree, so consider it a workaround. I will take a
> >>>> > further
> >>>> > > look into
> >>>> > > > this
> >>>> > > >
> >>>> > > > Hedwin
> >>>> > > >
> >>>> > > > On Sat, Dec 26, 2009 at 7:29 PM, Yi Sun
> >>>> > <beyo...@gmail.com>
> >>>> > > <beyo...@gmail.com>
> >>>> > > > wrote:
> >>>> > > > > Themouseshould work on
> >>>> > Android-x86.org
> >>>> > > out of box.
> >>>> > > > Where did
> >>>> > > > > you get
> >>>> > > > > your source code for your
> >>>> > android-x86?
> >>>> > > > > Yi
> >>>> > > > >
> >>>> > > > > On Wed, 2009-12-23 at 12:44
> >>>> > +0100, hedwin
> >>>> > > wrote:
> >>>> > > > > > Meant to say is that it did
> >>>> > not work
> >>>> > > because
> >>>> > > > android thinks
> >>>> > > > > the screen is off.
> >>>> > > > > >
> >>>> > > > > > Will provide the details when
> >>>> > I am back
>
> ...
>
> read more »
helen.wjt
On 2009年12月17日, 下午3时07分, hedwin <hedwin.kon...@gmail.com> wrote:
> USBmouseand keyboard do work, only enabled them in the kernel and it
> worked without any change to android.
> But then again was using the mips android so not sure yet if specific
> changes were made there that makes it work.
>
> Hedwin
>
>
>
> On Wed, Dec 16, 2009 at 7:09 PM, Yi Sun <beyo...@gmail.com> wrote:
> > Android does not supportmouseby default. But you can pick up all the
> > changes from android-x86.org for themousesupport. Check the git logs
> > in frameworks/base and frameworks/policy/base. You will be abel to find
> > the changes
> > And, yes, you need to enabled yourmousedriver in the kernel first.
> > Yi
> > On Wed, 2009-12-16 at 14:56 +0100, hedwin wrote:
> >> You need to enable this in the linux kernel.
>
> >> Hedwin
>
> >> On Wed, Dec 16, 2009 at 4:02 AM, jian qin <qinjiana0...@gmail.com> wrote:
> >> > I want know how to usemousein Android,please help me.
Yi Sun
2010/1/26 helen.wjt <hele...@gmail.com>:
--
Android-x86
http://www.android-x86.org