Please make X fallback to vesa if the card driver doesn't work.

[Jeff Bailey]

Please cause X to fallback to a minimal working graphic state if it otherwise
fails. Right now, a new end user with spiffy new hardware may find themselves
staring at a screen of text rather than an ugly graphics setup. Since all of
our bug reporting information is only accessible once the user has logged in,
the path to getting logged in must be made extremely robust.

This should probably be a spec. I think it's probably also really important to
do for Dapper, given the 3 year target timeframe.

Characteristics that I think would be ideal:

* It should attempt the correct setup and fallback to vesa without touching a
config file. This way updates will make the system boot correctly.

* It should use the notification applet once to indicate that the driver display
isn't in an ideal configuration, and that perhaps they should troubleshoot it.

* Some sort of detailed log should be placed somewhere so that when a support
professional comes along, there's something that (s)he* can do about it.

Tks,
Jeff Bailey

http://lists.ubuntu.com/archives/sounder/2005-March/001583.html: http://lists.ubuntu.com/archives/sounder/2005-March/001583.html

[Matt Zimmerman (mdz)]

Mark has asked for this functionality in Dapper. I know that the algorithm will fall back to selecting the vesa driver if we don't recognize the card, but there are some problems:

- I think it doesn't work unless the user passes a vga= kernel parameter (confirm?)

- We won't fall back for unknown cards from known vendors (the PCI vendor fallbacks in discover)

I don't know what to do about the former. For the latter, we should test whether the X server starts correctly, and fall back only if it does not work.

I realize that this is likely to be an intrusive feature to implement at this late stage, but please investigate thoroughly and see what we may be able to do with minimal risk.

[Jeff Bailey (jbailey)]

In the case which caused me to report this originally, I did not have to specify vga= on the command line to have vesa work. I think (but don't know for certain) that I have never had to. vesa modes are reported separately from vga framebuffer state.

Tks,
Jeff Bailey

[Mark Shuttleworth (sabdfl)]

I know that it's late to be asking for new features. I'm having kittens
about the fact that we are going to ship up to 8 million Dapper CD's,
all of them live CD's, and during the course of the lifespan of Dapper
the hardware on which it is being installed is going to change
substantially. It's a bit of an Achilles Heel if the Live CD fails to
bring X up on an increasing percentage of the machines where it gets tested.

I don't mind if there is a "conservative" mode which is slow but
reliable, as long as its easily selected for those for whom the primary
default pathways fail. A better option would be to maintain control of
the process, and fall back to give the user some choice of options only
if we need to do that.

The options should include the binary video drivers, the free drivers,
and then the VESA universal mode.

[Fabio Massimo Di Nitto (fabbione)]

I am not sure how to quote in malone but i understand the issue and
I see only two problems:

1) we might have to use a boot option to explicitly override the autodetection
to vesa

2) vesa might not work either.

the problems of detecting if X started properly is very hairy because it might starts but hang the entire machine.

For Matt:

There is no need to send the vga= option to the kernel, that's only for framebuffer.

The fall back is a catch all. Either we attempt to load the driver or we don't.
Historically it did work better to load the driver and that's why I am suggesting to consider the boot option as in forcevesa or something.

Fabio

[Mark Shuttleworth (sabdfl)]

Fabio Massimo Di Nitto wrote:
> 2) vesa might not work either.
>
Is there a slow-and-simple-but-most-likely-to-come-up option?

Mark

[Fabio Massimo Di Nitto (fabbione)]

> Is there a slow-and-simple-but-most-likely-to-come-up option?

No more slow and simple than vesa.

The problem comes from bad hw that is not fully vesa compliant, they claim to be but the only thing that really works with them is the proper (and fixed/patched) driver.

We can get very close to slow-and-etc. forcing vesa. That's the best we can do against broken hw.

Fabio

[Fabio Massimo Di Nitto (fabbione)]

Colin, please add the option, to the various i386/amd64 desktop-live cd's, to boot with X failsafe mode using as kernel cmd line "xforcevesa".

Thanks
Fabio

[Fabio Massimo Di Nitto (fabbione)]

It is now possible to force X to use a vesa driver using either XFORCEVESA envvar or passing xforcevesa as bootoption.

Fabio

[Colin Watson (cjwatson)]

