Re: [ACPI] Re: [RFC] Reliable video POSTing on resume

2005-02-10 Thread Carl-Daniel Hailfinger
Li-Ta Lo schrieb: > On Mon, 2005-02-07 at 09:01, Pavel Machek wrote: > 3 - it's always there and can be executed at *any* time: booting, returning from suspend, etc. Also it would allow the VESA framebuffer driver to change graphics mode at any time (for instance). >>> >>>OK, and what

Re: [ACPI] Re: [RFC] Reliable video POSTing on resume

2005-02-10 Thread Carl-Daniel Hailfinger
Jon Smirl schrieb: > On Thu, 10 Feb 2005 21:06:36 +, Matthew Garrett <[EMAIL PROTECTED]> wrote: > >>On Thu, 2005-02-10 at 12:46 -0800, Kendall Bennett wrote: >> >> >>>So perhaps this problem is something similar? > > > What type of computer has the problem? Who makes it's video chips? Samsu

Re: [ACPI] Re: [RFC] Reliable video POSTing on resume

2005-02-07 Thread Pavel Machek
Hi! > >The problem with the radeon reset code is that there are many, many > >variations of the radeon chips, including different steppings of the > >same part. The ROM is matched to the paticular bugs of the chip. From > >what I know ATI doesn't even have a universal radeon reset program. > > >

Re: [ACPI] Re: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))

2005-02-07 Thread Pavel Machek
Hi! > > Some systems (intel notably) appear to expect you to use the bios > > save/restore video state not re-POST. > > This works well in many cases, but there are some machines that freeze > if you attempt to make a VBE state save call. Sadly, I don't have any > access to an affected machine, s

Re: [ACPI] Re: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))

2005-02-07 Thread Matthew Garrett
On Sun, 2005-02-06 at 16:02 +, Alan Cox wrote: > Some systems (intel notably) appear to expect you to use the bios > save/restore video state not re-POST. This works well in many cases, but there are some machines that freeze if you attempt to make a VBE state save call. Sadly, I don't have a

Re: [ACPI] Re: [RFC] Reliable video POSTing on resume

2005-02-07 Thread Helge Hafting
Jon Smirl wrote: On Sat, 5 Feb 2005 17:48:43 +0100, Stefan DÃsinger <[EMAIL PROTECTED]> wrote: The reset code of radeon card seems to be easy to reverse engineer. I have started an attempt and I have 50-60% of my radeon M9 reset code implemented in a 32 bit C program. I had to stop due to school

Re: [ACPI] Re: [RFC] Reliable video POSTing on resume

2005-02-06 Thread Stefan Dösinger
Am Samstag, 5. Februar 2005 18:38 schrieb Jon Smirl: > On Sat, 5 Feb 2005 17:48:43 +0100, Stefan Dösinger > > <[EMAIL PROTECTED]> wrote: > > The reset code of radeon card seems to be easy to reverse engineer. I > > have started an attempt and I have 50-60% of my radeon M9 reset code > > implemented

Re: [ACPI] Re: [RFC] Reliable video POSTing on resume

2005-02-05 Thread Jon Smirl
On Sat, 5 Feb 2005 17:48:43 +0100, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > The reset code of radeon card seems to be easy to reverse engineer. I have > started an attempt and I have 50-60% of my radeon M9 reset code implemented > in a 32 bit C program. I had to stop due to school reasons. The

Re: [ACPI] Re: [RFC] Reliable video POSTing on resume

2005-02-05 Thread Stefan Dösinger
Am Samstag, 5. Februar 2005 16:47 schrieb Jon Smirl: > On Sat, 05 Feb 2005 12:53:37 +0100, Ondrej Zary > > <[EMAIL PROTECTED]> wrote: > > I wonder how this can work: > > a motherboard with i815 chipset (integrated VGA), Video BIOS is > > integrated into system BIOS > > a PCI card inserted into one

Re: [ACPI] Re: [RFC] Reliable video POSTing on resume

2005-02-04 Thread Matthew Garrett
On Fri, 2005-02-04 at 13:17 +0100, Carl-Daniel Hailfinger wrote: > Jon Smirl schrieb: > > 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/

Re: [ACPI] Re: [RFC] Reliable video POSTing on resume

2005-02-04 Thread David Goodenough
On Friday 04 February 2005 11:32, Carl-Daniel Hailfinger wrote: > Oliver Neukum schrieb: > > Am Freitag, 4. Februar 2005 08:48 schrieb Pavel Machek: > >>What about simply blocking all video accesses before disk (etc) is > >>resumed, so that "normal" (not locked in memory) application can be > >>use