Livecd video regression

[Timo Kreuzer]

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(a)web.de>
wrote:

>   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
>  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>   

-- 
With best regards
Caemyr

[Alex Ionescu]

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(a)myopera.com wrote:

>   No.3 looks most Windows-compatible.
>  
>  On Monday, October 17, 2011 2:49 PM, "Timo Kreuzer" <timo.kreuzer(a)web.de>
> wrote:
>  
> >   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
> >  
> >  
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >   
>  
>  
>  -- 
>  With best regards
>  Caemyr
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[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.

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:
>  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
>  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Timo Kreuzer]

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?

[Alex Ionescu]

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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev