al/+bug/331361
options video brightness_switch_enabled=0
Maybe that is of some help.
--
Ben
--
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows.
the compatibility table at
<http://ibm-acpi.sourceforge.net/> suggests I'm in uncharted territory.
I'm happy to help fill that table in of there are specific tests you'd
like me to run. Or is this a more informal process of doing whatever it
is I think I should do
I have retested using the latest thinkpad-acpi-0.18-20071203 release;
sorry for not doing that at the outset. This version avoids creating
the /sys/class/backlight/thinkpad_screen device. However, the other
glitches I originally reported remain:
- two devices in /sys/class/backlight for
Henrique, thank you for your speedy and informative reply.
I wrote
> - acpi_video1 works well, except that levels 0-19 are no-ops
Henrique de Moraes Holschuh replied:
> Lenovo BIOS bug, you can (and should!) open a technical support
> request with them, complaining about it. But make sure
Given Henrique's reply that the glitches I'm seeing are mainly kernel
ACPI video bugs, I now have the video module blacklisted and am loading
thinkpad_acpi 0.18-20071203 with brightness_enable=1.
I see a "/sys/class/backlight/thinkpad_screen" device directory, with
"brightness" and "actual_brig
Henrique de Moraes Holschuh wrote:
> In fact, the "simple interfaces" for led and brightness control
> through sysfs are incomplete and a major pain in the ass.
Well, the glitch I'm seeing affects
/sys/class/backlight/thinkpad_screen/{actual_brightness,brightness} and
/proc/acpi/ibm/brightness i
> Do you have the ACPI video.c driver loaded, perchance?
No. That module is blacklisted. I confirm that "lsmod | fgrep video"
shows no such module loaded.
> Also, make sure acpid is not loaded (thinkpad-acpi doesn't need it, and
> something in userspace might be hooked to it).
I see the kerne
Henrique de Moraes Holschuh wrote:
> I will fine-comb it looking for what we could be doing wrong in
> thinkpad-acpi, because it really looks like there's a bug in thinkpad-acpi
> somewhere.
Remember though that the brightness keys stop working once the kernel is
running even if thinkpad-acpi has
> Here's a patch that will cause thinkpad-acpi 0.18-20071203 (for
> 2.6.23, but should apply on others too) to print the contents of
> NBCF, which is the "brightness in ACPI mode" variable. Please tell
> me what it says.
acpi_evalf(NBCF, d, ...) failed: 4097
The ThinkPad reports NBCF (before pro
> Drat, must be an error in the patch (I can't run-test it, I don't have
> NBCF). Let me see if I can root out the problem...
OK, thanks. Feel free to contact me via private e-mail if you want to
try something more interactive, such as an IM/IRC/Skype session with me
running tests and feeding y
Henrique de Moraes Holschuh wrote:
> Where it reads in the patch "root_handle", change it to "NULL".
> Where it reads in the patch "NBCF", change it to "\\NBCF".
The ThinkPad reports NBCF (before probe) is 0
standard ACPI backlight interface available, not loading native one...
The ThinkPad report
Henrique de Moraes Holschuh wrote:
> No bugs, then. It is a Lenovo BIOS issue. Which doesn't mean we
> can't do anything about it (besides asking Lenovo for a fix), but I
> am not sure of what.
There must surely be *something* we can do about it, given that the
brightness controls work perfectl
hal:0.5.10-1.fc8
hal-info: 20071030-1.fc8
thinkpad_acpi: 0.18-20071203
Thanks!
-- Ben
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual
g is "ibm/hotkey HKEY 0080 1018", then what
should I mask on in /sys/devices/platform/thinkpad_acpi/hotkey_mask? Is
the mask value for this key 0x0080 or 0x1018? Or neither of the
above?
For what it's worth, hotkey_recommended_mask and hotkey_mask are
ow the right key mask, I tried "cat hotkey_all_mask >hotkey_mask" to
pull everything possible into the input system. But "xev" still shows
no KeyPress events under X, so presumably there's still something else I
need to do.
Thanks,
Ben
-
Henrique de Moraes Holschuh wrote:
> But you don't have to wait for fixes anywhere to use your backlight. Here's
> what you can do:
>
> 1. load latest thinkpad-acpi in whichever way you want (with or without
> backlight interface). It will work well enough, AFAIK.
>
> 2. load and then *UNLOAD*
Chris Hanson wrote:
> Short answer: your mask is correctly adjusted.
OK, thanks!
Might I politely suggest that the thinkpad_acpi documentation should
also include an explanation such as this? The existing documentation
talks about masks quite a lot but never actually states that the mask is
2
e. If that 0x17 scan code is not arriving in the first
place, then the problem is with thinkpad_acpi or my configuration thereof.
> PS: Many thanks to Henrique for implementing the input features in
> thinkpad-acpi, nicely documenting it, and answering my questions as I
> was fig
Henrique de Moraes Holschuh wrote:
> I think you just need to tell X.org to add the thinkpad-acpi event
> device as a keyboard, and things should work. I have this in my
> xorg.conf:
Neat! But it doesn't quite work right. :-( I added the lines you
suggested, plus the following line in my "Ser
Henrique de Moraes Holschuh wrote:
> This is something you can probably help fix, by writing that keymap,
> actually. It uses the standard xorg XKB layer, and you can force
> evdev to use it.
I already see a "/usr/share/X11/xkb/keycodes/evdev" file which describes
itself as a "translation from
Henrique de Moraes Holschuh wrote:
> Yes, load thinkpad-acpi with that "brightness mode" report patch (the fixed
> version) *after* loading and unloading video. It should say that the
> variable now contains "1". Does it?
Yes, it does.
I'm loading thinkpad_acpi with brightness_enable=3. The fi
My X61 is running Fedora's 2.6.23.9-85.fc8 kernel, but with a newer
0.18-20071203 release of thinkpad_acpi.
*Without* "acpi_osi=Linux", the mute button toggles volume muting but is
*not* seen by software. *With* "acpi_osi=Linux", the mute button
toggles volume muting and *is* seen by software,
Andrew Barr wrote:
> In Debian there is a package called 'input-utils' [...]
>
> Perhaps Fedora has a similar package.
It does not.
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
Special thanks to Guo Yonggang for showing me where to find the source
code for these input system utilities. The following were recorded
using "acpi_osi=Linux". If I omit that, volume up and down remain the
same but mute no longer results in any input events.
ThinkPad model: Lenovo ThinkPad
For extra annoyance, xbacklight is not packaged by Fedora 8, the distro
I run. So if I blacklist video.ko and load thinkpad_acpi.ko with
brightness_enable=0, I have no backlight control whatsoever. :-(
Even if I did have some way to control the backlight, I'm not sure how
I'd trigger it. I'm
Jim Paris wrote:
> On my system, another hacky way to control the backlight (which seems
> to be the same thing the intel X driver does) is:
Wacky! :-D
I've also figured out that the following works, and doesn't require root
access:
% xrandr --output LVDS --set BACKLIGHT ###
where "##
that case.
However, without acpi video the keys are unmasked, so keypresses
generate two brightness changes -- one from the firmware and one from
userspace.
It seems like the brightness keys should always be masked on this type
of firmware.
-Ben J
touch-button in the glass on the front of the
device, there is no response, but upon release the intel-vbtn driver reports:
[20312.415460] intel-vbtn INT33D6:00: unknown event index 0xc2
[20312.415519] intel-vbtn INT33D6:00: unknown event index 0xc3
Is there anything I can do to help
no response, but upon release the intel-vbtn driver
> reports: [20312.415460] intel-vbtn INT33D6:00: unknown event index 0xc2
> [20312.415519] intel-vbtn INT33D6:00: unknown event index 0xc3
>
> Is there anything I can do to help out?
>
> Thanks!
>
> - Ben
Pardon the immediate
29 matches
Mail list logo
