HEADSUP: default for hw.acpi.reset_video changed

[Nate Lawson]

Eric Anholt wrote:
> On Mon, 2006-06-19 at 10:55 -0700, Nate Lawson wrote:
>> I thought this would be a small change (since the default was already 
>> supposed to be this way) but as usual with acpi, there is a lot of 
>> variation out there.  I think it's split about 50/50 between systems 
>> where enabling this feature is helpful/neutral and those that it is harmful.
>>
>> The default value of the tunable/sysctl for hw.acpi.reset_video has 
>> changed from 1 to 0 (off).  This means the BIOS video reset method will 
>> not be called automatically on resume.  If you want the previous 
>> behavior, set hw.acpi.reset_video="1" in /boot/loader.conf or 
>> /etc/sysctl.conf.
>>
>> If a committer could throw the 2nd paragraph in UPDATING, that would be 
>> nice, thanks.
> 
> A note on reset_video from recent discussions I've had with Linux folks:
> 
> Up until recently was their reset_video equivalent (vbetool) being on or
> off sounded like about a 50/50 chance of working or not either way.  But
> apparently recently Linux started hooking in a reset_video from real
> mode before going back to protected, and this works a lot better than
> doing it with vm86.
> 
> As far as I understand, our reset_video hook in FreeBSD is done with
> vm86.  If so, it might be valuable to try that method, if it might get
> us something that works everywhere.

No, it's the opposite.  We run the reset_video code in real mode during 
resume and before enabling protected mode.  Linux does the same thing 
for this method (lcall 0xc000, 3).

However, the vbetool method does a much more complete reinitialization 
of video.  It would be worth looking into all the things it does and 
adding it to the agp video framework or acpi as appropriate.  We don't 
do any of this by default right now although Takawata-san ported vbetool 
to FreeBSD as a port.

-- 
Nate