Radeon M7 and resuming from suspend-to-ram

Radeon M7 and resuming from suspend-to-ram

[Tomi Kallio]

Hello.

I'm running gentoo on Compaq Evo N800V laptop with radeon M7. At the 
moment I'm using gentoo-dev-sources version 2.6.10-r4. For the first 
time suspend-to-ram almoust works but I'm having trouble resuming 
radeon/screen. After resuming, display on laptop stays black with just 
"weak" backlight but if I plug in external monitor, then external 
monitor is working normally but laptop's display stays black. So the 
resume from X "works". If I switch to console then external monitor 
complaints about invalid mode while laptop's display stays black. With 
radeontool I can normally power down/up external output, but display on 
laptop stays blank no matter what I do. I have also tried boot-radeon in 
console that should reset video bios, but it doesn't work either.

Any ideas?

Tomi

--
gentoo-user@gentoo.org mailing list

Re: Radeon M7 and resuming from suspend-to-ram

[Jeremy Moles]

Probably already tried this but:

Here at work we use an ACPID script that simply runs "radeontool light
on" after a resume. Also, you might trying "chvt 1" or similar before
suspend and chvt'ing back to whatever TTY X is on upon resume.

That's worked sometimes too.

On Fri, 2005-01-14 at 16:12 +0200, Tomi Kallio wrote:
> Hello.
> 
> I'm running gentoo on Compaq Evo N800V laptop with radeon M7. At the 
> moment I'm using gentoo-dev-sources version 2.6.10-r4. For the first 
> time suspend-to-ram almoust works but I'm having trouble resuming 
> radeon/screen. After resuming, display on laptop stays black with just 
> "weak" backlight but if I plug in external monitor, then external 
> monitor is working normally but laptop's display stays black. So the 
> resume from X "works". If I switch to console then external monitor 
> complaints about invalid mode while laptop's display stays black. With 
> radeontool I can normally power down/up external output, but display on 
> laptop stays blank no matter what I do. I have also tried boot-radeon in 
> console that should reset video bios, but it doesn't work either.
> 
> Any ideas?
> 
> Tomi
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: Radeon M7 and resuming from suspend-to-ram

[Karol Kozimor]

Thus wrote Tomi Kallio:
> I'm running gentoo on Compaq Evo N800V laptop with radeon M7. At the 

acpi_sleep=s3_bios helps here (ASUS L3C, Radeon M7), have you checked
Documentation/power/video.txt?
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: Radeon M7 and resuming from suspend-to-ram

[Matthew Garrett]

On Fri, 2005-01-14 at 16:12 +0200, Tomi Kallio wrote:

> Any ideas?

Try getting vbetool from http://www.srcf.ucam.org/~mjg59/vbetool and
build it. On boot (before X is started), do 

vbetool vbestate save >/var/run/vbestate

In your suspend script, chvt away from X. In your resume script, run

vbetool vbestate restore </var/run/vbestate
vbetool dpms on

and then chvt back to X. That seems to work on a large number of
machines.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: Radeon M7 and resuming from suspend-to-ram

[Tomi Kallio]

>>I'm running gentoo on Compaq Evo N800V laptop with radeon M7. At the 
 >>
> acpi_sleep=s3_bios helps here (ASUS L3C, Radeon M7), have you checked
> Documentation/power/video.txt?

I tried acpi_sleep=s3_bios, but it crashed during resume. Without any 
options resume works when using external display but laptops own display 
stays black, whether external display is connected or not.

Tomi




-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: Radeon M7 and resuming from suspend-to-ram

[Tomi Kallio]

> Probably already tried this but:
> 
> Here at work we use an ACPID script that simply runs "radeontool light
> on" after a resume. Also, you might trying "chvt 1" or similar before
> suspend and chvt'ing back to whatever TTY X is on upon resume.

I tried "radeontool light on", but it has no effect. When using external 
display I'm able to power it off using radeontool. At the moment resume 
from suspend-to-ram works from X (xorg and Gentoo's patches) using 
external display and suspend/resume from X is enough for me. Only 
problem is that I'm unable to get laptop's own display working after 
resume, only external works.

Tomi


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: Radeon M7 and resuming from suspend-to-ram

[Ralf Gerbig]

* Matthew Garrett writes:

> Try getting vbetool from http://www.srcf.ucam.org/~mjg59/vbetool and
> build it. On boot (before X is started), do 

Dammit, it does work on my Acer Travelmate 380. It took some idiot
hacks to compile on SuSE, but after calling 

chvt 1 
vbetool vbestate save > /tmp/vbestate

in /usr/lib/poewersave/scripts/prepare_suspend_to_ram and

vbetool vbestate restore < /tmp/vbestate
chvt 7

in /usr/lib/poewersave/scripts/restore_after_suspend_to_ram

the LCD becomes alive after suspend to ram.

Thanks for the good stuff,

Ralf
-- 
 P:     Linus Torvalds			patch-2.2.4
-S:     Buried alive in diapers
+S:     Buried alive in reporters


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: Radeon M7 and resuming from suspend-to-ram

[Matthew Garrett]

On Tue, 2005-01-18 at 23:11 +0100, Ralf Gerbig wrote:

> chvt 1 
> vbetool vbestate save > /tmp/vbestate
> 
> in /usr/lib/poewersave/scripts/prepare_suspend_to_ram and
> 
> vbetool vbestate restore < /tmp/vbestate
> chvt 7
> 
> in /usr/lib/poewersave/scripts/restore_after_suspend_to_ram
> 
> the LCD becomes alive after suspend to ram.

Excellent. So far, the best solution we've found is to save the vbestate
on boot rather than on suspend. There's a small number of machines that
this hangs on, irritatingly, but I'm trying to track them down. It seems
far more successful than using video_post for the most part.
-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: Radeon M7 and resuming from suspend-to-ram

[Ralf Gerbig]

* Matthew Garrett writes:
> On Tue, 2005-01-18 at 23:11 +0100, Ralf Gerbig wrote:
>> chvt 1 
>> vbetool vbestate save > /tmp/vbestate
>> 
>> in /usr/lib/poewersave/scripts/prepare_suspend_to_ram and
>> 
>> vbetool vbestate restore < /tmp/vbestate
>> chvt 7
>> 
>> in /usr/lib/poewersave/scripts/restore_after_suspend_to_ram
>> 
>> the LCD becomes alive after suspend to ram.

> Excellent. So far, the best solution we've found is to save the vbestate
> on boot rather than on suspend. There's a small number of machines that
> this hangs on, irritatingly, but I'm trying to track them down. It seems
> far more successful than using video_post for the most part.

Last night I was too dumbfounded that it actually worked to include
any details.

The thing is an Acer Travelmate 380:

rge@lapdog2:~> /sbin/lspci 
0000:00:00.0 Host bridge: Intel Corp. 82852/855GM Host Bridge (rev 02)
0000:00:00.1 System peripheral: Intel Corp. 855GM/GME GMCH Memory I/O Control Registers (rev 02)
0000:00:00.3 System peripheral: Intel Corp. 855GM/GME GMCH Configuration Process Registers (rev 02)
0000:00:02.0 VGA compatible controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02)
0000:00:02.1 Display controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02)
0000:00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03)
0000:00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 03)
0000:00:1d.2 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 03)
0000:00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB 2.0 EHCI Controller (rev 03)
0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 83)
0000:00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 03)
0000:00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage Controller (rev 03)
0000:00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 03)
0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03)
0000:00:1f.6 Modem: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 03)
0000:02:01.0 Network controller: Intel Corp. PRO/Wireless 2200BG (rev 05)
0000:02:09.0 CardBus bridge: Texas Instruments PCI7420 CardBus Controller
0000:02:09.2 FireWire (IEEE 1394): Texas Instruments PCI7x20 1394a-2000 OHCI Two-Port PHY/Link-Layer Controller
0000:02:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)

