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
On Wed, Oct 19, 2016 at 11:32:41AM +0200, Ladi
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.
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.