Bug#741438: Initialize Apple graphics muxer when booting from GRUB

[Colin Watson]

Control: tag -1 patch
# (because I'm not happy with this approach and wouldn't apply a patch
# of this form)

On Sun, Mar 30, 2014 at 10:45:31PM +0200, Thibaut Paumard wrote:
>  - adds support for five variables in grub-mkconfig:
>    GRUB_APPLE_GMUX_INIT
>    GRUB_APPLE_GMUX_SELECT
>    GRUB_APPLE_GMUX_DISPLAY
>    GRUB_APPLE_GMUX_DDC
>    GRUB_APPLE_GMUX_POWER

I should note up front that it would take a very great deal of
persuasion to get me to apply Debian-specific patches that add
additional variables, especially *five* additional variables, to
grub-mkconfig.  The reason for this is that upstream might well later
apply a similar patch but with different names and/or semantics, and I'd
then have to cope with migration.  Furthermore, examination of such
patches often results in ways to do the same kinds of things without the
need for configuration, which is better for everyone.  It would thus be
better to discuss this kind of thing upstream (grub-devel at gnu.org)
rather than in the Debian bug tracker.

Honestly, though, while I understand your motivation for doing this, and
it's fine as a local starting point for getting the system going, I
think this ought to be done quite differently, and not at the
configuration layer at all.  This is not something people actually
*want* to configure once it works; and the "outb" command is all very
well for local hacks, but it's not a sensible framework for real
hardware enablement, and we shouldn't be cluttering up configuration
files that people may actually need to read with this kind of thing for
various systems.  Entrenching this in a configuration file in such a way
that we'll need to keep supporting these variable names in the long term
is really not a good plan at all.  Instead, GRUB's video layer should
automatically detect whether the system needs this sort of thing (for
instance, by enumerating PCI devices, which GRUB can already do) and
behave appropriately.

As for the kernel command line changes, again, while it's often useful
to set this kind of thing locally, it's not a long-term sensible way to
do things.  The correct approach is to get the kernel to do the right
thing out of the box without the need for command-line arguments to tell
it what to do.  Putting this sort of thing in the GRUB packaging often
works out to be a bad idea because it's very easy for these options to
become wrong with later kernel versions, and then we're stuck
maintaining a nightmare configuration forest.

>  - fills some default in /etc/default/grub.

I have Debian-specific reasons to be reluctant to apply any further
changes to this file: it results in conffile prompts for a large number
of users, which I'd like to keep to an absolute minimum.  I'm
specifically uncomfortable with the approach your patch takes of adding
non-trivial shell code there; I think it quite likely that there are
tools around that try to parse and/or edit /etc/default/grub on the
assumption that it only contains trivial assignments.

Sorry,

-- 
Colin Watson                                       [cjwatson at debian.org]