On Mon, 5 Jan 2009 18:55:50 -0200 Tiago Vignatti <vigna...@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. This analysis is based on how I use GUIs, and how I think my mother uses GUIs as I've watched her, and we are on a very different level of thinking on how computers and GUIs with a mouse work. Sure, modern GUIs have mouse enter/leave animations for widgets, but it takes an experienced user to notice that hey, that button didn't turn blue when I moved my mouse over it, something's wrong. Making the mouse cursor jump is something no-one can ignore, even when they are in a hurry. If you embrace the idea that cursor updates have to visit user space, I believe it will make implementing things like secondary cursors and cursors that exceed hardware capabilities (e.g. very large cursors) easier. You don't have to implement a full 3D engine driver in the kernel to just blit the cursor image on screen (aren't simple blitting engines and overlays disappearing in the modern development of graphics hardware?). -- Pekka Paalanen http://www.iki.fi/pq/ ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
