PowerPC bugs

Sun Oct 7 11:38:05 UTC 2012

> 
> On Thu, Oct 04, 2012 at 01:53:32PM +0100, o jordan wrote:
> > Is it too late to get some PowerPC changes into the yaboot options on
> > the live/desktop ISOs?
> >  
> > I have an idea to build back in the legacy nvidia framebuffers into
> > the PowerPC kernel.  Whilst this is a backwards step in many respects,
> > it is the only way (I can think of) to get over the 16 colour
> > limitation of the openfirmware framebuffer.  Currently if you turn off
> > kernel modesetting with nouveau (and this it seems is a necessity now
> > for many cards of some vintage) you are thrown into a desktop with
> > only 16 colours on PowerPC and this is a largely unusuable desktop.
> >  
> > As this kernel change will disable KMS (which we don't want to do for
> > every nvidia card) the boot options need updating so that the legacy
> > framebuffers are turned off by default:
> >  
> > video=radeonfb:off video=rivafb:off video=nvidiafb:off  
> > Since you cannot easily remove default yaboot parameters a new
> > 'failsafe' option would need to be created on the desktop ISO without
> > these parameters.  This could replace the 'nosplash' option.  The new
> > yaboot parameters would be: nomodeset vt.handoff=7 I know you don't
> > think vt.handoff=7 makes any sense with yaboot, but it does actually
> > boot you into a higher colour depth than you would without it.  This
> > solves the problem of the installer windows not appearing in 8 bit
> > pseudo colour. I think I can create a patch for yaboot-installer (to
> > also introduce a failsafe option on an installed system), but I have
> > no clue what files are involved in the creation of the ISOs.  If you
> > can point me in the right direction then I can take (a rather
> > uneducated) look at them and see if I can come up with the necessary
> > changes myself. Of course this all depends on getting the PowerPC
> > kernel changed, something that I have struggled to do in the past.
> > Like yourself they are very cautious about changes.  I would need help
> > from somebody within Canonical to support the kernel change. These
> > changes would not improve the out-of-the box everything working 100%
> > on the first boot support of the PowerPC port (that can only come from
> > the kernel/radeon/nouveau developers), but the creation of a failsafe
> > mode would make the radeon and nvidia user experience much better.
> 
> To be honest, as I think I said before: I'm not going to touch these
> options at all without review from the kernel and X teams (CCed).  If
> they say it's necessary, then sure; but I would rather that somebody
> first checked whether this is a consequence of a bug we can fix, because
> it's always better for the software to work by default than to require
> boot parameters.
> 
> Regards,
> 
> -- 
> Colin Watson                                       [cjwatson at ubuntu.com]

Hi Colin,

I am keen too to get proper fixes and that is why bugs have been raised against all the appropriate packages.  However, a lot of the problems are long term ones, for example https://bugs.launchpad.net/ubuntu/+source/linux/+bug/725580 .  Some though are recent e.g. https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1058641 .  The problems are not PowerPC specific, but the difference is non-PowerPC hardware has better fallback options, for example the vesa or proprietary drivers.  Neither of these things are available on PowerPC.  My proposal is just to create a useable fallback option, something that isn't automatically available at the moment on PowerPC for some nouveau users.

I'm coming from this as a radeon user, which as you know has its problems in 12.10 - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1040526 .  As I've explained before, the current PowerPC kernel setup (radeonfb built in) doesn't allow radeon KMS to function and there is no getting around that other than disabling radeonfb.  I've tried to have this confirmed for you in this bug https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1058753 .

The obvious solution is to remove radeonfb from the kernel.  If we do this then radeon KMS will be used by default.  However, if for whatever reason KMS doesn't work for a user and they have to use 'nomodeset' then the fallback will be the fbdev driver with the openfirmare framebuffer.  This is currently the case for nouveau users.  The openfirmware framebuffer in many cases is limited to just 16 colours.  This is demonstrated in pictures linked on this nouveau bug report https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/1061790 .  The only way to get more colours (and a useable desktop) is to use a legacy framebuffer - radeonfb, but we've removed this to enable KMS.  It is a classic catch 22.

That is why I suggest the best option for radeon maybe to keep radeonfb built in and just change the boot parameters/options.  If you're creating a fallback option for radeon, then you might as well do the same for nouveau (which would need rivafb and nvidiafb building back in). 

To be honest I was happy just to have radeonfb removed since I don't like PowerPC having a different setup to the other architectures.  I see the 16 colour desktop just a limitation of the PowerPC hardware and if users want radeonfb then they can follow the instructions in the PowerPC FAQ to use it as a module on an installed system.  However, lubuntu-qa were talking of failing the live/desktop ISO over the lack of a useable fallback option.  The alternate was also in danger due to this bug with lightdm https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1044180 .  I don't know if they intend to continue to do this (I don't agree with it), but if they do then we should come up with better fallback option.

On previous versions of *Ubuntu I believe you could still use ubiquity in 16 colours.  Now it doesn't even work in 256 colours https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1040544 .  Presumably the problem is in whatever widgety thing it uses.  I think you could replicate the problem on non-PowerPC hardware by forcing a 8 bit colour depth. When I disable KMS (nomodeset) and use radeonfb I have a 16 bit framebuffer on tty1, but all the others are 8 bit (including X/fbdev on tty7).  Whatever wizardry vt.handoff=7 does, it makes tty7 the 16 bit framebuffer.  There could indeed be a better way to make X start in a higher colour depth automatically, perhaps this is something ubuntu-x could shed some light on?  As far as I know fbdev takes its colour depth from the framebuffer.  vt.handoff=7 is the part I am least sure about.  When used without a splash screen it gives a horrible corrupt screen early in the boot sequence.  So maybe it shouldn't replace the 'nosplash' option?  I'm only adding vt.handoff=7 to get over the problem with ubiquity, lightdm and network manager that nolonger want to function in an 8 bit depth. Like I said, up until bug 1058641 I was happy for radeonfb just to be removed.  This is even though I was responsible for having it put back (along with aty128) into 12.04 - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/949288 .  Incidentally, can I ask the kernel people was there a reason why CONFIG_FB_ATY was missed off.....something I probably should of done that at the time?!  Sorry!  I don't know anything about Mach64/Rage cards, particularly their current state in 12.10....will they use fbdev too now?  Can ubuntu-x confirm? Keeping the legacy framebuffers radeonfb, rivafb, nvidiafb in is messy with all the boot parameter changes, I don't particularly like it, but if it is the only way to satisfy lubuntu-qa then it should be done I suppose.  It would be good to get the qa perspecitive on this.  Time is running out for 12.10 and lubuntu-qa need to decide what they want.  Last time I checked debian wheezy (a couple of months ago) they had radeonfb, rivafb and nvidiafb still built in on PowerPC.  I don't know how they get over this disabling KMS though?  They must expect their users to add boot parameters, for example video=ofonly? I know you must be very busy at this time, so thanks for reading what has turned out to be another long email! Regards Adam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20121007/0fdd7ae1/attachment.html>