rge@lapdog2:~> /sbin/lspci -n
0000:00:00.0 Class 0600: 8086:3580 (rev 02)
0000:00:00.1 Class 0880: 8086:3584 (rev 02)
0000:00:00.3 Class 0880: 8086:3585 (rev 02)
0000:00:02.0 Class 0300: 8086:3582 (rev 02)
0000:00:02.1 Class 0380: 8086:3582 (rev 02)
0000:00:1d.0 Class 0c03: 8086:24c2 (rev 03)
0000:00:1d.1 Class 0c03: 8086:24c4 (rev 03)
0000:00:1d.2 Class 0c03: 8086:24c7 (rev 03)
0000:00:1d.7 Class 0c03: 8086:24cd (rev 03)
0000:00:1e.0 Class 0604: 8086:2448 (rev 83)
0000:00:1f.0 Class 0601: 8086:24cc (rev 03)
0000:00:1f.1 Class 0101: 8086:24ca (rev 03)
0000:00:1f.3 Class 0c05: 8086:24c3 (rev 03)
0000:00:1f.5 Class 0401: 8086:24c5 (rev 03)
0000:00:1f.6 Class 0703: 8086:24c6 (rev 03)
0000:02:01.0 Class 0280: 8086:4220 (rev 05)
0000:02:09.0 Class 0607: 104c:ac8e
0000:02:09.2 Class 0c00: 104c:802e
0000:02:0a.0 Class 0200: 10ec:8139 (rev 10)

Kernel is 2.6.11-rc1-mm1, Distribution SuSE 9.2
gcc version 3.3.4 (pre 3.3.5 20040809)

SuSE does not have a shared libpci, only static so the precompiled
binary unsurprisingly did not work.

Compiling the source I got: 

rge@lapdog2:/usr/src/vbetool-0.2> make
if gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" 
-DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"vbetool\" 
-DVERSION=\"0.2\"  -I. -I.    
-g -Wall -Werror -pedantic -g -O2 -MT vbetool.o -MD -MP -MF ".deps/vbetool.Tpo" \
  -c -o vbetool.o `test -f 'vbetool.c' || echo './'`vbetool.c; \
then mv -f ".deps/vbetool.Tpo" ".deps/vbetool.Po"; \
else rm -f ".deps/vbetool.Tpo"; exit 1; \
fi
In file included from /usr/include/stdlib.h:416,
                 from vbetool.c:14:
/usr/include/sys/types.h:62: error: conflicting types for `dev_t'
/usr/include/linux/types.h:22: error: previous declaration of `dev_t'
/usr/include/sys/types.h:67: error: conflicting types for `gid_t'
/usr/include/linux/types.h:52: error: previous declaration of `gid_t'
/usr/include/sys/types.h:72: error: conflicting types for `mode_t'
/usr/include/linux/types.h:24: error: previous declaration of `mode_t'
/usr/include/sys/types.h:77: error: conflicting types for `nlink_t'
/usr/include/linux/types.h:25: error: previous declaration of `nlink_t'
/usr/include/sys/types.h:82: error: conflicting types for `uid_t'
/usr/include/linux/types.h:51: error: previous declaration of `uid_t'
In file included from /usr/include/sys/types.h:216,
                 from /usr/include/stdlib.h:416,
                 from vbetool.c:14:
/usr/include/sys/select.h:78: error: conflicting types for `fd_set'
/usr/include/linux/types.h:21: error: previous declaration of `fd_set'

stdlib.h:415-416:

#if defined __USE_SVID || defined __USE_XOPEN_EXTENDED || defined __USE_BSD
# include <sys/types.h>         /* we need int32_t... */ 

after fuzing around with -D, I temporally commented out the
include. Thereafter adding -lpci to the end of the link command, I got
a working executable.

Ralf
-- 
 P:     Linus Torvalds			patch-2.2.4
-S:     Buried alive in diapers
+S:     Buried alive in reporters


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

Re: Radeon M7 and resuming from suspend-to-ram

[Carl-Daniel Hailfinger]

