Hi,
Since one of my recent video driver loading changes, livecd video is vga mode. The reson is:
When installing bootcd, there will be only 1 video driver installed: based on 1st stage selection, either vbe or vga will be installed the other one is deactivated (start mode = manual). When installing a 3rd party driver, that one used to be installed and loaded prior to VBE and thus became Device/Video0, which win32k happily used as primary adapter. This behaviour changed with ACPI hal and VBE is loaded first, resulting is non functional VBox driver. I fixed this, by having win32k decide which driver to use, by looking if its a vga compatible driver and use that one only as fallback, if no other is present. additionally the VBE was marked as VgaCompatible. Now livecd behaves differently and simply installs both VGA and VBE. and since both are now marked as VgaCompatible, win32k doesn't know which one to use and currently uses VGA.
Now how does this work in Windows? Windows has only one Adapter installed for VGA and VBE (vga.sys + vga.dll/vga256.dll/vga64k.dll/framebuf.dll) This service is always loaded and marked as "VgaCompatible". It is also used when a 3rd party driver is installed, when you switch to fullscreen console mode. This adapter is only replaced by a 3rd party adapter if that one is also vga compatible. This way its easy for win32k to decide which one to use: based on whether /BASEVIDEO is passed, either the vga compatible one or the other one can be selected.
Possible solutions: 1) Add another workaround to win32k, checking if 2 VGA adapters are installed and then using the first one, instead of the second one as currently (because 1st is VGA, simply the second is used), but thats not a real solution. 2) Fix whatever is neccessary to have VBE be replaced by a 3rd party driver that is installed. (Cameron said it was related to VBE not being PNP ready.) This way we can stop marking it as VgaCompatible. 3) Combine VGA and VBE miniport into one vga compatible driver, like it's in windows. Alex mentioned that eVb has more or less finished that. Question is: whats missing to have the code comitted?
Comments and feedback appreciated, Timo
No.3 looks most Windows-compatible.
On Monday, October 17, 2011 2:49 PM, "Timo Kreuzer" timo.kreuzer@web.de wrote:
Possible solutions:
- Add another workaround to win32k, checking if 2 VGA adapters are
installed and then using the first one, instead of the second one as currently (because 1st is VGA, simply the second is used), but thats not a real solution. 2) Fix whatever is neccessary to have VBE be replaced by a 3rd party driver that is installed. (Cameron said it was related to VBE not being PNP ready.) This way we can stop marking it as VgaCompatible. 3) Combine VGA and VBE miniport into one vga compatible driver, like it's in windows. Alex mentioned that eVb has more or less finished that. Question is: whats missing to have the code comitted?
Comments and feedback appreciated, Timo
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi,
It's missing the magic to draw the 4 planes into a single region -- there were some changes done to ExtCreateregion to support this, but I think they were then later reverted, and maybe fixed again after? I don't know anymore.
I can commit the missing file and we can give it a try.
-- Best regards, Alex Ionescu
On 2011-10-17, at 10:18 AM, caemyr@myopera.com wrote:
No.3 looks most Windows-compatible.
On Monday, October 17, 2011 2:49 PM, "Timo Kreuzer" timo.kreuzer@web.de wrote:
Possible solutions:
- Add another workaround to win32k, checking if 2 VGA adapters are
installed and then using the first one, instead of the second one as currently (because 1st is VGA, simply the second is used), but thats not a real solution. 2) Fix whatever is neccessary to have VBE be replaced by a 3rd party driver that is installed. (Cameron said it was related to VBE not being PNP ready.) This way we can stop marking it as VgaCompatible. 3) Combine VGA and VBE miniport into one vga compatible driver, like it's in windows. Alex mentioned that eVb has more or less finished that. Question is: whats missing to have the code comitted?
Comments and feedback appreciated, Timo
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- With best regards Caemyr
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
What's missing is the magic function that takes the VGA data and prints out as a 4-layer region… that didn't work and required some changes to ExtCreateRegion I believe -- otherwise ReactOS was booting with just black and white.
Eventually those were changes were reverted I think, then re-added back? I don't know anymore.
I'll try to commit the missing file.
-- Best regards, Alex Ionescu
On 2011-10-17, at 5:49 AM, Timo Kreuzer wrote:
Hi,
Since one of my recent video driver loading changes, livecd video is vga mode. The reson is:
When installing bootcd, there will be only 1 video driver installed: based on 1st stage selection, either vbe or vga will be installed the other one is deactivated (start mode = manual). When installing a 3rd party driver, that one used to be installed and loaded prior to VBE and thus became Device/Video0, which win32k happily used as primary adapter. This behaviour changed with ACPI hal and VBE is loaded first, resulting is non functional VBox driver. I fixed this, by having win32k decide which driver to use, by looking if its a vga compatible driver and use that one only as fallback, if no other is present. additionally the VBE was marked as VgaCompatible. Now livecd behaves differently and simply installs both VGA and VBE. and since both are now marked as VgaCompatible, win32k doesn't know which one to use and currently uses VGA.
Now how does this work in Windows? Windows has only one Adapter installed for VGA and VBE (vga.sys + vga.dll/vga256.dll/vga64k.dll/framebuf.dll) This service is always loaded and marked as "VgaCompatible". It is also used when a 3rd party driver is installed, when you switch to fullscreen console mode. This adapter is only replaced by a 3rd party adapter if that one is also vga compatible. This way its easy for win32k to decide which one to use: based on whether /BASEVIDEO is passed, either the vga compatible one or the other one can be selected.
Possible solutions:
- Add another workaround to win32k, checking if 2 VGA adapters are installed and then using the first one, instead of the second one as currently (because 1st is VGA, simply the second is used), but thats not a real solution.
- Fix whatever is neccessary to have VBE be replaced by a 3rd party driver that is installed. (Cameron said it was related to VBE not being PNP ready.) This way we can stop marking it as VgaCompatible.
- Combine VGA and VBE miniport into one vga compatible driver, like it's in windows. Alex mentioned that eVb has more or less finished that. Question is: whats missing to have the code comitted?
Comments and feedback appreciated, Timo
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Am 18.10.2011 23:31, schrieb Alex Ionescu:
What's missing is the magic function that takes the VGA data and prints out as a 4-layer region… that didn't work and required some changes to ExtCreateRegion I believe -- otherwise ReactOS was booting with just black and white.
You are aware that ExtCreateRegion is a usermode gdi function and we are talking about the kernel mode display driver, yes? Do you mean EngCreateClip?
EngCreateRegion… there or some similar function that had issues with RLE and such.
On 2011-10-19, at 2:06 PM, Timo Kreuzer wrote:
Am 18.10.2011 23:31, schrieb Alex Ionescu:
What's missing is the magic function that takes the VGA data and prints out as a 4-layer region… that didn't work and required some changes to ExtCreateRegion I believe -- otherwise ReactOS was booting with just black and white.
You are aware that ExtCreateRegion is a usermode gdi function and we are talking about the kernel mode display driver, yes? Do you mean EngCreateClip?
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-
Alex Ionescu -
caemyr＠myopera.com -
Timo Kreuzer