When the framebuffer driver does not publish detailed timing information
for the current video mode, the correct value for the pixclock field is
zero, not -1.

Since pixclock is actually unsigned, the value -1 would be interpreted
as 4294967295 picoseconds (i.e., about 4 milliseconds) by
register_framebuffer() and userspace programs.

This patch allows X.org's fbdev driver to work.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Tested-by: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>

I believe this is a typo.

Signed-off-by: Dave Airlie <airlied@redhat.com>

This sets the fbcon to use TRUECOLOR by default, it then
only modifies the pseudo palette for fbcon, and only touches
the real palette when in 8-bit pseudo color mode.

Signed-off-by: Dave Airlie <airlied@redhat.com>

The previous patches had some unwanted side effects, I've fixed
the lack of 32bpp working, and fixed up 16bpp so it should also work.

this also adds the interface to allow the driver to set a preferred
console depth so for example low memory rn50 can set it to 8bpp.
It also catches 24bpp on cards that can't do it and forces 32bpp.

Tested on r100/r600/i945.

Signed-off-by: Dave Airlie <airlied@redhat.com>

This adds support for the setcmap api and fixes the 8bpp
support at least on radeon hardware. It adds a new load_lut
hook which can be called once the color map is setup.

Signed-off-by: Dave Airlie <airlied@redhat.com>

Compiling DRM throws the following warning if MAGIC_SYSRQ is disabled:

drivers/gpu/drm/drm_fb_helper.c:101: warning: 'sysrq_drm_fb_helper_restore_op' defined but not used

Fix: place sysrq_drm_fb_helper_restore_op and associated
definitions inside #ifdef CONFIG_MAGIC_SYSRQ.

Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>
Signed-off-by: Dave Airlie <airlied@linux.ie>

This initialises the fb helper with the connector helper,
so that the fb cmdline code works for intel as well.

Signed-off-by: Dave Airlie <airlied@redhat.com>

If drivers don't init the fb helper on the connector, the cmdline
code won't work, but it shouldn't crash either.

Signed-off-by: Dave Airlie <airlied@redhat.com>

[note this requires an fb patch posted to linux-fbdev-devel already]

This uses the normal video= command line option to control the kms
output setup at boot time. It is used to override the autodetection
done by kms.

video= normally takes a framebuffer as the first parameter, in kms
it will take a connector name, DVI-I-1, or LVDS-1 etc. If no output
connector is specified the mode string will apply to all connectors.

The mode specification used will match down the probed modes, and if
no mode is found it will add a CVT mode that matches.

video=1024x768 - all connectors match a 1024x768 mode or add a CVT on
video=VGA-1:1024x768, VGA-1 connector gets mode only.

The same strings as used in current fb modedb.c are used, except I've
added three more letters, e, D, d, e = enable, D = enable Digital,
d = disable, which allow a connector to be forced into a certain state.

Signed-off-by: Dave Airlie <airlied@redhat.com>

The drm_fb_helper shouldn't mess with CRTCs that aren't enabled or in
its initial config. Ideally it shouldn't even include CRTCs in its
initial config if they're not in use, but my old fix for that no longer
works.  At any rate, this fixes a real bug I was seeing where after a
console blank, both pipes would come back on, even though only one had
been enabled before that.  Since the other pipe had a bogus config,
this led to some screen corruption.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>