GNU GRUB - Bugs: bug #50911, i386-pc: ability to probe extra...
You are not allowed to post comments on this tracker with your current authentication level.
bug #50911: i386-pc: ability to probe extra VBE modes
Submitter: | felix <felix_s> | ||
Submitted: | Tue 02 May 2017 08:27:04 AM UTC | ||
Votes: | 1 | ||
Category: | User Interface | Severity: | Major |
Priority: | 5 - Normal | Item Group: | Feature Request |
Status: | None | Privacy: | Public |
Assigned to: | None | Originator Name: | |
Open/Closed: | Open | Release: | Git master |
Release: | Reproducibility: | Every Time | |
Planned Release: | None |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Carbon-Copy List
There is 1 vote so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follows 1 latest change.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2018-08-07 | nickel | Carbon-Copy | - | Added nickel |
Powered by Savane 3.13-02a9.
Corresponding source code
Some VBE implementations may fail to advertise the availability of all supported video modes via the interrupt call 0x10/ax=0x4f00. I used to have a laptop with Intel integrated graphics which did just that: mode 0x17d/0x17e/0x17f set the highest possible resolution on the available display (8bpp, 16bpp, 32bpp respectively), but I only found it out by brute-forcing queries to the interrupt 0x10/ax=0x4f01 call.
I can work this around by patching the video BIOS (that is, unlocking writes to the [0xc0000, 0xcffff] RAM range, patching the modes list and locking the range again), but this is quite ugly, hardware-specific and potentially dangerous. I'd rather would have set a variable in GRUB which would make the vbe module probe modes of my choosing in addition to (or maybe even instead of?) the ones returned from the interrupt 0x10/ax=0x4f00 call.