Ralf Gerbig schrieb:
> * Matthew Garrett writes:
> 
>>On Tue, 2005-01-18 at 23:11 +0100, Ralf Gerbig wrote:
>>
>>>chvt 1 
>>>vbetool vbestate save > /tmp/vbestate
>>>
>>>in /usr/lib/poewersave/scripts/prepare_suspend_to_ram and
>>>
>>>vbetool vbestate restore < /tmp/vbestate
>>>chvt 7
>>>
>>>in /usr/lib/poewersave/scripts/restore_after_suspend_to_ram
>>>
>>>the LCD becomes alive after suspend to ram.
> 
> 
>>Excellent. So far, the best solution we've found is to save the vbestate
>>on boot rather than on suspend. There's a small number of machines that
>>this hangs on, irritatingly, but I'm trying to track them down. It seems
>>far more successful than using video_post for the most part.
> 
> 
> Last night I was too dumbfounded that it actually worked to include
> any details.
> 
[...]
> 
> SuSE does not have a shared libpci, only static so the precompiled
> binary unsurprisingly did not work.
> 
> Compiling the source I got: 
> 
> rge@lapdog2:/usr/src/vbetool-0.2> make
> if gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" 
> -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"vbetool\" 
> -DVERSION=\"0.2\"  -I. -I.    
> -g -Wall -Werror -pedantic -g -O2 -MT vbetool.o -MD -MP -MF ".deps/vbetool.Tpo" \
>   -c -o vbetool.o `test -f 'vbetool.c' || echo './'`vbetool.c; \
> then mv -f ".deps/vbetool.Tpo" ".deps/vbetool.Po"; \
> else rm -f ".deps/vbetool.Tpo"; exit 1; \
> fi
> In file included from /usr/include/stdlib.h:416,
>                  from vbetool.c:14:
> /usr/include/sys/types.h:62: error: conflicting types for `dev_t'
> /usr/include/linux/types.h:22: error: previous declaration of `dev_t'
> [...]

Yes, the pci.h shipped by SUSE has problems. Simply move the #include
<pci/pci.h> from the beginning to directly before #include <sys/kd.h>

> after fuzing around with -D, I temporally commented out the
> include. Thereafter adding -lpci to the end of the link command, I got
> a working executable.

This is a bug in Makefile.am. Pseudo-diff:

-AM_LDFLAGS = -lpci
+LIBS = -lpci

Then run aclocal, autoconf and automake again.


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

Re: Radeon M7 and resuming from suspend-to-ram

[Ralf Gerbig]

Moins,

* Carl-Daniel Hailfinger:
> Ralf Gerbig schrieb:
>> Compiling the source I got: 
>> 
>> rge@lapdog2:/usr/src/vbetool-0.2> make
>> if gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" 
>> -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"vbetool\" 
>> -DVERSION=\"0.2\"  -I. -I.    
>> -g -Wall -Werror -pedantic -g -O2 -MT vbetool.o -MD -MP -MF ".deps/vbetool.Tpo" \
>> -c -o vbetool.o `test -f 'vbetool.c' || echo './'`vbetool.c; \
>> then mv -f ".deps/vbetool.Tpo" ".deps/vbetool.Po"; \
>> else rm -f ".deps/vbetool.Tpo"; exit 1; \
>> fi
>> In file included from /usr/include/stdlib.h:416,
>> from vbetool.c:14:
>> /usr/include/sys/types.h:62: error: conflicting types for `dev_t'
>> /usr/include/linux/types.h:22: error: previous declaration of `dev_t'
>> [...]

> Yes, the pci.h shipped by SUSE has problems. Simply move the #include
> <pci/pci.h> from the beginning to directly before #include <sys/kd.h>

>> after fuzing around with -D, I temporally commented out the
>> include. Thereafter adding -lpci to the end of the link command, I got
>> a working executable.

> This is a bug in Makefile.am. Pseudo-diff:

> -AM_LDFLAGS = -lpci
> +LIBS = -lpci

> Then run aclocal, autoconf and automake again.


yup, works with this diff:

--- ../vbetool-0.2-orig/Makefile.am     2004-12-30 16:27:07.000000000 +0100
+++ Makefile.am 2005-02-03 23:38:08.000000000 +0100
@@ -12,4 +12,4 @@
        $(RM) Makefile.in aclocal.m4 config.h.in stamp-h.in configure
 
 AM_CFLAGS = -g -Wall -Werror -pedantic
