Not sure if the hardware cursor would solve the problem or not. the
intelfb driver has hw cursor support. Let see if I can find a time to
try it out.
Yi
On Thu, 2009-05-21 at 12:24 +0800, Chen Yang wrote:
> My guess is the surface transaction related handling caused the
> recomputation of the whole screen. I have observed with the diaglo on,
> system_server used lots of cpu time.
> So we may need to find some better approach in drawing the cursor.
> Can some one from google give some comments? Thanks.
> --
> Chen
>
> 2009/5/21 Yi Sun <beyo...@gmail.com>
> This code is wrong (Ya, I did it). But, it should not be the
> reason of the slowness. The position convert should not happen
> here. Otherwise, the event batch will crew up the position
> value in the original event. Even after I fixed it, the
> slowness is still there. One thing I have observed is that
> the performance issue only happens when we use it in multiple
> select window. For the other cases, it seems to be ok.
>
> One more problem is that when I drag an icon around window,
> the icon has never moved to the place I want. The position
> value seems correct, need to dig more when have time.
>
>
> 2009/5/20 Chen Yang <sunsety...@gmail.com>
>
>
> The mouse cursor works! Thanks to Yi for your great
> work! :)
> I also observed the same as Chih-wei, if there are
> some dialog appears, the mouse cursor responds very
> slowly. To have a try, you can just try in the home
> screen, long press the mouse and then one dialog will
> pop up, then you can try to move the mouse, it
> responds to the move very slowly. I guess it may
> relate to some computation internally to dim to
> background. But i haven't done any extra
> investigation. Given the vesafb's large screen and
> lack of hardware acceleration, the dim computation may
> take some cpu cycles.
>
> So one question raises: is there some better
> implementation to draw the mouse cursor? I am
> attaching the drawing here, and highly appreciate the
> suggestions! Thanks.
>
> @@ -5119,6 +5134,44 @@ public class
> WindowManagerService extends IWindowManager.Stub
> implements Watchdo
> //Log.i(TAG, "Read
> next event " + ev);
> dispatchPointer(ev,
> (MotionEvent)ev.event, 0, 0);
> break;
> + case
> RawInputEvent.CLASS_MOUSE:
> + MotionEvent mmev =
> (MotionEvent)ev.event;
> + int mcx = mMlx +
> (int)(mmev.getX()* mmev.getXPrecision());
> + int mcy = mMly +
> (int)(mmev.getY()* mmev.getYPrecision());
> + mcx = ((mcx < 0) ?
> 0 :(mcx >=
> mDisplay.getWidth() ?(mDisplay.getWidth()-1):mcx));
> + mcy = ((mcy < 0) ?
> 0 :(mcy >= mDisplay.getHeight()?(mDisplay.getHeight()
> - 1):mcy));
> +
> +
> mmev.setLocation((float) mcx, (float) mcy);
> + dispatchPointer(ev,
> mmev, 0, 0);
> + if (mMouseSurface !=
> null && (mMlx != mcx || mMly != mcy))
> {
> + // Should we use
> lock? synchronized(mWindowMap) {
> +
> Surface.openTransaction();
> + if (DEBUG_INPUT)
> + Log.i(TAG,
> + "Open
> transaction for the mouse surface");
> + WindowState top
> =
> +
> (WindowState)mWindows.get(mWindows.size() - 1);
> + try {
> + if
> (DEBUG_INPUT)
> +
> Log.i(TAG, "Move surf, x: " +
> +
> Integer.toString(mcx) + " y:"
> + +
> Integer.toString(mcy));
> +
> +
> mMouseSurface.setPosition(mcx,mcy);
> +
> mMouseSurface.setLayer(top.mAnimLayer + 1);
> + if
> (mShowMouse != 1) {
> +
> mMouseSurface.show();
> +
> mShowMouse = 1;
> + }
> + mMlx = mcx;
> + mMly = mcy;
> + } catch
> ( RuntimeException e) {
> + Log.e(TAG,
> "Failure showing mouse surface",e);
> + }
> +
> Surface.closeTransaction();
> + }
> +
> + break;
>
> --
> Chen
>
>
>
> On Fri, May 8, 2009 at 11:48 PM, Yi Sun
> <beyo...@gmail.com> wrote:
>
> CHih-wei,
> Could you document the test results in the
> project wiki? THanks
> Yi
>
> On Fri, 2009-05-08 at 00:40 -0700, Chih-Wei
> wrote:
> > I've done more tests on all EeePC I can
> access, including
> > 701/701SD/900/900A/901/904HD/1000/1000HD.
> > (using the same kernel image, of course)
> > The touchpad works for all models, except
> 701. Very strange...
> >
> > However, I noticed a strange behavior.
> > If there is a popup message box (e.g., XXX
> is closed unexpected),
> > the mouse cursor becomes very slow and
> irresponsive.
> > After closing the message box, the cursor
> becomes normal.
> > Any comment?
> >
> > On 5月8日, 上午12時55分, Yi Sun
> <beyo...@gmail.com> wrote:
> > > A..... I don't know :-). Ok, let me try to
> find a 701, If I can get one,
> > > I will try it out.
> > > At the meanwhile, I will post the new
> patch.
> > > Yi
> > >
> > > On Wed, 2009-05-06 at 23:29 -0700,
> Chih-Wei wrote:
> > > > Hi Yi,
> > > > Indeed I took that configuration (plus
> some additional drivers).
> > > > The following options are enabled:
> > > > CONFIG_INPUT_MOUSE=y
> > > > CONFIG_MOUSE_PS2=y
> > > > CONFIG_MOUSE_PS2_ALPS=y
> > > > CONFIG_MOUSE_PS2_LOGIPS2PP=y
> > > > CONFIG_MOUSE_PS2_SYNAPTICS=y
> > > > CONFIG_MOUSE_PS2_LIFEBOOK=y
> > > > CONFIG_MOUSE_PS2_TRACKPOINT=y
> > > > CONFIG_MOUSE_PS2_TOUCHKIT=y
> > > > CONFIG_MOUSE_SERIAL=y
> > > > ...
> > > > I just tested it on EeePC 1000, with the
> same kernel image I tested on
> > > > 701.
> > > > Amazingly, the touchpad works.
> > > > So... what's the problem?
> >
> > >
>
>
>
>
>
>
>
>
>
>
>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---
