Ok, this requires quite a dance to actually hit:
1) We plug in a 2nd screen, enable it in both X and (by vt-switching)
in the fbcon.
2) We disable that screen again in with xrandr.
3) We vt-switch again, so that fbcon displays on the 2nd screen, but X
on the first screen. This obviously needs a driver that doesn't switch
off unused functions when regaining the VT.
3) When X controls the vt, we unplug that screen.

Now drm_fb_helper_hotplug_event we noticed that that some crtcs are
bound, but because we still have the fbcon on the 2nd screeen we also
have bound set. Which means the fbcon wrongly assumes it's in control
of everything an happily disables the output on the 2nd screen, but
enables its fb on the first screen.

Work around this issue by counting how many crtcs are bound and how
many are bound to fbcon and assuming that when fbcon isn't bound to
all of them, it better not touch the output configuration.

Conceptually this is the same as only restoring the fbcon output
configuration on the driver's ->lastclose, when we're sure that no one
else is using kms. So this should be consistent with existing kms
drivers.

Chris has created a separate patch for the intel ddx, but I think we
should fix this issue here regardless - the fbcon messing with the
output config while it's not fully in control simply isn't a too
polite behaviour.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50772Tested-by: NMaxim A. Nikulin <M.A.Nikulin@gmail.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Drivers for hardware without gamma support should not be forced to
implement a no-op gamma set operation.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Rob Clark <rob.clark@linaro.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

It won't find any, yet.  Fix up callers to match: standard mode codes
will look prefer r-b modes for a given size if present, EST3 mode codes
will look for exactly the r-b-ness mentioned in the mode code.  This
might mean fewer modes matched for EST3 mode codes between now and when
the DMT mode list regrows the r-b modes, but practically speaking EST3
codes don't exist in the wild.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Tested-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

mplayer -vo fbdev tries to create a screen that is twice as tall as the
allocated framebuffer for "doublebuffering". By default, and all in-tree
users, only sufficient memory is allocated and mapped to satisfy the
smallest framebuffer and the virtual size is no larger than the actual.
For these users, we should therefore reject any userspace request to
create a screen that requires a buffer larger than the framebuffer
originally allocated.

References: https://bugs.freedesktop.org/show_bug.cgi?id=38138Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

crtc_id is set but never used, so remove it from struct
drm_fb_helper_crtc.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

conn_limit is set but never used. Remove it from struct
drm_fb_helper.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

drm_fb_helper_on|off currently manually searches for encoders
to turn on/off. Make this simpler by using the helper function.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

drm_setup_crtcs allocated modes using drm_mode_duplicate. Free
them in drm_fb_helper_crtc_free.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if
we're going to reboot immediately, the user will not be able to see the
messages anyway, and messing with the video mode may display artifacts,
and certainly get into several layers of complexity (including mutexes and
memory allocations) which we shall be much safer to avoid.
Signed-off-by: NHugh Dickins <hughd@google.com>
[ Edited commit message and modified to short-circuit panic_timeout < 0
  instead of testing panic_timeout >= 0.  -Mandeep ]
Signed-off-by: NMandeep Singh Baines <msb@chromium.org>
Acked-by: NDavid Rientjes <rientjes@google.com>
Acked-by: NStéphane Marchesin <marcheu@chromium.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

So that we don't get build failures once the implicit module.h
presence is removed.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

Remove the duplicate "return" statement in drm_fb_helper_panic().
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We need to hold the dev->mode_config.mutex whilst detecting the output
status. But we also need to drop it for the call into
drm_fb_helper_single_fb_probe(), which indirectly acquires the lock when
attaching the fbcon.

Failure to do so exposes a race with normal output probing. Detected by
adding some warnings that the mutex is held to the backend detect routines:

