[SeaBIOS] [PATCH] vgabios: Reorder video modes to work around a Windows bug

[Laszlo Ersek]

On 10/19/16 15:16, Ladi Prosek wrote:
> On Wed, Oct 19, 2016 at 2:23 PM, Kevin O'Connor <kevin at koconnor.net> wrote:
>> On Wed, Oct 19, 2016 at 11:32:41AM +0200, Ladi Prosek wrote:
>>> On Wed, Oct 19, 2016 at 10:06 AM, Ladi Prosek <lprosek at redhat.com> wrote:
>>>> On Wed, Oct 19, 2016 at 1:29 AM, Kevin O'Connor <kevin at koconnor.net> wrote:
>>>>> On Mon, Oct 17, 2016 at 05:53:04PM +0200, Ladi Prosek wrote:
>>>>>> Windows Server 2016 and Windows 10 RS1 come with a bug in its blue screen
>>>>>> of death rendering logic which prevents it from generating crash dumps.
>>>>>>
>>>>>> The bug does not manifest if Windows sees a suitable 32 bpp video mode
>>>>>> before a suitable 24 bpp video mode in the list of modes returned from
>>>>>> vgabios. This commit moves all 32 bpp modes to the front of the list to
>>>>>> make sure that this is always the case.
>>>>>>
>>>>>> Signed-off-by: Ladi Prosek <lprosek at redhat.com>
>>>>>> ---
>>>>>>  vgasrc/bochsvga.c | 39 ++++++++++++++++++++-------------------
>>>>>>  1 file changed, 20 insertions(+), 19 deletions(-)
>>>>>>
>>>>>> diff --git a/vgasrc/bochsvga.c b/vgasrc/bochsvga.c
>>>>>> index ec5d101..c5d1511 100644
>>>>>> --- a/vgasrc/bochsvga.c
>>>>>> +++ b/vgasrc/bochsvga.c
>>>>>> @@ -28,6 +28,25 @@ static struct bochsvga_mode
>>>>>>      u16 mode;
>>>>>>      struct vgamode_s info;
>>>>>>  } bochsvga_modes[] VAR16 = {
>>>>>> +    /* 32 bpp BOCHS modes */
>>>>>> +    { 0x140, { MM_DIRECT, 320,  200,  32, 8, 16, SEG_GRAPH } },
>>>>>> +    { 0x141, { MM_DIRECT, 640,  400,  32, 8, 16, SEG_GRAPH } },
>>>>>> +    { 0x142, { MM_DIRECT, 640,  480,  32, 8, 16, SEG_GRAPH } },
>>>>>> +    { 0x143, { MM_DIRECT, 800,  600,  32, 8, 16, SEG_GRAPH } },
>>>>>> +    { 0x144, { MM_DIRECT, 1024, 768,  32, 8, 16, SEG_GRAPH } },
>>>>>> +    { 0x145, { MM_DIRECT, 1280, 1024, 32, 8, 16, SEG_GRAPH } },
>>>>>> +    { 0x147, { MM_DIRECT, 1600, 1200, 32, 8, 16, SEG_GRAPH } },
>>>>>> +    { 0x14c, { MM_DIRECT, 1152, 864,  32, 8, 16, SEG_GRAPH } },
>>>>>> +    { 0x177, { MM_DIRECT, 1280, 768,  32, 8, 16, SEG_GRAPH } },
>>>>>> +    { 0x17a, { MM_DIRECT, 1280, 800,  32, 8, 16, SEG_GRAPH } },
>>>>>> +    { 0x17d, { MM_DIRECT, 1280, 960,  32, 8, 16, SEG_GRAPH } },
>>>>>> +    { 0x180, { MM_DIRECT, 1440, 900,  32, 8, 16, SEG_GRAPH } },
>>>>>> +    { 0x183, { MM_DIRECT, 1400, 1050, 32, 8, 16, SEG_GRAPH } },
>>>>>> +    { 0x186, { MM_DIRECT, 1680, 1050, 32, 8, 16, SEG_GRAPH } },
>>>>>> +    { 0x189, { MM_DIRECT, 1920, 1200, 32, 8, 16, SEG_GRAPH } },
>>>>>> +    { 0x18c, { MM_DIRECT, 2560, 1600, 32, 8, 16, SEG_GRAPH } },
>>>>>> +    { 0x18f, { MM_DIRECT, 1280, 720,  32, 8, 16, SEG_GRAPH } },
>>>>>> +    { 0x192, { MM_DIRECT, 1920, 1080, 32, 8, 16, SEG_GRAPH } },
>>>>>>      /* standard modes */
>>>>>>      { 0x100, { MM_PACKED, 640,  400,  8,  8, 16, SEG_GRAPH } },
>>>>>>      { 0x101, { MM_PACKED, 640,  480,  8,  8, 16, SEG_GRAPH } },
>>>>>> @@ -56,50 +75,32 @@ static struct bochsvga_mode
>>>>>>      { 0x11D, { MM_DIRECT, 1600, 1200, 15, 8, 16, SEG_GRAPH } },
>>>>>>      { 0x11E, { MM_DIRECT, 1600, 1200, 16, 8, 16, SEG_GRAPH } },
>>>>>>      { 0x11F, { MM_DIRECT, 1600, 1200, 24, 8, 16, SEG_GRAPH } },
>>>>>> -    /* BOCHS modes */
>>>>>> -    { 0x140, { MM_DIRECT, 320,  200,  32, 8, 16, SEG_GRAPH } },
>>>>>> -    { 0x141, { MM_DIRECT, 640,  400,  32, 8, 16, SEG_GRAPH } },
>>>>>> -    { 0x142, { MM_DIRECT, 640,  480,  32, 8, 16, SEG_GRAPH } },
>>>>>> -    { 0x143, { MM_DIRECT, 800,  600,  32, 8, 16, SEG_GRAPH } },
>>>>>> -    { 0x144, { MM_DIRECT, 1024, 768,  32, 8, 16, SEG_GRAPH } },
>>>>>> -    { 0x145, { MM_DIRECT, 1280, 1024, 32, 8, 16, SEG_GRAPH } },
>>>>>> +    /* 8, 15, 16, and 24 bpp BOCHS modes */
>>>>>>      { 0x146, { MM_PACKED, 320,  200,  8,  8, 16, SEG_GRAPH } },
>>>>>> -    { 0x147, { MM_DIRECT, 1600, 1200, 32, 8, 16, SEG_GRAPH } },
>>>>>
>>>>> Thanks.  Instead of moving all of the 32bit modes to the top of the
>>>>> list, can the 32bit modes be kept next to the other modes with the
>>>>> same resolution, just above the 24bpp mode?
>>>>
>>>> Yes, that would work too. As long as 32 bpp come before 24 bpp for the
>>>> same resolution, it will be fine.
>>>>
>>>>> Also, all of the mode numbers above 0x11b are arbitrary, so it would
>>>>> be preferable to renumber the mode numbers as lines are moved.
>>>>
>>>> Will do.
>>>>
>>>>> We were about to make a SeaBIOS release - does this need to go into
>>>>> that release?
>>>>
>>>> It would be highly desired as the problematic Windows builds have
>>>> already RTM'ed.
>>>>
>>>> I'll send a v2 with the changes as suggested above.
>>>
>>> Actually, I spoke too soon. The problematic 24 bpp mode that Windows
>>> picks right now is 118 and that's within the standard range so I can't
>>> move 144 above it and renumber. What would be considered safer,
>>> keeping the same mode numbers or partially renumbering to keep them
>>> monotonically increasing except for the standard range?
>>
>> I wouldn't renumber anything at 0x11B or below - those are defined in
>> the vbe3 spec.  Ordering and the numbering of all the other modes can
>> be changed.  Despite the comment in the source, modes 0x11C-0x11F do
>> not appear to be standard modes.
> 
> Got it. My point is that given how the standard modes are fixed, it's
> not possible to renumber so all modes are in an increasing order. So I
> wonder if renumbering is worth it at all. In fact, the issue would be
> solved just by changing the order of the two 1024x768 modes mentioned
> above: 118 and 144.
> 
>> Thinking on this further, there's a good chance other systems (in
>> addition to Windows) choose the first valid mode found.  So,
>> reordering the 32bit modes above the 24bit modes could cause changes
>> in other systems as well.  So, I think it may be too risky to push
>> this into the pending SeaBIOS release.
> 
> Understood. Would be ok to get it into the next release (assuming this
> is how it gets some test exposure - apologies for not being familiar
> with the SeaBIOS release process) or would you be opposed to the
> change at all?
> 
> Another hypothetical alternative would be to try to find an API
> invocation pattern reasonably unique to Windows that would trigger the
> new behavior, to minimize the risk.

How about a new CONFIG_xxx knob?

Thanks
Laszlo