Re: RFC: Plan for new "hwmatch" command

[Evan Broder]

On Thu, Nov 18, 2010 at 7:52 PM, Brendan Trotter <address@hidden> wrote:
> Hi,
>
> On Thu, Nov 18, 2010 at 3:28 PM, Evan Broder <address@hidden> wrote:
>>   Based on some off-list discussion, I'd like to try a different
>> angle for the Lua patches I submitted a week or two ago. For context,
>> Ubuntu is interested in setting gfxpayload=keep as often as we can in
>> the next release [1]. Since gfxpayload=keep doesn't work with all
>> hardware/driver combinations, we need a way to selectively turn it on,
>> based on a whitelist or blacklist.
>
> I'm curious why setting gfxpayload=keep doesn't work with all
> hardware/driver combinations; and by extension, also wondering if
> Ubuntu is relying on extending an already over-complicated generic
> boot loader (GRUB) to hide symptoms of problems that exist elsewhere
> (rather than fixing the problem/s that exist elsewhere, and maybe not
> setting gfxpayload=keep until those problems are fixed).
>
> Mostly, I'm wondering where GRUB's responsibilities end and OS
> responsibilities start, and how this can effect the GRUB developer's
> ability to maintain GRUB in the upcoming months/years/decades; given
> that it's easy to add features but almost impossible to remove them.

I can certainly try to give a bit more context on Ubuntu's perspective:

In the last release development cycle, we experimented with setting
gfxpayoad=keep. As I recall, we found that some drivers, which are
able to initialize the hardware when it's in text mode, are unable to
initialize the hardware when it's in graphics mode. This results in
the X environment failing to initialize (not sure whether that's
"crash" or just "invisible" - or some of each). I know there were bugs
involving the radeon driver (i.e. open-source ATI) [1], the nvidia
driver (i.e. closed source NVIDIA) [2], and the VMware guest video
driver [3], and those were just the bugs I was able to track down
easily [4].

We're certainly planning to work to get these drivers improved, but it
seems unlikely that we can guarantee that gfxpayload=keep will work
with every piece of hardware running GRUB and Ubuntu - certainly not
by April, if ever. However, it's considered a comparatively
high-priority goal for this release to set gfxpayload=keep when we're
confident that the hardware we're running on supports it. Based on the
impression I've gotten, it's high enough priority that we're willing
to carry Ubuntu-specific patches to make this happen, but of course
it's always preferable to build these sorts of things by coordinating
with upstream.

[1] https://bugs.launchpad.net/bugs/605614
[2] https://bugs.launchpad.net/bugs/612626
[3] https://bugs.launchpad.net/bugs/608429
[4] Yes, the thought has occurred to me that I've just eliminated 2 of
the 3 primary graphics hardware manufacturers with that sentence,
although I'm hoping that the damage is more limited than having to
eliminate entire manufacturers at a time.

- Evan