[   17.772456] WARNING: at drivers/gpu/drm/i915/intel_crt.c:471 intel_crt_detect+0x3e/0x373 [i915]()
[   17.772458] Hardware name: Latitude E6400
[   17.772460] Modules linked in: ....
[   17.772582] Pid: 11, comm: kworker/0:1 Tainted: G        W 2.6.38.4-custom.2 #8
[   17.772584] Call Trace:
[   17.772591]  [<ffffffff81046af5>] ? warn_slowpath_common+0x78/0x8c
[   17.772603]  [<ffffffffa03f3e5c>] ? intel_crt_detect+0x3e/0x373 [i915]
[   17.772612]  [<ffffffffa0355d49>] ?  drm_helper_probe_single_connector_modes+0xbf/0x2af [drm_kms_helper]
[   17.772619]  [<ffffffffa03534d5>] ?  drm_fb_helper_probe_connector_modes+0x39/0x4d [drm_kms_helper]
[   17.772625]  [<ffffffffa0354760>] ?  drm_fb_helper_hotplug_event+0xa5/0xc3 [drm_kms_helper]
[   17.772633]  [<ffffffffa035577f>] ? output_poll_execute+0x146/0x17c [drm_kms_helper]
[   17.772638]  [<ffffffff81193c01>] ? cfq_init_queue+0x247/0x345
[   17.772644]  [<ffffffffa0355639>] ? output_poll_execute+0x0/0x17c [drm_kms_helper]
[   17.772648]  [<ffffffff8105b540>] ? process_one_work+0x193/0x28e
[   17.772652]  [<ffffffff8105c6bc>] ? worker_thread+0xef/0x172
[   17.772655]  [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
[   17.772658]  [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
[   17.772663]  [<ffffffff8105f767>] ? kthread+0x7a/0x82
[   17.772668]  [<ffffffff8100a724>] ? kernel_thread_helper+0x4/0x10
[   17.772671]  [<ffffffff8105f6ed>] ? kthread+0x0/0x82
[   17.772674]  [<ffffffff8100a720>] ? kernel_thread_helper+0x0/0x10
Reported-by: NFrederik Himpe <fhimpe@telenet.be>
References: https://bugs.freedesktop.org/show_bug.cgi?id=36394Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

In the absence of configuration data for providing the fixed mode for
a panel, I would like to be able to pass such modes along a separate
module paramenter. To do so, I then need to parse a modeline from a
string, which drm is already capable of. Export that capability to the
drivers.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We need to hold the dev->mode_config.mutex whilst detecting the output
status. But we also need to drop it for the call into
drm_fb_helper_single_fb_probe(), which indirectly acquires the lock when
attaching the fbcon.

Failure to do so exposes a race with normal output probing. Detected by
adding some warnings that the mutex is held to the backend detect routines:

[   17.772456] WARNING: at drivers/gpu/drm/i915/intel_crt.c:471 intel_crt_detect+0x3e/0x373 [i915]()
[   17.772458] Hardware name: Latitude E6400
[   17.772460] Modules linked in: ....
[   17.772582] Pid: 11, comm: kworker/0:1 Tainted: G        W 2.6.38.4-custom.2 #8
[   17.772584] Call Trace:
[   17.772591]  [<ffffffff81046af5>] ? warn_slowpath_common+0x78/0x8c
[   17.772603]  [<ffffffffa03f3e5c>] ? intel_crt_detect+0x3e/0x373 [i915]
[   17.772612]  [<ffffffffa0355d49>] ?  drm_helper_probe_single_connector_modes+0xbf/0x2af [drm_kms_helper]
[   17.772619]  [<ffffffffa03534d5>] ?  drm_fb_helper_probe_connector_modes+0x39/0x4d [drm_kms_helper]
[   17.772625]  [<ffffffffa0354760>] ?  drm_fb_helper_hotplug_event+0xa5/0xc3 [drm_kms_helper]
[   17.772633]  [<ffffffffa035577f>] ? output_poll_execute+0x146/0x17c [drm_kms_helper]
[   17.772638]  [<ffffffff81193c01>] ? cfq_init_queue+0x247/0x345
[   17.772644]  [<ffffffffa0355639>] ? output_poll_execute+0x0/0x17c [drm_kms_helper]
[   17.772648]  [<ffffffff8105b540>] ? process_one_work+0x193/0x28e
[   17.772652]  [<ffffffff8105c6bc>] ? worker_thread+0xef/0x172
[   17.772655]  [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
[   17.772658]  [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
[   17.772663]  [<ffffffff8105f767>] ? kthread+0x7a/0x82
[   17.772668]  [<ffffffff8100a724>] ? kernel_thread_helper+0x4/0x10
[   17.772671]  [<ffffffff8105f6ed>] ? kthread+0x0/0x82
[   17.772674]  [<ffffffff8100a720>] ? kernel_thread_helper+0x0/0x10
Reported-by: NFrederik Himpe <fhimpe@telenet.be>
References: https://bugs.freedesktop.org/show_bug.cgi?id=36394Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

i915 calls the panic handler function on last close to reset the modes,
however this is a really bad idea for multi-gpu machines, esp shareable
gpus machines. So add a new entry point for the driver to just restore
its own fbcon mode.

v2: move code into fb helper, fix panic code to block mode change on
powered off GPUs.

[airlied: this hits drm core and I wrote it and it was reviewed on intel-gfx
 so really I signed it off twice ;-).]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Index i was already used in thhe first loop
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If there is an alpha channel, need to mask in 1's in the alpha channel
to prevent the fb from being completely transparent.
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The meaning of CONFIG_EMBEDDED has long since been obsoleted; the option
is used to configure any non-standard kernel with a much larger scope than
only small devices.

This patch renames the option to CONFIG_EXPERT in init/Kconfig and fixes
references to the option throughout the kernel.  A new CONFIG_EMBEDDED
option is added that automatically selects CONFIG_EXPERT when enabled and
can be used in the future to isolate options that should only be
considered for embedded systems (RISC architectures, SLOB, etc).

Calling the option "EXPERT" more accurately represents its intention: only
expert users who understand the impact of the configuration changes they
are making should enable it.
Reviewed-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NDavid Woodhouse <david.woodhouse@intel.com>
Signed-off-by: NDavid Rientjes <rientjes@google.com>
Cc: Greg KH <gregkh@suse.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Robin Holt <holt@sgi.com>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This reverts commit dfe63bb0.

This commit was causing nouveau not to work properly, for -rc1 I'd
prefer it worked and we can look if this is useful for 2.6.39.

Cc: James Simmons <jsimmons@infradead.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If you change the color depth via fbset or some other framebuffer aware
userland application struct fb_fix_screeninfo is not updated to this new
information. This patch fixes this issue. Also the function is changed to
just pass in struct drm_framebuffer so in the future we could use more
fields. I'm hoping some day fix->smem* could be set here :-)
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Kconfig says fbcon is required by drm_kms_helper.  If radeon, fbcon,
and drm_kms_helper are all modules, radeon is auto loaded (by PCI id?),
drm_kms_helper is loaded because of the module dependency, but fbcon
isn't loaded leaving the console unusable.  Since fbcon is required
and there isn't an explicit module dependency, request the module
to be loaded from drm_kms_helper.
Signed-off-by: NDavid Fries <david@fries.net>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

For the fbdev api if the struct fb_var_screeninfo accel_flags field is set
to FB_ACCELF_TEXT then userland applications can not mmap the mmio region.
Since it is a bad idea for DRM drivers to expose the mmio region via the
fbdev layer we always set the accel_flags to prevent this. Please apply.
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The enter argument as implemented by commit 413d45d3 (drm, kdb, kms:
Add an enter argument to mode_set_base_atomic() API) should be more
descriptive as to what it does vs just passing 1 and 0 around.

There is no runtime behavior change as a result of this patch.
Reported-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
CC: David Airlie <airlied@linux.ie>
CC: dri-devel@lists.freedesktop.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

When changing VTs non-atomically the kernel works in conjunction with
the Xserver in user space and receives the LUT information from the
Xserver via a system call.  When changing modes atomically for kdb,
this information must be saved and restored without disturbing user
space as if nothing ever happened.

There is a short cut used by this patch where gamma_store is used as
the save space.  If this turns out to be a problem in the future a
pre-allocated chunk of memory will be required for each crtc to save
and restore the LUT information.
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: David Airlie <airlied@linux.ie>
CC: dri-devel@lists.freedesktop.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Some devices such as the radeon chips receive information from user
space which needs to be saved when executing an atomic mode set
operation, else the user space would have to be queried again for the
information.

This patch extends the mode_set_base_atomic() call to pass an argument
to indicate if this is an entry or an exit from an atomic kernel mode
set change.  Individual drm drivers can properly save and restore
state accordingly.
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: David Airlie <airlied@linux.ie>
CC: dri-devel@lists.freedesktop.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Noone is using tty argument so let's get rid of it.
Acked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
Acked-by: NJason Wessel <jason.wessel@windriver.com>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

"fb_helper_conn" is dereferenced before the check for NULL.  It's never
actually NULL here, so this is mostly to keep the static checkers happy.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Commit 5349ef31 (drm/fb: fix
FBIOGET/PUT_VSCREENINFO pixel clock handling) changed the logic of
when a pixclock was valid vs invalid.

The atomic kernel mode setting used by the kernel debugger relies upon
the drm_fb_helper_check_var() to always return -EINVAL.  Until a
better solution exists, this behavior will be restored.

CC: David Airlie <airlied@linux.ie>
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>

Implement the callbacks for KDB entry/exit via the drm helpers.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>

We don't currently update the DPMS status of the connector (both in the
connector itself and the connector's DPMS property) in the fb helper
code.  This means that if the kernel FB core has blanked the screen,
sysfs will still show a DPMS status of "on".  It also means that when X
starts, it will try to light up the connectors, but the drm_crtc_helper
code will ignore the DPMS change since according to the connector, the
DPMS status is already on.

Fixes https://bugs.freedesktop.org/show_bug.cgi?id=28436 (the annoying
"my screen was blanked when I started X and now it won't light up" bug).
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Reduced blanking is valid only when doing CVT modes.  Also, generate GTF
modes unless CVT was requested; CVT devices are required to support GTF,
but the reverse is not true.

[airlied: fix typo]
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

using DRM_ERROR, results in people blaming the drm code for the oops, and
not looking at the oops.

(sadly yes I've gotten reports).
Signed-off-by: NDave Airlie <airlied@redhat.com>

Simple cloning rules compared to server:
(a) single crtc
(b) > 1 connector active
(c) check command line mode
(d) try and find 1024x768 DMT mode if no command line.
(e) fail to clone
Signed-off-by: NDave Airlie <airlied@redhat.com>

After thinking it over a lot it made more sense for the core to deal with
the output polling especially so it can notify X.

v2: drop plans for fake connector - per Michel's comments - fix X patch sent to xorg-devel, add intel polled/hpd setting, add initial nouveau polled/hpd settings.

v3: add config lock take inside polling, add intel/nouveau poll init/fini calls

v4: config lock was a bit agressive, only needed around connector list reading.
otherwise it could re-enter.

glisse: discard drm_helper_hpd_irq_event

v3: Reviewed-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Recently I've studied my system dmesg and seen this:

  <lots of stuff before>
1 [    0.478416] ACPI: Battery Slot [C1B4] (battery present)
2 [    0.478648] ACPI: Battery Slot [C1B3] (battery absent)
3 [    0.906678] [drm] initialized overlay support
4 [    1.762304] Console: switching to colour frame buffer device 128x48
5 [    1.765211] fb0: inteldrmfb frame buffer device
6 [    1.765242] registered panic notifier
7 [    1.765272] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
8 [    1.765372] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
  <lots of stuff after>

and it was not evident who registered that panic notifier on line 6.

I'd bought it as some low-level stuff needed by kernel itself, but the
time was inappropriate -- too late for such things.

So I had to study sources to see it was drm who was registering
switch-to-fb on panic.

Let's avoid possible confusion and mark this message as going from drm
subsystem.

(I'm a bit unsure whether to use '[drm]:' or 'drm:' -- the rest of the
 kernel just uses 'topic:', and even in drm_fb_helper.c we use 'fb%d:'
 without [] brackets. Either way is ok with me.)
Signed-off-by: NKirill Smelkov <kirr@landau.phys.spbu.ru>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This patch is against the drm-fbdevfix1 branch. It removes the
drm_fb_helper_setcolreg function. The reason is that fb_setcolreg is only
used in the case where fb_setcmap is called and no fb_ops->fb_setcmap is
used. In the drm case we always need a fb_setcmap hook to handle multiple
crtcs so we don't need a fb_setcolreg hook. Please apply.
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

a) slow work is always used now for any fbcon hotplug, as its not
   a fast task and is more suited to being ran under slow work.

b) attempt to not do any fbdev changes when X is running as we'll
   just mess it up. This hooks set_par to hopefully do the changes
   once X hands control to fbdev.

This also adds the nouveau/intel hotplug support.
Signed-off-by: NDave Airlie <airlied@redhat.com>

When we are running in a headless environment we have no idea what
output the user might plug in later, we only have hotplug detect
from the digital outputs. So if we detect no connected outputs at
initialisation, start a slow work operation to poll every 5 seconds
for an output.

this is only hooked up for radeon so far, on hw where we have full
hotplug detection there is no need for this.
Signed-off-by: NDave Airlie <airlied@redhat.com>

If we get no outputs setup provide a 1024x768 fbcon, with
this + radeon hotplug stuff I can plug a monitor in after startup
and get to see stuff.

Last thing is to add some sort of timer for non-hpd outputs like
VGA etc.
Signed-off-by: NDave Airlie <airlied@redhat.com>