Date: Mon, 25 Feb 2013 20:20:29 -0800 From: matt <sendtomatt@gmail.com> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: Fixing X220 Video The Right Way Message-ID: <512C380D.5030506@gmail.com> In-Reply-To: <CAJ-VmomuKk-4yHbX3dmy5Hs=%2BEyEh7ytAdB_QBABEMG6XUWaOA@mail.gmail.com> References: <512A6FFF.2060603@gmail.com> <201302251330.57034.jhb@freebsd.org> <512C159B.3020707@gmail.com> <CAJ-Vmo=hRSZ-Nwja0uJRFbT3R1xnvtC%2BnHjMFA9xMz=6Azz1BA@mail.gmail.com> <512C1C8A.5020104@gmail.com> <CAJ-VmomuKk-4yHbX3dmy5Hs=%2BEyEh7ytAdB_QBABEMG6XUWaOA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/25/13 18:33, Adrian Chadd wrote: > [101232] acpi_video0: <ACPI video extension> on vgapci0 > found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0 > > And what do I do with acpi_get_handle ? > > > > I threw printfs into acpi_video, not sure if that would work for both vgapci or not. I'm not sure if I wiped out my debug patches yet, I may have a patch. Basically the idea is to figure out which paths in the DSDT are getting attached to the vgapci devices. This dsdt patch from Mitsuru Iwasaki illustrates fixing a similar issue to X220 via a custom dsdt http://people.freebsd.org/~iwasaki/acpi/tpx61.asl.diff <http://people.freebsd.org/%7Eiwasaki/acpi/tpx61.asl.diff>; It seems like we could either try to find these paths on affected models, or have a tunable override for acpi_video. Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?512C380D.5030506>