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 / video-detec
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 c
when did it start working?
-adrian
On 9 August 2013 20:10, matt wrote:
> hw.acpi.reset_video used to send this machine X220 into a reboot loop,
> with flashing thinklight. Interesting that it no longer causes this
> problem. I kind of paused since the trackpad sucks so much in X.
>
> I think si
hw.acpi.reset_video used to send this machine X220 into a reboot loop,
with flashing thinklight. Interesting that it no longer causes this
problem. I kind of paused since the trackpad sucks so much in X.
I think since ssh still works, that just the display or graphics port
is off.
It may be worth
On Friday, August 09, 2013 4:37:50 am Adrian Chadd wrote:
> 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
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 wrote:
> O
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.
Grea
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 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
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
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
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 to
> >>> your ASL lying aro
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 to
your ASL lying around already?
Too big for pastebin :( +500k
https://docs.google.com/file
Hi,
On Wed, 27 Feb 2013 15:27:36 -0500
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 to your ASL lying around already?
> > Too big for pasteb
I'll email later, but I do have two PCI devices show up in pciconf
-lv; but acpi_video() only attaches to one.
I don't know why two PCI devices show up.. guess there's more digging to do.
ADrian
___
freebsd-acpi@freebsd.org mailing list
http://lists.f
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 to
> > your ASL lying around already?
> Too big for pastebin :( +500k
>
> https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWN
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 to
> your ASL lying around already?
Too big for pastebin :( +500k
https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing
Thanks,
Matt
__
On Tuesday, February 26, 2013 9:32:33 pm matt wrote:
> On 02/26/13 10:46, John Baldwin wrote:
> > On Monday, February 25, 2013 11:20:29 pm matt wrote:
> >> On 02/25/13 18:33, Adrian Chadd wrote:
> >>> [101232] acpi_video0: on vgapci0
> >>> found Internal/Integrated Digital Flat Panel(400), idx#0,
On 02/26/13 10:46, John Baldwin wrote:
> On Monday, February 25, 2013 11:20:29 pm matt wrote:
>> On 02/25/13 18:33, Adrian Chadd wrote:
>>> [101232] acpi_video0: on vgapci0
>>> found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0
>>>
>>> And what do I do with acpi_get_handle ?
On Monday, February 25, 2013 11:20:29 pm matt wrote:
> On 02/25/13 18:33, Adrian Chadd wrote:
> > [101232] acpi_video0: 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 ac
On 02/25/13 18:33, Adrian Chadd wrote:
> [101232] acpi_video0: 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 sur
[101232] acpi_video0: 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 wrote:
> On 02/25/13 18:19, Adrian Chadd wrote:
>>
>> My T400 has:
>>
>>
>> vgapci0@pci0:0:2:0: class
On 02/25/13 18:19, Adrian Chadd wrote:
>
> My T400 has:
>
>
> vgapci0@pci0:0:2:0: class=0x03 card=0x20e417aa chip=0x2a428086
> rev=0x07 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Mobile 4 Series Chipset Integrated Graphics Controller'
> class = display
>
On 25 February 2013 17:53, matt 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 acpi_video ret
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
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
26 matches
Mail list logo
