[PATCH 0/4] Cursor's update inside kernel only

[Jesse Barnes]

On Sunday, January 25, 2009 2:28 am Pekka Paalanen wrote:
> On Mon, 5 Jan 2009 18:55:50 -0200
>
> Tiago Vignatti <vignatti at c3sl.ufpr.br> wrote:
> > Hi guys,
> >
> > Under KMS, we can build a feature to update the cursor directly to screen
> > without the continuous intervention of the userspace application (X
> > server, wayland, etc). It's a fastpath for DRM based cursors obtained by
> > short-circuit the kernel input layer and DRM module. This would solve all
> > cursor's latency issues that we have in our current model [0].
>
> Reducing latency is a good idea, but I don't think circumventing user space
> altogether is so good. Consider a case where user space is stalled due to
> excessive load, and let's think about usability. Much of usability comes
> from feedback given to a user.
>
> If cursor updates are done completely inside the kernel, the mouse will
> continue to work without any hiccups under severe load (this is what you
> are aiming for, right?). The user clicks a button, and nothing happens in
> the GUI, since user space is stalled. The user clicks again. And again.
> Then clicks another button. It takes several seconds for the user to
> realize, that the clicks are not getting processed. What's worse, all the
> clicks are probably queued now and will be processed later, possibly
> leading to unexpected results.
>
> If cursor updates had to visit user space, the mouse cursor would stall
> and jump. This is bad behaviour in itself, but it is also an immediate
> feedback to the user, that the system is not responsive. The user cannot
> even reach a button to click it, before he sees that something is going on.
> In a bad situation, I think this is the less evil choice.

SGI did some use case studies on this.  The conclusion they drew was that the 
cursor should *always* be responsive, and so that's what they did back in the 
old days on IRIX.  Unfortunately we don't have access to that data so we 
don't know the circumstances under which they tested users, or what the 
tradeoffs were.

But personally I think it sucks when the pointer jumps around, no matter what 
the situation is with the machine.  It makes the whole OS seem cheap and 
crappy.  And for a more "typical" user, I still think smooth movement makes 
sense.  We already have other ways of communicating "system/program busy" 
than cursor movement (greyed out windows for instance), so I don't buy that 
argument either.

-- 
Jesse Barnes, Intel Open Source Technology Center