Re: [RFC] Reliable video POSTing on resume

[Carl-Daniel Hailfinger <c-d.hailfinger.devel.2005-hi6Y0CQ0nG0@public.gmane.org>]

Jon Smirl schrieb:
> Reseting a video card from suspend is essentially the same problem as
> reseting secondary video cards on boot. The same code can address both
> problems.
> 
> Some things to consider....
> 
> 1) With multiple video cards you have to ensure only a single VGA gets
> enabled. Running video reset on a card is going to turn on it's VGA
> emulation. So you have to ensure that VGA emulation on other cards is
> disabled first.

No problem. Let the kernel tell the userspace application which card
to reset.

> 2) I add the 'rom' parameter in sysfs so that you can get to the rom
> contents from a user space app. It's there to support running video
> reset code. "echo 1 >rom" to see the contents, it is not enabled by
> default.

That could be very helpful for secondary cards.

> 3) The user space reset programs have to be serialized because of the
> rule about only a single VGA at a time. Calling vm86 from kernel mode
> is not a good idea. Doing this in user space lets you have two reset
> programs, vm86 and emu86 for non-x86 machines.

With the approach I detailed in the thread starter, this is easily
possible. vesaposter can call the kernel function used to synchronize
in an endless loop and this kernel function would not only be used
to synchronize, but its return value would tell vesaposter what to do
to which card. An alternative would be to restart vesaposter as soon
as it has finished its job, which would make the POSTing reliable
even if the BIOS code hangs or causes crashes. The kernel can simply
store a list of video devices and their respective treatments and
the kernel function called by vesaposter would just iterate through
the list. Hmmm... why not call it

int video_helper(struct video_actions *what_to_do)

and it blocks until we have something to POST. It could contain
all the locking needed to serialize access to the video cards.
OTOH, if starting applications from initramfs at resume time is
easy, we could make video_helper non-blocking and start vesaposter
on demand.


And the problem of locking all application memory: The current tool
for POSTing and restoring video state (vbetool) uses only 27k on
disk. If we put it in initramfs, we could maybe avoid mlock
completely (if we can guarantee initramfs contents aren't swapped
out). And it would be available early enough for initializing
video hardware on boot.


> A starting place for a user space reset program:
> ftp://ftp.scitechsoft.com/devel/obsolete/x86emu/x86emu-0.8.tar.gz
> 
> This thread talks about the VGA routing code:
> http://lkml.org/lkml/2005/1/17/347

Thanks for the pointers! I'll have to compare it to our current
userspace reset and vesa register restoring program
http://www.srcf.ucam.org/~mjg59/vbetool/


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl