x220 notes

[matt]

On 04/01/12 22:49, Kevin Oberman wrote:
> 2012/4/1 Любомир Григоров<nm.knife at gmail.com>:
>> Well I can't do the brightness switching. acpi_call port is installed, but:
>>
>> # kldload acpi_call
>> kldload: can't load acpi_call: No such file or directory
>>
>> # acpi_call -p '\VBRC' -i 14
>> ioctl: Device not configured
>>
>> At least closing the lid turns off the monitor (not going to sleep), which
>> is OK to conserve energy when not using. I would like to be able to change
>> brightness, however. And have dimming.
>>
>> A minor problem, with the KMS Intel patch, when I log out of X (startx or
>> xfce4), screen goes black. I don't know if this is acpi related. I typed
>> reboot, and nothing happened. Using all.13.7-stable-9.patch with 9.0-STABLE.
> # cd /usr/ports/sysutils/acpi_call&&  make install clean
> # rehash
> # kld_load acpi_call
> # acpi_call -p '\VBRC' -i 5
Exactly...I'd like to add it does require appropriate kernel sources, 
something I discovered as I'm currently testing off a 4gb 
USB...appropriately to current discussions, /usr/obj 
/usr/ports/distfiles /tmp /var/run are all tmpfs :) (we'll see how that 
goes too!).

Some general followup/status of brightness:
The hotkeys are working just fine out of the box, at least as far as 
they seem to adjust the brightness value seen by acpi_video, however as 
we know this doesn't actually seem to do much.
There are a couple of branches in the ACPI code when brightness is 
called, one of which checks for integrated or discrete graphics (why I 
do not know as discrete is not an option).
If \VIGD returns 1 (which I think means graphics are integrated) it 
talks to the \_SB.PCI0.LPC.EC.BRNS method, which doesn't seem to do 
anything for us.
If \VIGD returns 0 (which I think would mean discrete graphics if 
available) it calls \VBRC
The above method simply bypasses the VIGD switch and calls \VBRC directly.

There are other ACPI methods which seem to be related, but I have yet to 
figure out what they mean...VBTC is one, and some _Q(X)(X) methods also 
seem to talk to the EC about the panel and brightness etc.

It seems like we need to find how to make the EC be in charge of 
brightness instead of whatever VBRC is doing (it's an SMI call). I think 
brightness might just work fine...another note is the fact that 
acpi_video sees lcd0 as inactive...not sure why.

Regarding acpi_ibm, it appears that it is also talking to the EC, which 
is why brightness cannot work there. Although for some reason, probably 
an alignment or address change, the fan speed appears corrupt after 
setting brightness via acpi_ibm, the fan controls still work fine in 
both manual and automatic as far as I can tell.

It seems like if we can determine why the EC does not care for 
brightness settings, or isn't in charge of brightness, that we would be 
a small patch away from fixing acpi_ibm for this model.

HOWEVER, it appears resume is now toast on CURRENT, since at least a few 
months, with or without Konstantin's patches. I'm not sure what's 
hanging, although setting suspend_beep=1 creates a horrible sound during 
the failing resume, which may indicate it's something fairly early in 
the resume, or even concurrent with "beeping". Even bounce does not 
work, and debugging is complicated by the lack of display.

If anyone has anyone ideas for fixing resume on CURRENT, we'd be awful 
close to having a pretty damn nice laptop for FreeBSD.

Matt