On 04/01/12 22:49, Kevin Oberman wrote:
2012/4/1 Любомир Григоров<nm.kn...@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
_______________________________________________
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
