So now that i have everything else working on this x230, I'm taking a
fresh look at the acpi brightness support.
I'm in the same boat - only PEG works. But I have integrated graphics
only, rather than both integrated and nvidia graphics.
A cursory reading of the linux acpi and video /
Not sure that it did :)
I tried it once early on, and it concerned me enough I never tried
again. It was clearly in a violently erroneous state!
At one point, X *could* resume the display. This makes me think the
problem is solved via the graphics chip state, but it could be an
acpi thing.
I
Hi!
Hm, resurrecting this thread, I'll try this on my X230 tomorrow and
see if it makes the (non-xorg, console only) video work on resume.
If it does, what will it take to automatically determine that this
kind of work-around is needed?
Thanks!
-adrian
On 14 June 2013 16:00, matt
On Fri, 14 Jun 2013 16:00:11 -0700, matt wrote
I'm glad you got this working, it makes the X220 (and probably
other laptops with similar issues) more usable on FreeBSD.
Sure, that's good news !
I'll have to bring my X220 back up to current and start
looking at sleep issues next.
Great !
On Thursday, March 07, 2013 9:13:38 pm matt wrote:
On 02/28/13 09:09, John Baldwin wrote:
On Thursday, February 28, 2013 8:15:46 am matt wrote:
On 02/27/13 12:27, John Baldwin wrote:
On Wednesday, February 27, 2013 1:35:43 pm matt wrote:
On 02/27/13 09:00, John Baldwin wrote:
If that is
On 06/14/13 08:39, John Baldwin wrote:
I got this to work by using 4 backslashes. At that point the patch
worked. (I recently got access to an X220.) I get a local APIC
error each time I adjust the brightness though (probably the BIOS
is doing something wonky).
That's awesome! I've
On 02/28/13 09:09, John Baldwin wrote:
On Thursday, February 28, 2013 8:15:46 am matt wrote:
On 02/27/13 12:27, John Baldwin wrote:
On Wednesday, February 27, 2013 1:35:43 pm matt wrote:
On 02/27/13 09:00, John Baldwin wrote:
If that is true, it's because your BIOS is lying. Do you have a URL
On Sunday, February 24, 2013 2:54:39 pm matt wrote:
I am working on fixing acpi_video for X220.
My X220 is back to FreeBSD land, and I always felt \VBRC calls were dirty.
So I've set out to fix acpi_video to work naturally, as it does in linux
land.
Background:
Lenovo laptops boot in a
On 02/25/13 10:30, John Baldwin wrote:
Is there a better place to correct the ACPI_PATH that gets stored in
vgapci's ivar? Is there already a tunable I can use to fix this?
vgapci's ivar is set by the PCI address. Do you have multiple vgapci devices?
No, just one. I think that the DSDT is
On 25 February 2013 17:53, matt sendtom...@gmail.com wrote:
No, just one. I think that the DSDT is very creative on recent Lenovos
(read: broken). There are multiple video devices defined, with
functional calls that nonetheless don't work to actually do anything.
The acpi_get_handle() call in
[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 ?
Adrian
On 25 February 2013 18:23, matt sendtom...@gmail.com wrote:
On 02/25/13 18:19, Adrian Chadd wrote:
My T400 has:
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
I am working on fixing acpi_video for X220.
My X220 is back to FreeBSD land, and I always felt \VBRC calls were dirty.
So I've set out to fix acpi_video to work naturally, as it does in linux
land.
Background:
Lenovo laptops boot in a mode where the brightness keys automagically
work, under
13 matches
Mail list logo