lubuntu-qa team mailing list archive

[Andy Whitcroft <apw@xxxxxxxxxxxxx>]

On Wed, Oct 10, 2012 at 12:32:01PM +0100, Colin Watson wrote:
> On Mon, Oct 08, 2012 at 08:54:57PM +0100, o jordan wrote:
> > Phil, Colin et al This is an insanely easy bug to fix.  I knocked up a
> > patch for yaboot-installer in a few minutes to show how to solve the
> > problem.  I've attached it to the bug 1040526.  The use of the
> > vt.handoff=7 parameter boots radeon cards into a 16 bit desktop by
> > default.
> 
> vt.handoff=7 is only one part of a much larger complex of code to do
> flicker-free boot, none of the rest of which is present in yaboot, and
> it's quite entitled to assume that the rest of that setup code is there.
> I'd be fairly concerned that this would break something else on a
> chipset-specific basis.  Andy Whitcroft, if you're reading this on
> kernel-team@, what do you think?

The kernel assumes that the framebuffer is initialised and valid when
it starts.  With vt.handoff=N we skip kernel initialisation of the
framebuffer, as we wish to maintain its contents.  The issue comes when
the existing driver we are handing off to assumes the base state and just
initialises the differences, either though poor programming or through
lack of information from the vendor.

Pushing a change like this for everyone on powerpc (especially given
Apple's penchant for having different h/w in every single batch of its
devices) would need some wide testing before we could have any confidence
we are not just trading off one groups of users pain for another.

>From a testing point of view if you are able to change vt to vt1 and back
successfully (the system continues to have a working console (the handoff
data is necessarily lost) then it is realtivly safe to enable this mode.
It only persists until the first chvt, which nominally happens when
plymouth takes over.

If this change can be tested on sufficient representitive h/w I am not
against changing defaults or which modules are enabled.  But it is very
late in the cycle to be changing things for 'everyone'.  Perhaps we can
get a call for testing together on these options and see what feedback
we get.  That should provide sufficient confidence (or not) to satisfy
the SRU team.

Finally from my point of view I am still unclear as to which changes are
needed and which option combinations are available before and after the
kernel changes you propose, if someone could write a clear summary so we
can see what options would need to be considered and testeed that would
help.

-apw