-AM_LDFLAGS = -lpci
+LIBS = -lpci

--- ../vbetool-0.2-orig/vbetool.c       2004-12-31 16:11:19.000000000 +0100
+++ vbetool.c   2005-02-03 23:38:40.000000000 +0100
@@ -8,7 +8,6 @@
 version 2
 */
 
-#include <pci/pci.h>
 #include <assert.h>
 #include <stdio.h>
 #include <stdlib.h>
@@ -17,6 +16,7 @@
 #include <sys/ioctl.h>
 #include <sys/types.h>
 #include <sys/io.h>
+#include <pci/pci.h>
 #include <sys/kd.h>
 #include <sys/stat.h>
 #include <errno.h>

Ralf


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

Re: Radeon M7 and resuming from suspend-to-ram

[Carl-Daniel Hailfinger]

[-- Attachment #1: Type: text/plain, Size: 1417 bytes --]

Carl-Daniel Hailfinger schrieb:
> Ralf Gerbig schrieb:
> 
>>SuSE does not have a shared libpci, only static so the precompiled
>>binary unsurprisingly did not work.
>>
>>Compiling the source I got: 
>>
>>rge@lapdog2:/usr/src/vbetool-0.2> make
>>if gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" 
>>-DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"vbetool\" 
>>-DVERSION=\"0.2\"  -I. -I.    
>>-g -Wall -Werror -pedantic -g -O2 -MT vbetool.o -MD -MP -MF ".deps/vbetool.Tpo" \
>>  -c -o vbetool.o `test -f 'vbetool.c' || echo './'`vbetool.c; \
>>then mv -f ".deps/vbetool.Tpo" ".deps/vbetool.Po"; \
>>else rm -f ".deps/vbetool.Tpo"; exit 1; \
>>fi
>>In file included from /usr/include/stdlib.h:416,
>>                 from vbetool.c:14:
>>/usr/include/sys/types.h:62: error: conflicting types for `dev_t'
>>/usr/include/linux/types.h:22: error: previous declaration of `dev_t'
>>[...]
> 
> 
> Yes, the pci.h shipped by SUSE has problems. Simply move the #include
> <pci/pci.h> from the beginning to directly before #include <sys/kd.h>
> 
>>after fuzing around with -D, I temporally commented out the
>>include. Thereafter adding -lpci to the end of the link command, I got
>>a working executable.

Matthew, could you apply attached patch and run aclocal, autoconf and
automake again? This will fix the compile problems on SUSE 9.2.


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

[-- Attachment #2: vbetool-fix.diff --]
[-- Type: text/x-patch, Size: 848 bytes --]

diff -urN vbetool-0.2/Makefile.am vbetool-0.2-modified/Makefile.am
--- vbetool-0.2/Makefile.am	2004-12-30 16:27:07.000000000 +0100
+++ vbetool-0.2-modified/Makefile.am	2005-02-03 21:58:16.000000000 +0100
@@ -12,4 +12,4 @@
 	$(RM) Makefile.in aclocal.m4 config.h.in stamp-h.in configure
 
 AM_CFLAGS = -g -Wall -Werror -pedantic
-AM_LDFLAGS = -lpci
+LIBS = -lpci
diff -urN vbetool-0.2/vbetool.c vbetool-0.2-modified/vbetool.c
--- vbetool-0.2/vbetool.c	2004-12-31 16:11:19.000000000 +0100
+++ vbetool-0.2-modified/vbetool.c	2005-02-03 22:02:53.000000000 +0100
@@ -8,7 +8,6 @@
 version 2
 */
 
-#include <pci/pci.h>
 #include <assert.h>
 #include <stdio.h>
 #include <stdlib.h>
@@ -17,6 +16,7 @@
 #include <sys/ioctl.h>
 #include <sys/types.h>
 #include <sys/io.h>
+#include <pci/pci.h>
 #include <sys/kd.h>
 #include <sys/stat.h>
 #include <errno.h>