Implementing the accelerated DRI/DRM driver for a pure 2D graphics card?

[Ilia Mirkin]

On Mon, Aug 11, 2014 at 9:42 AM, Tom Li <biergaizi2009 at gmail.com> wrote:
> Hello everyone.
>
> I'm currently working on a DRM/KMS driver for the Silicon Motion SM712
> graphics card. Avoid the flicking between the VT-switching on my
> computer is what I want.
> This antiquated card doesn't support 3D and OpenGL stuff, but provide
> simple 2D acceleration by a drawing processor. Currently, the DDX
> driver xf86-video-siliconmotion directly accessing the hardware to
> write the registers for modesetting and 2D acceleration.
>
> But in the world of KMS/DRI, Xorg/DDX can't just control the cards and
> write the registers anymore. It is not a problem for modesetting
> because there's standard KMS way, but it prevent the DDX driver to
> access the 2D drawing processor. It is the problem, the card will
> become even more slower if it lost the only acceleration.
>
> Implement the complete DRI/DRM framework seems the right way to do it.
> But it seems the DRI/DRM are mainly designed for modern cards, 2D is
> just the subset of 3D / OpenGL, so it always got implemented
> automatically if we just implemented 3D. Many documents are talking
> about how to deal with the vertices / textures to implement 2D/3D, but
> I just have something like fillrect.
>
> So I just stuck at here. Is there a standard way to just let
> userspace/DDX to access the 2D drawing processor by the exported
> interface or DRI/DRM layer?

There's nothing specific to 3D in the DRM api's exposed by the kernel
drivers. They all just provide a method for submitting commands to the
card via ioctl's, manage buffers, etc. Each driver has its libdrm_foo
userspace API that hides the ioctl nastiness and provides a cleaner C
API. Many modern (and even older) hardware works by having a command
ring that the hardware processes, and userspace just provides lists of
those commands, as well as buffer management. Then the DDX and Mesa
and anything else that wants direct access uses the
libdrm_foo-provided APIs to submit commands to the card.

Hope this helps,

  -ilia