chrisp
5th April 2006, 11:02 PM
In reply to the comments in xom/lib.c regarding the two instances of the UgaDraw protocol:
The first one is provided by the ConSplitter driver. That's the code responsible for switching between text and graphics mode through the ConsoleControl interface. The TextOut protocol on that handle is also provided by ConSplitter. ConSplitter buffers any output to that protocol, so it can show the full text console when you switch from graphics mode. Other than that, it just forwards requests to the real UgaDraw and TextOut implementations, but only when switched to the appropriate mode.
The second UgaDraw instance is the PCI device handle for the video card. The UgaDraw protocol for it is implemented by the appropriate driver for the hardware (ATI/Intel). The TextOut protocol on that handle is implemented by the GraphicsConsole driver. That driver attaches itself to any UgaDraw protocol that doesn't already have a TextOut and provides text rendering into the framebuffer.
XOM explicitly selects the second UgaDraw instance. That way UGA drawing always works, even with the console in text mode, because you're bypassing ConSplitter and talking directly to the hardware driver. The rest of XOM is written to know when not to draw to the console, but it assumes that XOM is started with graphics mode enabled. When you start XOM with the console in text mode (e.g. from the EFI shell), you'll see the text console with the logo drawn on top.
In short, I think it would be better to use the first UgaDraw instance. Also, XOM could check the current mode of the console through ConsoleControl and adjust its internal state accordingly.
The first one is provided by the ConSplitter driver. That's the code responsible for switching between text and graphics mode through the ConsoleControl interface. The TextOut protocol on that handle is also provided by ConSplitter. ConSplitter buffers any output to that protocol, so it can show the full text console when you switch from graphics mode. Other than that, it just forwards requests to the real UgaDraw and TextOut implementations, but only when switched to the appropriate mode.
The second UgaDraw instance is the PCI device handle for the video card. The UgaDraw protocol for it is implemented by the appropriate driver for the hardware (ATI/Intel). The TextOut protocol on that handle is implemented by the GraphicsConsole driver. That driver attaches itself to any UgaDraw protocol that doesn't already have a TextOut and provides text rendering into the framebuffer.
XOM explicitly selects the second UgaDraw instance. That way UGA drawing always works, even with the console in text mode, because you're bypassing ConSplitter and talking directly to the hardware driver. The rest of XOM is written to know when not to draw to the console, but it assumes that XOM is started with graphics mode enabled. When you start XOM with the console in text mode (e.g. from the EFI shell), you'll see the text console with the logo drawn on top.
In short, I think it would be better to use the first UgaDraw instance. Also, XOM could check the current mode of the console through ConsoleControl and adjust its internal state accordingly.