On Mon, Mar 12, 2012 at 02:40:14PM +0000, Julian Pidancet wrote:
On Sat, Mar 10, 2012 at 7:01 PM, Kevin O'Connor kevin@koconnor.net wrote:
On Wed, Mar 07, 2012 at 02:41:05AM +0000, Julian Pidancet wrote:
Implements VBE function 15h defined in the VBE/DDC standard. Contains a preliminary implementation for bochsvga which returns a hardcoded EDID with some generic informations.
It seems Xorg refuses to use resolutions higher than 1024x768 if the ROM doesn't return an EDID with timing informations to support it.
I think this work can be completed to add support for the Geode vga ROM, as an I2C interface is probably available to extract the EDID from a real monitor.
I'm okay with the change, but I don't think it should be enabled in the upcoming SeaBIOS v1.7.0 release. Perhaps add a config setting and disable it by default.
Also, the comment on patch 2 seems to indicate it is untested. I think it should be tested before committing.
How about including only the first of this 2-patch set. It only adds the 15h function stub and is a pretty low-risk change.
What's the gain to having the stub present? It will always just return an error code, right?
-Kevin
On Thu, Mar 15, 2012 at 1:32 AM, Kevin O'Connor kevin@koconnor.net wrote:
What's the gain to having the stub present? It will always just return an error code, right?
Right. Forget what I said about the release. It doesn't need to be included in any release. But about the development branch, I know it doesn't make much sense to include something unfinished, but I just thought it would be something good to have in the VBE driver interface. So if someone wants to contribute, the stub is already there and it's just 2 functions to implement.
Also, I'd like to open a discussion on what the right thing to do is about this 15h function for bochs and virtualized devices in general.
- Xorg won't use a resolution higher than 1024x768 unless the ROM provides an EDID which describes monitor timings higher than 1024x768. - The EDID in the patch I proposed exposes 1024x768 as the monitor preferred resolution, which doesn't offer any improvements from what Xorg can already do. - The preferred resolution exposed in the EDID block will correspond to the video mode that will be choosen by default, both by Windows and Xorg.
Is it worth trying to support high resolutions in Xorg ? If yes, then we need to expose a valid EDID block. But what capabilities should the virtual monitor report ? (I mean max resolution, preferred resolution, should they be static, provided by configuration options, or dynamically chosen at run-time).
Anybody has an opinion on this ?
-
Julian Pidancet -
Kevin O'Connor