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

[olafBuddenhagen at gmx.net]

Hi,

On Sun, Jan 25, 2009 at 12:28:37PM +0200, Pekka Paalanen wrote:

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

I totally agree that when the GUI is totally stalled, the curser better
be stalled as well... But this is actually a rather untypical case.

Much more often the cursor just becomes somewhat jerky under load. The
GUI becomes sluggish, but still quite usable. The jerky cursor however
makes it much harder to work with it -- a smooth cursor indeed improves
usability in this case.

On top of that, there is an important psychological effect: With a jerky
cursor, the system *feels* much slower than it actually is. Users think,
"This X stuff is reall crap: OS X/Windows/whatever is so much
smoother..." Sad but true.

So ideally, the cursor should remain smooth under some load, but stall
when the system is really busy... Any suggestions how to achieve that?
:-)

-antrik-