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 ?