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].
This series of patches implement such feature using Xorg as the application. Through an ioctl, Xorg tells which devices are responsible for cursors' updates and the kernel evdev driver will spit the events to DRM. DRM will take care about the event informations and also screen limits, and then will draw the cursor on screen. Very intuitive. Right now a thing that is annoying me is how others cursors, sw rendered, could be implemented. I want to avoid two differents sets of the same code in different contexts. IMHO conceptually all these cursor update things must be in-kernel. Painting a cursor image seems to be quite hard as we have to save/restore areas under the cursor. I remember that anholt had an idea concerning this, but I do not remember details. Well, the patches are far from ready to go upstream, but it deploys a system working on this way. So, for now, this mail has two goals: - to people comment on and see in what kind of world we can move. - get a feedback how we can proceed in the case of sw cursors. Please, comment on. Thank you, [0] http://vignatti.wordpress.com/2008/07/29/improving-input-latency/ -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ------------------------------------------------------------------------------ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel