Hi Gerd,
I was curious to see what the "sercon" stuff would look like in
SeaVGABIOS instead of in SeaBIOS. So, I put together a quick
prototype. The code is also at:
https://github.com/KevinOConnor/seabios/tree/testing
This is just a proof-of-concept thing - I didn't implement any of the
useful features you have in your series. Specifically, it doesn't
unclutter the serial output, doesn't implement cp437 translations, and
doesn't handle multi-byte input. It does does have basic input,
output, and split-output handling though.
I'm not sure if this is better than a SeaBIOS implementation. I
suspect it will be easier to handle vga quirks this way. However,
handling exotic serial outputs (eg, mmio and usb based) would be
better suited in SeaBIOS.
Thoughts?
-Kevin
Kevin O'Connor (3):
sercon: Initial support for VGA emulation over serial port
sercon: Add basic keyboard input support
sercon: Support "split output" mode
Makefile | 2 +-
vgasrc/Kconfig | 6 +
vgasrc/sercon.c | 356 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
vgasrc/vgabios.c | 15 ++-
vgasrc/vgabios.h | 5 +
vgasrc/vgaentry.S | 7 ++
vgasrc/vgahw.h | 72 ++++++++++-
vgasrc/vgainit.c | 12 +-
vgasrc/vgautil.h | 24 ++++
9 files changed, 482 insertions(+), 17 deletions(-)
create mode 100644 vgasrc/sercon.c
--
2.5.5
Hi Stefan,
I dusted off some TPM patches I had worked on earlier in the year.
Mostly just code movement, but the last patch I think helps simplify
tpm_build_and_send_cmd().
Do they look okay to you?
-Kevin
Kevin O'Connor (6):
tpm: Add comment banners to tcg.c separating major parts of spec
tpm: Don't call tpm_set_failure() from tpm12_get_capability()
tpm: Move code around in tcgbios.c to keep like code together
acpi: Generalize find_fadt() and find_tcpa_by_rsdp() into
find_acpi_table()
tpm: Don't call tpm_build_and_send_cmd() from tpm20_stirrandom()
tpm: Rework tpm_build_and_send_cmd() into tpm_simple_cmd()
src/fw/biostables.c | 18 +-
src/std/acpi.h | 7 -
src/std/tcg.h | 199 +++++++++--------
src/tcgbios.c | 611 ++++++++++++++++++++++------------------------------
src/util.h | 1 +
5 files changed, 369 insertions(+), 467 deletions(-)
--
2.5.5
The 1.10.0 version of SeaBIOS has now been released. For more
information on the release, please see:
http://seabios.org/Releases
New in this release:
* Initial support for Trusted Platform Module (TPM) version 2.0
* Several USB XHCI timing fixes on real hardware
* Support for "LSI MPT Fusion" scsi controllers on QEMU
* Support for virtio devices mapped above 4GB
* Several bug fixes and code cleanups
For information on obtaining SeaBIOS, please see:
http://seabios.org/Download
===== git shortlog -n rel-1.9.0..rel-1.10.0 =====
Kevin O'Connor (124):
usb: Allow configuration of sigatt time (in etc/usb-time-sigatt)
xhci: Check for device disconnects during USB2 reset polling
sdcard: Only enable error_irq_enable for bits defined in SDHCI v1 spec
sdcard: fix typo causing 32bit write to 16bit block_size field
sdcard: Enable extra debugging on sdcard_waitw() timeout
acpi_extract: Move main code to new function main()
acpi_extract: Make the generated .hex files more human readable
acpi_extract: Don't generate unused (and empty) q35-acpi-dsdt.hex file
acpi: Don't build SSDT files on every build; store them in git
acpi: Remove build check for iasl
tpm: Move standard definitions from tcgbios.h to new file std/tcg.h
util.h: Minor - HaveRunPost is in misc.c not resume.c
tpm: Add "static" declaration to functions not used outside tcgbios.c
tpm: Move code around in tcgbios.c
tpm: Move error recovery from tpm_extend_acpi_log() to only caller
tpm: Open code tpm_ipl() into callers
tpm: Change tpm_add_measurement() to tpm_add_action()
tpm: Move tpm_add_bootdevice() into callers
tpm: Move tpm_start_option_rom_scan() and tpm_calling_int19h() into callers
tpm: pcpes->event is a variable length array
tpm: Don't pass entry_count around in parameters to/from tpm_extend_acpi_log()
tpm: There is no need to pass pcrindex to hash_log_extend_event()
tpm: Perform hashing separately from logging
tpm: There is no need to pass event_length to hash/extend functions
tpm: Avoid scatter-gather copying in build_and_send_cmd()
tpm: Don't implement scatter-gather in transmit()
tpm: Merge tpm_log_event() and tpm_extend_acpi_log()
tpm: Merge tpm_log_extend_event() and tpm_extend(); extend before logging
xhci: Wait for port enable even for USB3 devices
xhci: Improve port status change debugging
xhci: Disable slot on failed set_address command
nmi: Don't try to switch onto extra stack in NMI handler
scsi: Do not call printf() from scsi_is_ready()
block: Report drive->sectors using "%u" instead of "%d"
tpm: Add banner separating the TCG bios interface code from TCG menu code
tpm: Avoid macro expansion of tpm request / response structs
tpm: Simplify hardware probe and detection checks
tpm: Add wrapper function tpmhw_set_timeouts()
tpm: Move TPM hardware functions from tcgbios.c to hw/tpm_drivers.c
tpm: Rework TPM interface shutdown support
tpm: Simplify tcpa probe
tpm: Introduce tpm_get_capability() helper function
tpm: Eliminate response buffer parameter from build_and_send_cmd()
tpm: Don't return a status from external bios measurement functions
tpm: No need to check the return status of measurements
tpm: Don't call tpm_set_failure() from tpm_log_extend_event()
tpm: Don't use 16bit BIOS return codes in build_and_send_cmd()
tpm: Don't use 16bit BIOS return codes in tpm_log_event()
tpm: Don't use 16bit BIOS return codes in tpmhw_* functions
tpm: Don't use 16bit BIOS return codes in TPM menu functions
usb: Remove usbdev->slotid field
coreboot: Check for unaligned cbfs header
resume: Make KVM soft reboot loop detection more flexible
post: Always set HaveRunPost prior to setting any other global variable
kbd: Don't treat scancode and asciicode as separate values
kbd: Refactor capslock and numlock handling
ehci: Only delay UHCI/OHCI port scan until after EHCI setup completes
usb: Eliminate USB controller setup thread
pci: Add helper functions for internal driver BAR handling
ahci: Convert to new PCI BAR helper functions
ata: Convert to new PCI BAR helper functions
esp-scsi: Convert to new PCI BAR helper functions
lsi-scsi: Convert to new PCI BAR helper functions
megasas: Convert to new PCI BAR helper functions
pvscsi: Convert to new PCI BAR helper functions
sdcard: Convert to new PCI BAR helper functions
ehci: Convert to new PCI BAR helper functions
ohci: Convert to new PCI BAR helper functions
uhci: Convert to new PCI BAR helper functions
xhci: Convert to new PCI BAR helper functions
virtio: Convert to new PCI BAR helper functions
pci: Consistently set pci->have_drivers for devices with internal drivers
pci: Implement '%pP' printf handler for 'struct pci_device' pointers
pci: Move code in pci.c that is specific to pciinit.c to pciinit.c
pci: Split low-level pci code from higher-level 'struct pci_device' code
scsi: Always use MAXDESCSIZE when building drive description
block: Move drive setup to new function block_setup()
tpm: Unify tpm_fill_hash()/tpm_log_extend_event() and use in BIOS interface
docs: Note release date of 1.9.1
build: fix .text section address alignment
tpm: Write logs in TPM 2 format
mpt-scsi: Declare 'int i' outside of for loop for older compilers
block: Move send_disk_op() from block.c to disk.c
disk: Avoid stack_hop() path if already on the extra stack
optionroms: Drop support for CONFIG_OPTIONROMS_DEPLOYED
shadow: Batch PCI config writes
virtio: Use threads when scanning for virtio devices
scsi: Launch a thread when scanning for drives in the scsi drivers
docs: Note release date of 1.9.2
usb-xhci: Remove unused const variables
tcgbios: Remove unused const variable
vgabios: Remove special case of dh==0xff in handle_1013()
vgabios: Don't check for special case of page==0xff on external calls
vgabios: Simplify set_cursor_pos()
docs: Note release date of 1.9.3
vgabios: Simplify scroll logic
blockcmd: CMD_SCSI op is only used in 32bit mode
swcursor: Move swcursor code from vgafb.c to new file swcursor.c
swcursor: Concentrate swcursor logic in swcursor.c
vgafb: Move header definitions from vgabios.h to new file vgafb.h
vgainit: Move video param setup to stdvga_build_video_param()
vgautil: Add new header file with misc function and variable definitions
vgautil: Move generic definitions from stdvga.h to vgautil.h
vgautil: Move definitions from cbvga.h and clext.h to vgautil.h
version: Update header files now that version.c is not auto generated
checkstack: Handle conditional checks at start of functions
tpm: Append to TPM2 log the hashes used for PCR extension
ps2: Remove stale check for timeout warning on reset
pic: The default hardware interrupt handlers should not take a parameter
kbd: Implement 101-key keyboard keycode mapping
kbd: Implement extended keycode mappings for keypad-enter and keypad-/
kbd: Suppress keys without mappings
kbd: Merge bda->kbd_flag0 and bda->kbd_flag1
kbd: Extract out shift flag setting into new function
kbd: Move checking for special keys in __process_keys() into switch
kbd: Ignore fake shift keys
usb-hid: Generate Ctrl+Break and Alt+SysReq keys
kbd: Generate interrupt events for SysReq, PrtScr, and Break
post: Map int 0x05 to entry point
kbd: Move extended and release events out of special key detection switch
build: Be sure to also include out/*.d in Makefile
smp: consolidate CPU APIC ID detection and accounting
build: Add -fno-pie to the gcc flags when available
docs: Note v1.10.0 release
Stefan Berger (34):
tpm: Temporarily deactivate the TPM in case of failure
tpm: Refactor function building TPM commands
tpm: Refactor the parameters being passed to tpm_extend_acpi_log
tpm: Refactor hash_log_event BIOS interface function
tpm: Refactor hash_log_extend_event
tpm: fix compiler warning with older gcc versions
tpm: Drop code using the TPM for sha1
tpm: Set timeouts and durations to microsecond values
tpm: Cache all log related pointers in tpm_state
tpm: Refactor pass_through_to_tpm
tpm: Rename remaining interrupt functions
tpm: Remove check for working TPM from TPM interrupt handler
tpm: Check length parameter of the array
tpm: Add a menu for TPM configuration
tpm: Copy digest into HashLogExentEvent response
tpm: Move assert_physical_presence and dependencies
tpm: Add support for harware physical presence
tpm: Rework the assertion of physical presence
tpm: Remove usage of PP_CMD_ENABLE from all but one place
tpm: Do not set TPM in failure mode if menu command fails
tpm: Extend TPM TIS with TPM 2 support.
tpm: Factor out tpm_extend
tpm: Prepare code for TPM 2 functions
tpm: Implement tpm20_startup and tpm20_s3_resume
tpm: Implement tpm20_set_timeouts
tpm: Implement tpm20_prepboot
tpm: Implement tpm20_extend
tpm: Implement tpm20_menu
tpm: Implement TPM 2's tpm_set_failure part
tpm: Filter TPM commands in passthrough API
tpm: Retrieve the PCR Bank configuration
tpm: Restructure tpm20_extend to use buffer and take hash as parameter
tpm: Refactor tpml_digest_values_sha1 structure
tpm: Extend tpm20_extend to support extending to multiple PCR banks
Gerd Hoffmann (4):
ahci: set transfer mode according to the capabilities of connected drive
virtio: uninline _vp_{read,write}
virtio: pci cfg access
virtio: fix virtio-pci
Igor Mammedov (3):
paravirt: disable legacy bios tables in case of more than 255 CPUs
add helpers to read etc/boot-cpus at resume time
support booting with more than 255 CPUs
Dana Rubin (2):
pvscsi: Fix incorrect arguments order in call to memalign_low
pvscsi: Use high memory for rings
Marcel Apfelbaum (2):
fw/pci: do not automatically allocate IO region for PCIe bridges
fw/pci: add Q35 S3 support
Alex Williamson (1):
fw/pci: Add support for mapping Intel IGD via QEMU
Cao jin (1):
Fix comment typo
Cole Robinson (1):
biostables: Support SMBIOS 2.6+ UUID format
Don Slutz (1):
Support for booting from LSI Logic LSI53C1030, SAS1068, SAS1068e
Haozhong Zhang (1):
fw/msr_feature_control: add support to set MSR_IA32_FEATURE_CONTROL
Matt DeVillier (1):
sdcard: skip detection of PCI sdhci controllers if etc/sdcard used
Paolo Bonzini (1):
smp: restore MSRs on S3 resume
Piotr Król (1):
docs: fix various typos and inconsistency
Roger Pau Monne (1):
build: fix typo in buildversion.py
Zheng Bao (1):
splash: Skip the RGB555 mode
Dear SeaBIOS folks,
just a note, that due to a regression in GCC 6 in Debian Sid/unstable
[1] the latest master branch [2] does not build.
```
$ make
Build Kconfig config file
Compile checking out/src/misc.o
Compile checking out/src/stacks.o
src/stacks.c: Assembler messages:
src/stacks.c:567: Error: found '(', expected: ')'
src/stacks.c:567: Error: junk `(%ebp))' after expression
src/stacks.c:568: Warning: indirect call without `*'
Makefile:133: die Regel für Ziel „out/src/stacks.o“ scheiterte
make: *** [out/src/stacks.o] Fehler 1
```
It builds fine with gcc-4.9 and gcc-5.
```
$ make CC=gcc-4.9 -j
$ make CC=gcc-5 -j
```
There is gcc-6 6.2.0-9 out already [3], but it’s not available over the
mirrors yet.
Thanks,
Paul
[1] http://metadata.ftp-master.debian.org/changelogs/main/g/gcc-6/gcc-6_6.2.0...
gcc (Debian 6.2.0-7) 6.2.0 20161018
[2] commit 00b0402 (docs: fix various typos and inconsistency)
[3] http://metadata.ftp-master.debian.org/changelogs/main/g/gcc-6/gcc-6_6.2.0...
Changelog since:
v4:
* (Kevin) drop
[PATCH v4 3/5] error out if present cpus count changed during SMP bringup
and resolve conflicts caused by this in followup patches
v3:
* don't move CPU counting around, leave it as is and
consolidate apic_id accounting only
* add and use qemu_*_present_cpus_count() helpers to init/get boot
cpus count at boot time and only qemu_get_present_cpus_count()
at resume time
* fix S3 wakeup stuck in resume vector
* If cpu were hotplugged during smp_scan, report it to user
instead of silently hanging if it came online while smp_scan()
waits for APs
v2:
* rebase on top of current master /smp_scan() changes/
v1:
* s/count_cpu/apic_id_init/
* merge handle_x2apic() into apic_id_init()
RFC:
* move out max-cpus check out of mptable_setup()
* factor out CPU counting/apic ID detection in separate function
* return back accidentially deleted debug message with APIC ID
* drop unused code in smp_setup()
According to SDM, if CPUs have APIC ID more than 254
firmware should pass control to OS in x2APIC mode.
This series adds x2APIC bootstrap initialization.
QEMU side of x2APIC support:
"[PATCH v3 00/13] pc: q35: x2APIC support in kvm_apic mode"
https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg02865.html
Note:
S3 wakeup works as expected if linux guest is running with IRQ remapping enabled.
However it seems that kernel is buggy with IRQ remapping disabled as kernel
disables CPUs with APIC ID > 254 and on resume from S3 hangs somewere after
getting control from Seabios.
Cc: rkrcmar(a)redhat.com
Cc: mst(a)redhat.com
Cc: jan.kiszka(a)web.de
Cc: kraxel(a)redhat.com
Cc: pbonzini(a)redhat.com
Cc: lersek(a)redhat.com
Cc: kraxel(a)redhat.com
Igor Mammedov (3):
paravirt: disable legacy bios tables in case of more than 255 CPUs
add helpers to read etc/boot-cpus at resume time
support booting with more than 255 CPUs
Kevin O'Connor (1):
smp: consolidate CPU APIC ID detection and accounting
src/fw/paravirt.h | 3 +++
src/x86.h | 1 +
src/fw/paravirt.c | 44 ++++++++++++++++++++++++++++++++++++++++++--
src/fw/smp.c | 52 +++++++++++++++++++++++++++++++++++++---------------
4 files changed, 83 insertions(+), 17 deletions(-)
--
2.7.4
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(a)redhat.com> wrote:
> > On Wed, Oct 19, 2016 at 1:29 AM, Kevin O'Connor <kevin(a)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(a)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.
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.
-Kevin
On 10/19/16 15:16, Ladi Prosek wrote:
> On Wed, Oct 19, 2016 at 2:23 PM, Kevin O'Connor <kevin(a)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(a)redhat.com> wrote:
>>>> On Wed, Oct 19, 2016 at 1:29 AM, Kevin O'Connor <kevin(a)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(a)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
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(a)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
