cursor handling and updates inside DRM
vignatti at c3sl.ufpr.br
Thu Jul 10 00:05:57 PDT 2008
The current DRM kernel modesetting tree is already taking care to update
the cursor registers and paint it to the screen. Very cool .
What I've done today is a shortcut between the kernel input layer and
DRM to update the cursor directly on screen without the X server be
notified always. Of course, a lot of issues raised up together. So let's
try to delegates the tasks again.
userspace app (X server):
- starts all this mechanism telling which is the device responsible for
the cursor (input ddx drv)
- responsible for loading new cursor images and push to the DRM (video
kernel input layer (evdev driver):
- notify and send its relative coordinates events to DRM
- transform relative motion into absolute
- takes care the cursor limits
- responsible for the acceleration computation
- responsible for the input transformation as well?
- touch the gfx registers.
Seems that a reasonable amount of code in ddx input drv (mainly
ReadInput) and dix (mainly GetPointerEvents) would be "swallowed" by the
DRM. The "event generation stage" of the server would deal with the
event itself + xkb + Xi things (which eventually could be done in a
dedicated thread) and will let to DRM the responsibility of paint the
cursor on screen.
The communication between kernel input drv can be directly, calling a
DRM function; the DRM and userspace can communicate basically using
This would only works with DRM supporting OSes. What about the others?
 Not so much. Seems this method to update the cursor is sending _a
lot of_ ioctls and sometimes doing cursor jumps. But I have to double
check to see if the problem is for sure with context switches.
C3SL - Centro de Computação Científica e Software Livre
More information about the xorg