[PATCH 2/3] vt: fix issue when fbcon wants to takeover a second time.

From: Dave Airlie airl...@redhat.com With framebuffer handover and multiple GPUs, we get into a position where the fbcon unbinds the vesafb framebuffer for GPU 1, but we still have a radeon framebuffer bound from GPU 0, so we don't unregister the console driver. Then when we tried to bind the new

vt/fbcon binding and handover fixes

I've been working on some issues with the fb handoff between vesafb and KMS on my machine with a dual-gpu card. These 3 patches are the primary result of this, to fix a number of issues where the VT layer and fbcon layers got themselves into a place that they couldn't get out off, having the

[PATCH 3/3] fbcon: fix situation where fbcon gets deinitialised and can't reinit.

From: Dave Airlie airl...@redhat.com Situation as follow: 2 GPUs + vesafb + kms. GPU 1 is primary, vesafb binds to it as fb0 radeon loads GPU 0 loads as fb1 GPU 1 loads, vesafb gets kicked off which causes fb0 to unbind console, which causes the dummy console to rebind. this means fbcon_deinit

[PATCH 1/3] fb: fix overlapping test off-by-one.

From: Dave Airlie airl...@redhat.com On my system with a radeon x2, the first GPU was not overlapping vesa but the test decided it was. Signed-off-by: Dave Airlie airl...@redhat.com --- drivers/video/fbmem.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git

Re: [PATCH 1/3] fb: fix overlapping test off-by-one.

On Die, 2010-12-21 at 11:41 +1000, Dave Airlie wrote: From: Dave Airlie airl...@redhat.com On my system with a radeon x2, the first GPU was not overlapping vesa but the test decided it was. Signed-off-by: Dave Airlie airl...@redhat.com --- drivers/video/fbmem.c |2 +- 1 files