Re: x220 notes

On 02/12/12 12:29, Hannes Mehnert wrote:
> Hi,
>
> I recently got a X220 and installed -CURRENT (with kib's 13.1 patch) on
> it - let me add some notes on this thread.
>
> On 10/17/2011 03:53, Matt wrote:
>> On 09/28/11 16:01, Kevin Oberman wrote:
>>> On Wed, Sep 28, 2011 at 12:32 PM, Garrett Cooper<yanegomi_at_gmail.com> 
>>> wrote:
>>>> On Wed, Sep 28, 2011 at 12:25 PM, Matt<sendtomatt_at_gmail.com>  wrote:
>>>>> On 09/28/11 11:52, Garrett Cooper wrote:
>>>>>> On Wed, Sep 28, 2011 at 11:48 AM, Matt<sendtomatt_at_gmail.com>    wrote:
>>>>>>> acpi_ibm needs "LEN0068" added to the list of ibm ids at the
>>>>>>> beginning of
>>>>>>> /usr/src/sys/dev/acpi_support/acpi_ibm.c...I'd write a patch but that
>>>>>>> machine is in a world of ports hurt right now :).
>>>>>>> With this many of the sysctls and leds work, still no brightness
>>>>>>> (w or
>>>>>>> wout
>>>>>>> intel DRI from Konstantin...thanks Konstantin!!)
> (there's a pr about that kern/164538)
>
>
>> I'm not sure if I mentioned this in another post, but I can confirm that
>> adjusting brightness in ibm_acpi for me results in corrupting the fan
>> speed, which makes me think that addresses have changed, widths/extents
>> have changed, or something else is different. For what it's worth,
>> thinkpad-acpi in Linux does this just fine, although I haven't
>> determined if it's through the EC or ACPI...I am thinking EC however.
>>
>> I have a feeling the answer to brightness (aside from KMS patch for X,
>> which is seperate) might be comparing changelogs for thinkpad ec
>> handlers on a platform that works like Linux...the code looks mostly
>> similar...can anyone confirm if Open/NetBSD have issues with the
>> backlight on these SandyBridge thinkpads?
> The brightness work fine on Linux, but not on OpenBSD(-CURRENT).
>
> But on OpenBSD xbacklight (which uses randr) works to set the brightness
> once in X. This unfortunately does not work on FreeBSD (receiving "No
> outputs have backlight property" when running xbacklight).
>
>
> Cheers,
>
> Hannes
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
I got 10-CURRENT installed on the x220 again.

1. Standard GENERIC kernel
2. Buildworld/installworld from today's CVS
3. No DRM/KMS patches or any other "factors"
4. Witness KDB disabled in loader.conf (otherwise panic on suspend).
5. setting hw.pci.do_power_suspend=0 wil prevent some AE_NO_METHOD
errors where it tries to set PCI express ports to D2 (the ports
themselves, I think...not the attached device)

This is what I've found as I investigate the backlight/resume issue. I
am not very good at understanding ASL, but here's what I see.

1. _WAK calls a number of display related methods
2. There are apparently brightness related calls here, as well as some
other video related calls
3. Some of this behavior depends on /VIGD, whatever that is.
4. The brightness calls seem to connect over LPC to the embedded controller
5. Some of the brightness methods check OSI for WIN7

I will add that iasl finds 35 errors in this fine piece of lenovo work.
However, none of the errors appear to be near _wak. I've attached an
acpidump asl if it helps anyone who has a better eye for ASL and
resume/brightness problems. I think we can control brightness at least
with acpi_video, it attaches but not correctly..."active=0"...I haven't
gone back over its source in comparison with ASL yet either. Probably
acpi_ibm will work also, as the acpi methods seem to just call the
embedded controller over the lpc bus? Unfortunately it seems something
has changed with the ec, as some of the data becomes corrupt when
acpi_ibm is loaded.

Resume obviously works fine in Win7, works 80-95% of the time in Linux
(seems like KMS fail when it doesn't resume on Linux), and it resumes
fine on FreeBSD except no video. No bad messages in logs after resume.

Matt