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

[Kevin O'Connor]

On Wed, Oct 19, 2016 at 03:16:48PM +0200, 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:
> >> 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.

I'm not sure what the best approach is.  If it's really just that one
mode, perhaps moving it above 118 and adding a comment is the best
approach.  If you're moving whole blocks around, I'd renumber.

> > 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?

I'm not opposed to the change - just wary of pushing it out into a
release in under a week.

> 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.

That sounds complex.

-Kevin