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 -~----------~----~----~----~------~----~------~--~---