On Mon, Aug 11, 2014 at 9:42 AM, Tom Li <biergaizi2009@xxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
