Further discussion of default video quirks

[Matthew Garrett]

27d8bdbe7eb0bc5c375b456fc480d6bb235c0dc4 changes the behaviour of the 
build system to explicitly require --enable-video-default-quirks to be 
passed. I think this is a poor choice for several reasons.

Firstly, at a philosophical level, if hal-info isn't installing a file 
by default then it shouldn't be shipped with hal-info. It might as well 
be kept as a third-party addon.

Secondly, I believe the rational behind this choice to be faulty. 
I've read through the previous discussion thread on this and the stated 
reasons against providing these quirks by default are generally based on 
a misunderstanding of the problem.

The ACPI specification does not require the system firmware to 
reinitialise the graphics hardware in any way. In an ideal world, this 
will be handled by kernel drivers. In Linux, this is now true for Intel 
out of the box, and also true if the nvidia or fglrx binary drivers are 
in use. Full mode reprogramming is almost complete for Radeon.

On systems that do not support kernel-level video reinitialisation, we 
need to do something else to reinitialise the graphics. This is 
generally handled by running a variety of hacks that attempt to use the 
code in the video BIOS to bring the card back to text mode. X is then 
usually able to reprogram graphics mode.

The set of these quirks that each machine needs differs based on the 
combination of the video hardware, video BIOS and system BIOS. It can 
also be affected by the version of the X driver in use and whether any 
sort of kernel framebuffer has been set up. The default behaviour right 
now is for no quirks to be run unless the system has been explicitly 
configured via an entry in an fdi file.

The net result of this is that most machines do not have any quirks set. 
Unless they are using the intel, nvidia or fglrx drivers, there is 
therefore approximately no chance of them resuming correctly.

The problem is that we don't know which quirks a given machine may 
require. The approach taken by the default quirks fdi is to switch on 
most of them. This makes it likely that any necessary quirks are run - 
however, it also makes it possible that one of the quirks will be 
unnecessary and will break resume. However, this doesn't result in any 
increased failure rate. The machine almost certainly failed to resume 
without the quirks - it will also fail to resume with them. While we've 
changed the precise failure mode, we haven't changed the fundamental 
fact that the system doesn't behave usefully. I don't see this as a 
problem.

The absolute theoretical worst case scenario for having these default 
quirks is that they will break systems that would otherwise resume 
successfully. I am unaware of the existence of any hardware where this 
is true. The more common worst case scenario is where a machine that 
failed to resume continues to fail to resume. The more common case is 
that a machine that previously failed to resume will now work.

This is, clearly, a gross hack. So is the entire video quirk framework. 
We're moving towards a future where it doesn't matter, and so arguments 
about the long-term maintainability of this approach aren't terribly 
relevant. The idea is to try to improve the number of machines that we 
support right now.

Unless someone has a documented case where this change will break 
otherwise working hardware, I plan to flip the default to install the 
file and allow a compile time argument to disable it. Distributions that 
want their hardware support to be reduced can pass the argument, but 
everyone else gets sensible behaviour out of the box.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org