All the conditional features, such as DDC support, are now enabled and
the source file includes the copied header file.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

This adds tdfxkms, a DRM driver for 3dfx Banshee, Voodoo 3 or later. The
driver provides a non-accelerated framebuffer with atomic mode setting.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

With the update, all driver code coming from matroxfb is build
unconditionally. The driver registers itself with the mgakms driver,
instead of the fbdev core.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

Only code is being copied, no functional changes are made.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

The mgakms driver uses DRM's fbconv helpers to provide a DRM driver
for Matrox chipsets. This will allow matroxfb to be refactored into
a first-class DRM driver.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

There's now a tutorial on how to create a DRM driver on top of fbconv
helpers. The DRM TODO list contains an entry for converting fbdev
drivers over to DRM.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

The implementation of drm_fbconv_fill_fb_info() sets up an fbdev driver's
fb_info structure for use. It's similar to register_framebuffer(), but does
not create device files, register the driver with the fbdev code or create
a console. drm_fbconv_cleanup_fb_info() does the inverse.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

This patch reimplements fb_blank(), fb_pan_display(), fb_set_cmap() and
fb_set_var() for fbconv helpers. The goal is to have all calls to driver
callback functions located within fbconv and to reduce the amount of
contained work to a minimum.

Some noteable differences to fbdev include:

  * Code related to fbcon has been left out. Console support is
    emulated by DRM and the drivers don't interact directly with
    it.

  * No events are sent out. As the fbconv helpers are not part of
    the fbdev framework, there are no event listeners anyway.

  * Code related to ioctl and user-space has been left out as
    well. User-space interfaces are provided by DRM.

  * Error messages have been added.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

The display mode is set by converting the DRM display mode to an
fb_info state and handling it to the fbdev driver's fb_setvar()
function. This also requires a color depth, which we take from the
value of struct drm_mode_config.preferred_depth

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

For the update of the primary plane, we copy the content of a SHMEM buffer
object to the hardware's on-screen buffer; doing a format conversion if
necessary. This is able to support all combinations of framebuffers and
hardware, and should work with any fbdev driver.

Occasionally, fbdev drivers require an update of the hardware's gamma
tables to not show distorted colors. We also do this during the plane
update.

There's no support for horizontal panning, as fbdev drivers vary widely
in their capability to do this. Vertical panning is supported to the
extend allowed by available video ram. However, this whole functionality
is more interesting for porting drivers and not directly required by
fbconv itself.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

Modesetting for fbconv supports a single display pipeline with CRTC,
primary plane, encoder and connector. It's implementation is based on
struct drm_simple_display_pipe, which fits this use case nicely.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

DRM uses struct drm_display_mode to describe a display mode. The
conversion functions fill it from fbdev data strucutures, and vice
versa.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>