2006-04-07 12:16:43 GMT Colin Watson <email address hidden> patch-302

    Summary:
      add xforcevesa boot option to amd64 and i386 (closes: Malone #27020)
    Revision:
      debian-cd--ubuntu--0--patch-302

    modified files:
     tools/boot/dapper/boot-amd64 tools/boot/dapper/boot-i386

[Colin Watson (cjwatson)]

I also need to change gfxboot-theme-ubuntu to enable translations of these boot options.

[Colin Watson (cjwatson)]

gfxboot-theme-ubuntu (0.1.18) dapper; urgency=low

  * Fix parsing of gfxboot-foreground keyword.
  * Add translations for new xforcevesa boot options (closes: Malone
    #27020).
  * Update language names from localechooser 0.27ubuntu13, adding Thai.
  * Fix comments in .po/.pot files: maintainer comments should start with
    "#.", not "# ".
  * Update translations from Rosetta: Breton, German, Greek, Spanish,
    Finnish, French, Galician, Hungarian, Italian, Lithuanian, Norwegian
    Bokmål, Polish, Portuguese, Portuguese (Brazil), Romanian, Russian,
    Slovak, Swedish, Chinese (China), Chinese (Taiwan).
  * Update font to add newly-required characters.
  * Fix memory handling in isolinux.cfg parser: take copies of all labels,
    and free a pointer to the start of the file, not the end (closes: Malone
    #34592).

 -- Colin Watson <email address hidden> Fri, 7 Apr 2006 18:02:33 +0100

[Jeff Bailey (jbailey)]

Spoke to Fabio today. Noting my understanding here as the submitter.

1) We can expect most installs to be done through the LiveCD installer. The LiveCD has a usual detection mode, and a safe mode fallback. The safe fallback is a vesa mode, and if the install is done with that, then the installed system will use the vesa driver.

2) For a system installed either through the regular install CD, or a system that is upgraded there is no way to know before the system boots into X whether it will be successful. Varying display managers (of which we now have at least 3 in main) would each need to be tweaked in order to cope with this. The solution here is to reboot into single user mode, and X will provide a script which reconfigures X to use the vesa driver. This can then be documented on the wiki, in the knowledgebase, and provides a tool that is easy for tech support to use.

I think that this is a solution that will work for this release.

Tks,
Jeff Bailey

[Matt Zimmerman (mdz)]

Thanks, Fabio and Colin, for your prompt attention to this issue.

On Fri, Apr 07, 2006 at 06:28:17PM -0000, Jeff Bailey wrote:
> 2) For a system installed either through the regular install CD, or a
> system that is upgraded there is no way to know before the system boots
> into X whether it will be successful. Varying display managers (of which
> we now have at least 3 in main) would each need to be tweaked in order to
> cope with this. The solution here is to reboot into single user mode, and
> X will provide a script which reconfigures X to use the vesa driver. This
> can then be documented on the wiki, in the knowledgebase, and provides a
> tool that is easy for tech support to use.

It should be possible to test-start the X server with -probeonly and try a
fallback to vesa if that fails. That would catch the most common cases,
e.g. where we currently use ati or nv for devices which actually only work
with vesa or the binary drivers (due to the discover1 fallbacks).

This should help in both the live CD and the install CD cases, and be
transparent to the user.

Fabio, what do you think?

--
 - mdz

[Matt Zimmerman (mdz)]

On Fri, Apr 07, 2006 at 03:24:02PM -0700, Matt Zimmerman wrote:
> Fabio, what do you think?

I see that in an earlier comment you expressed hesitation with this approach
because it might hang the machine. We do already do this anyway in some
cases via xresprobe, and if starting X is going to hang the machine, we'd
only hang earlier when we would have hung anyway.

I think this would be a good complement to the boot option.

--
 - mdz

[Fabio Massimo Di Nitto (fabbione)]

> It should be possible to test-start the X server with -probeonly and try a
> fallback to vesa if that fails. That would catch the most common cases,
> e.g. where we currently use ati or nv for devices which actually only work
> with vesa or the binary drivers (due to the discover1 fallbacks).

> This should help in both the live CD and the install CD cases, and be
> transparent to the user.

> Fabio, what do you think?

I have been down this road somehow and it requires a lot of changes around that we can't efford to do at this point in time of the release.

To get it right we will need:

- half rewrite of postinst to write both normal and failsafe config. No changing the driver only to vesa is not enough.
- put either a script somewhere that will try to start X and test it or use login managers fallback (afaik only gdm has it)
- kill hutterly annoying failsafe messages from the login managers

No it's an amount of changes (+ tests etc) that starts to be too scary. The failback as it is, is more than enough to cover everybody. Also for total newbie that don't know how to run a script from single user, they can just add the boot option to the install CD and it will work.

Fabio

[Matt Zimmerman (mdz)]

On Sat, Apr 08, 2006 at 06:30:56AM -0000, Fabio Massimo Di Nitto wrote:
> I have been down this road somehow and it requires a lot of changes around
> that we can't efford to do at this point in time of the release.
>
> To get it right we will need:
>
> - half rewrite of postinst to write both normal and failsafe config. No changing the driver only to vesa is not enough.
> - put either a script somewhere that will try to start X and test it or use login managers fallback (afaik only gdm has it)
> - kill hutterly annoying failsafe messages from the login managers

OK, let's revisit this at a later date then. Thanks.

--
 - mdz