ACPI brightness events no longer work on ThinkPad T61

Some external references:

http://www.justlinux.com/forum/showthread.php?p=883138
http://www.nabble.com/T61-Brightness-keys-with-2.6.26-not-working-(NVIDIA)-td18577619.html

Documentation/laptops/thinkpad-acpi.txt says:

0x1010 0x0F FN+HOME Brightness up. This key is
                                always handled by the firmware
                                in IBM ThinkPads, even when
                                unmasked. Just leave it alone.
                                For Lenovo ThinkPads with a new
                                BIOS, it has to be handled either
                                by the ACPI OSI, or by userspace.
0x1011 0x10 FN+END Brightness down. See brightness
                                up for details.

(my laptop is of the "Lenovo ThinkPad with a new BIOS" variety)

http://<email address hidden>/msg00657.html

Writing values to /proc/acpi/VID1/LCD0/brightness works (though VID/LCD0/brightness seems to do nothing...why are there two?)

Aha...when I press the hotkeys, I can see the value in /proc/acpi/VID/LCD0/brightness change (the one which does nothing). So it's twiddling the wrong one (or there's an extra one when there shouldn't be).

This looks relevant:

http://osdir.com/ml/linux.acpi.ibm-acpi.devel/2007-10/msg00102.html

Recent Lenovo ThinkPads define a dummy grahpics device, find it and ignore it

Those laptops define one grahpics device on a PCI Express (e.g. Internal Intel
965 card) and one on a separate PCI bus (via a PCI root bridge, e.g. in AGP
case for an Nvidia graphics card).
PCI devices need to be enumerated and checked whether on the ACPI video device
a graphics card is really connected to.

This patch only checks whether a PCI device exists (could also be a PCI bridge).
To really get the pci_dev struct and check it whether it really is of class
"graphics card" or to further make use of it in this driver, it must be checked
what got set up behind a possilbe bridge.

Signed-off-by: Thomas Renninger <trenn@xxxxxxx>

I rebooted into 2.6.24 and the problem persists, so I don't think this is strictly a kernel issue. Looking at g-p-m now.

gnome-power-manager --verbose says that it is grabbing the right keycodes:

TI:11:55:04 TH:0x650a00 FI:gpm-button.c FN:gpm_button_grab_keystring,152
 - Grabbed modmask=0, keycode=233
TI:11:55:04 TH:0x650a00 FI:gpm-button.c FN:gpm_button_grab_keystring,152
 - Grabbed modmask=0, keycode=232

which matches xev:

    state 0x10, keycode 232 (keysym 0x1008ff03, XF86MonBrightnessDown), same_screen YES,
    state 0x10, keycode 233 (keysym 0x1008ff02, XF86MonBrightnessUp), same_screen YES,

but somehow gnome-power-manager doesn't seem to respond.

perseus:[~] cat /proc/acpi/ibm/hotkey
status: enabled
mask: 0x008c7fff
commands: enable, disable, reset, <mask>

The gpm brightness applet does work, so gpm's logic for setting the brightness (and whatever it calls out to...xrandr?) is working.

Starting to look like a hal issue, moving there...

I can see the events being received by hald-addon-acpi (using strace), but there's nothing in lshal -m

I can see /sys/devices/virtual/backlight/acpi_video[01]/actual_brightness change when I press the keys, just as /proc/acpi/video/VID/LCD0/brightness does. However there doesn't seem to be anything in sysfs corresponding to /proc/acpi/video/VID1/LCD0/brightness (the one which works).

Looking like a kernel problem again?

Writing to acpi_video0/brightness does nothing, but writing to acpi_video1 successfully changes the brightness. is this the interface which hal should be using?

Please, see this bug report and check if you have the same behavior:

   https://bugs.launchpad.net/ubuntu/+bug/279766

On Thu, Oct 09, 2008 at 12:28:02PM -0000, Marc Jauvin wrote:
> Please, see this bug report and check if you have the same behavior:
>
> https://bugs.launchpad.net/ubuntu/+bug/279766

That doesn't seem related; my num lock is off and turning it on doesn't
change my symptoms.

--
 - mdz

OK, but try deleting the file I mention in ~/.gconf along with
~/.gconfd/saved_state and do a logout/login. If you've got the same
behavior as I do, this should restore your hotkeys (until you enable
Numlock again).

Matt Zimmerman <email address hidden> wrote:

> On Thu, Oct 09, 2008 at 12:28:02PM -0000, Marc Jauvin wrote:
>> Please, see this bug report and check if you have the same behavior:
>>
>> https://bugs.launchpad.net/ubuntu/+bug/279766
>
> That doesn't seem related; my num lock is off and turning it on doesn't
> change my symptoms.
>
> --
> - mdz
>
> --
> ACPI brightness events no longer work on ThinkPad T61
> https://bugs.launchpad.net/bugs/280646
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “hal” source package in Ubuntu: Triaged
>
> Bug description:
> Binary package hint: gnome-power-manager
>
> [regression from 8.04]
>
> I'm not sure about the root cause of this yet, but starting here.
>
> Pressing the brightness up/down keys on my ThinkPad T61 no longer
> changes the brightness of the LCD backlight. This worked fine in
> 8.04, and at some point in Intrepid as well.
>
> When I press the brightness-up key, I see two ACPI events:
> video LCD0 00000086 00000000
> ibm/hotkey HKEY 00000080 0000501
>
> brightness-down is similar:
> video LCD0 00000087 00000000
> ibm/hotkey HKEY 00000080 0000501
>
> In xev, I see KeyPress and KeyRelease events forXF86MonBrightnessUp
> and XF86MonBrightnessDown, respectively.
>
> However, the backlight is not actually changed, and
> gnome-power-manager does not display the brightness level OSD (both
> of which worked in 8.04)
>
> ProblemType: Bug
> Architecture: amd64
> DistroRelease: Ubuntu 8.10
> Package: linux-image-2.6.27-5-generic 2.6.27-5.8 [modified:
> lib/modules/2.6.27-5-generic/modules.pcimap
> lib/modules/2.6.27-5-generic/modules.dep
> lib/modules/2.6.27-5-generic/modules.ieee1394map
> lib/modules/2.6.27-5-generic/modules.usbmap
> lib/modules/2.6.27-5-generic/modules.isapnpmap
> lib/modules/2.6.27-5-generic/modules.inputmap
> lib/modules/2.6.27-5-generic/modules.seriomap
> lib/modules/2.6.27-5-generic/modules.alias
> lib/modules/2.6.27-5-generic/modules.symbols]
> ProcCmdLine: root=UUID=305dde78-d20a-4248-aaf4-09447b7c5791 ro quiet splash
> ProcEnviron:
> LC_COLLATE=C
>
> PATH=/home/username/bin:/usr/lib/ccache:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/sbin:/usr/sbin:/usr/games:/usr/lib/surfraw
> LANG=en_US.UTF-8
> SHELL=/bin/zsh
> ProcVersionSignature: Ubuntu 2.6.27-5.8-generic
> SourcePackage: linux
>

--
Marc Jauvin
514-905-6500
http://register4less.com

On Thu, Oct 09, 2008 at 04:30:48PM -0000, Marc Jauvin wrote:
> OK, but try deleting the file I mention in ~/.gconf along with
> ~/.gconfd/saved_state and do a logout/login. If you've got the same
> behavior as I do, this should restore your hotkeys (until you enable

Oh, thanks for clarifying.

I just tested in a guest session (which would have all default gconf
settings) and noticed that the brightness keys work there!

I'll test clearing out that file as well.

--
 - mdz

Confirmed, deleting .gconf/desktop/gnome/peripherals/keyboard/host-perseus/0/%gconf.xml and starting a new session got it working again. Thanks for that data point.

Now to find out why that setting affects it...

Part of the problem appears to be that this gconf key gets set to true when num lock is turned on, and then never set back to false when num lock is turned off.

perseus:[~] gconftool-2 --get /desktop/gnome/peripherals/keyboard/host-perseus/0/numlock_on
false
perseus:[~] # press num lock
perseus:[~] gconftool-2 --get /desktop/gnome/peripherals/keyboard/host-perseus/0/numlock_on
true
perseus:[~] # press num lock
perseus:[~] gconftool-2 --get /desktop/gnome/peripherals/keyboard/host-perseus/0/numlock_on
true

The only way to set it back to false is manually with gconf.

Unsetting /desktop/gnome/peripherals/keyboard/remember_numlock_state doesn't seem to help...

Further debugging on #ubuntu-devel has revealed that gnome-settings-daemon listens for numlock keypresses (by listening for every key event) and sets the gconf key.

I have also discovered that, snooping with xev, I see a KeyPress event for num lock when the state is off (i.e. when turning num lock on) but NOT when turning it off.

This may point to an xkeyboard-config issue...

I can reproduce the problem on the console, using "sudo input-events 1":

/dev/input/event1
   bustype : BUS_I8042
   vendor : 0x1
   product : 0x1
   version : 43860
   name : "AT Translated Set 2 keyboard"
   phys : "isa0060/serio0/input0"
   bits ev : EV_SYN EV_KEY EV_MSC EV_LED EV_REP

I get a num lock event the first time I press it (to turn it on), but not the second (to turn it off). So it seems the event is not being generated by the kernel.

This is what I see in xev when toggling then NumLock key on and then off:

[Toggle ON]
KeyPress event, serial 33, synthetic NO, window 0x4000001,
    root 0x7b, subw 0x0, time 67170208, (104,59), root:(175,141),
    state 0x0, keycode 77 (keysym 0xff7f, Num_Lock), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

PropertyNotify event, serial 33, synthetic NO, window 0x4000001,
    atom 0x1ac (XKLAVIER_STATE), time 67170212, state PropertyNewValue

KeyRelease event, serial 33, synthetic NO, window 0x4000001,
    root 0x7b, subw 0x0, time 67170289, (104,59), root:(175,141),
    state 0x10, keycode 77 (keysym 0xff7f, Num_Lock), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

[Toggle OFF]
KeyPress event, serial 33, synthetic NO, window 0x4000001,
    root 0x7b, subw 0x0, time 67179879, (104,59), root:(175,141),
    state 0x10, keycode 77 (keysym 0xff7f, Num_Lock), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

PropertyNotify event, serial 33, synthetic NO, window 0x4000001,
    atom 0x1ac (XKLAVIER_STATE), time 67179882, state PropertyNewValue

KeyRelease event, serial 33, synthetic NO, window 0x4000001,
    root 0x7b, subw 0x0, time 67179975, (104,59), root:(175,141),
    state 0x10, keycode 77 (keysym 0xff7f, Num_Lock), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

Andreas Hasenack pointed out on IRC that, on Ubuntu 8.04, his brightness keys do work (as I reported as well), but he is also able to reproduce the num_lock misbehaviour. So it appears that the num lock / gconf issue may be old, but that something new has caused the brightness keys to stop working when that gconf key is set.

I rebooted into 2.6.24 and confirmed (via input-events) that I see a num lock event on the first press and not on the second, so that issue is older.

Since the num lock bug is old, I'm trying to work out why the brightness keys don't work when that gconf key is set.

When numlock_on is false, gnome-power-manager sees KeyPress events for the brightness keys in gpm_button_filter_x_events and responds.

When numlock_on is true, gpm_button_filter_x_events is never even called.

The callback is registered like this:

                /* use global filter */
                gdk_window_add_filter (button->priv->window,
                                       gpm_button_filter_x_events, (gpointer) button);

Notably, I don't see anything in "lshal -m" when I press the brightness keys, regardless of whether numlock_on=false (works) or numlock_on=true (doesn't work)

I've noticed that gnome-settings-daemon seems to propagate the numlock state from the gconf key to X via XkbLockModifiers. This explains why toggling the gconf key changes the behaviour even though nothing is actually looking at the gconf key.

Andreas reports that, on 8.04 (where everything works correctly), he sees events in hal:

andreas@nsn2:~$ lshal -m

Start monitoring devicelist:
-------------------------------------------------
15:38:53.978: computer_logicaldev_input_2 condition ButtonPressed = brightness-down
15:38:53.983: computer_logicaldev_input_0 condition ButtonPressed = brightness-down
15:38:55.159: computer_logicaldev_input_0 condition ButtonPressed = brightness-up
15:38:56.195: computer_logicaldev_input_0 condition ButtonPressed = brightness-down
15:38:56.198: computer_logicaldev_input_2 condition ButtonPressed = brightness-down

while on Intrepid on the same hardware, he sees no such events (but the brightness keys still work!).

Bryce has reproduced the problem on a different laptop, where (although his brightness is handled in hardware) when numlock is on, gnome-power-manager doesn't receive the appropriate events, and the OSD doesn't display

I've made a few packages/patches for debugging purposes:

  http://bryceharrington.org/ubuntu/EvdevBug280646/

 x11-xkb-utils-xkbwatch-dbg.patch - modifies xkbwatch to print changes to stdout

        *~instrumented* - Instruments -evdev to print out the keys (code=) and the action value (0=keyup, 1=keydown, 2=chorded-with-another-key)

        *git20081009* - Git snapshot of current -evdev code (without any of the ubuntu/debian patches applied).

Fwiw, this is what I see in my /var/log/Xorg.0.log with the instrumented package:

Tap num_lock:
(II) [bwh] Posting keyboard event code=77, value=1...
(II) [bwh] Posting keyboard event code=77, value=0...

Fn+ARROWUP (brightness up):
(II) [bwh] Posting keyboard event code=233, value=1...
(II) [bwh] Posting keyboard event code=233, value=1...
(II) [bwh] Posting keyboard event code=233, value=0...
(II) [bwh] Posting keyboard event code=233, value=1...
(II) [bwh] Posting keyboard event code=233, value=0...
(II) [bwh] Posting keyboard event code=233, value=0...
(II) [bwh] Posting keyboard event code=233, value=1...
(II) [bwh] Posting keyboard event code=233, value=0...

Backtrace from gnome-power-manager on gpm_button_filter_x_events with numlock off:

#0 gpm_button_filter_x_events (xevent=0xbf9ce898, event=0x81774f8, data=0x81ac5b8)
    at gpm-button.c:79
#1 0xb7702679 in gdk_event_translate (display=0x8175000, event=0x81774f8,
    xevent=0xbf9ce898, return_exposes=0)
    at /build/buildd/gtk+2.0-2.14.3/gdk/x11/gdkevents-x11.c:991
#2 0xb77040c3 in _gdk_events_queue (display=0x8175000)
    at /build/buildd/gtk+2.0-2.14.3/gdk/x11/gdkevents-x11.c:2276
#3 0xb77044ef in gdk_event_dispatch (source=0x817a7d0, callback=0, user_data=0x0)
    at /build/buildd/gtk+2.0-2.14.3/gdk/x11/gdkevents-x11.c:2364
#4 0xb71d16f8 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#5 0xb71d4da3 in ?? () from /usr/lib/libglib-2.0.so.0
#6 0xb71d52c2 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#7 0x08068c92 in main (argc=2, argv=0x145e) at gpm-main.c:268

-evdev sees the same output regardless of whether numlock is on or off:

Brightness key down:
(II) [bwh] Posting keyboard event code=232, value=1...
(II) [bwh] Posting keyboard event code=232, value=1...
(II) [bwh] Posting keyboard event code=232, value=0...
(II) [bwh] Posting keyboard event code=232, value=1...
(II) [bwh] Posting keyboard event code=232, value=0...
(II) [bwh] Posting keyboard event code=232, value=0...
(II) [bwh] Posting keyboard event code=232, value=1...
(II) [bwh] Posting keyboard event code=232, value=0...

Toggle numlock on:
(II) [bwh] Posting keyboard event code=77, value=1...
(II) [bwh] Posting keyboard event code=77, value=0...

Brightness key down:
(II) [bwh] Posting keyboard event code=232, value=1...
(II) [bwh] Posting keyboard event code=232, value=1...
(II) [bwh] Posting keyboard event code=232, value=0...
(II) [bwh] Posting keyboard event code=232, value=1...
(II) [bwh] Posting keyboard event code=232, value=0...
(II) [bwh] Posting keyboard event code=232, value=0...
(II) [bwh] Posting keyboard event code=232, value=1...
(II) [bwh] Posting keyboard event code=232, value=0...

Toggle numlock back off:
(II) [bwh] Posting keyboard event code=77, value=1...
(II) [bwh] Posting keyboard event code=77, value=0...

Weird, here's my xev output:

keycode 36 = (keysym 0xff0d, Return)

Brightness down:
keycode 8 =
keycode 8 =
keycode 8 =
keycode 8 =
keycode 8 =
keycode 8 =
(OCD displays)

Numlock:
keycode 77 = (keysym 0xff7f, Num_Lock)
keycode 77 = (keysym 0xff7f, Num_Lock)

Brightness down:
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown)
keycode 8 =
keycode 8 =
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown)
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown)
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown)
keycode 8 =
keycode 8 =
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown)
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown)
keycode 8 =
keycode 8 =
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown)
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown)
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown)
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown)
(OCD did not display)

Numlock:
keycode 77 = (keysym 0xff7f, Num_Lock)
keycode 77 = (keysym 0xff7f, Num_Lock)

Here is output from xmond sitting between the X server and gnome-power-manager. I did brightness-down, numlock, brightness-down.

In the first case, it printed a whole slew of output (including all the opcode 152 stuff), in the second cases it only printed a few lines (the opcode 95 stuff).

With -verbose=4

1. The problem with g-p-m not handling the brightness key when numlock is set is in fact an issue local to gnome-power-manager. It's simply neglects to grab the modifiers for the keys.

The first line of the attached patch makes the issue go away (the rest of the patch is just instrumentation). No changes to X are required; it seems to be working properly.

2. On the Thinkpad T61 specific issue, I discussed it with Peter Hutterer. It seems to be that on this hardware, the numlock key doesn't actually send events when the fn is pressed so we have no way of knowing that it is pressed. This was verified via gdb on the xserver. Scroll lock and numlock are shared, so fn has to be pressed to trigger numlock.

So it seems to be either a hardware or kernel bug.

Brightness up/down works for me on Lenovo X60s with intrepid beta - OSD stops working after NumLock.
Brightness changes are very slow (1 second).

Most Hotkeys work - still no OSD for the volume control keys ...

On Fri, Oct 10, 2008 at 01:50:49AM -0000, Bryce Harrington wrote:
> 1. The problem with g-p-m not handling the brightness key when numlock
> is set is in fact an issue local to gnome-power-manager. It's simply
> neglects to grab the modifiers for the keys.
>
> The first line of the attached patch makes the issue go away (the rest
> of the patch is just instrumentation). No changes to X are required; it
> seems to be working properly.

Thanks for the analysis, Bryce. I'm attaching a debdiff which implements
that change. I don't see any cases in the code where it would be
appropriate to treat these keysyms differently with a modifier, since
they're all special-purpose hotkeys:

  gpm_button_xevent_key (button, XF86XK_PowerOff, GPM_BUTTON_POWER);
  gpm_button_xevent_key (button, XF86XK_Sleep, GPM_BUTTON_SUSPEND); /* should be configurable */
  gpm_button_xevent_key (button, XF86XK_MonBrightnessUp, GPM_BUTTON_BRIGHT_UP);
  gpm_button_xevent_key (button, XF86XK_MonBrightnessDown, GPM_BUTTON_BRIGHT_DOWN);
  gpm_button_xevent_key (button, XF86XK_ScreenSaver, GPM_BUTTON_LOCK);
  gpm_button_xevent_key (button, XF86XK_KbdBrightnessUp, GPM_BUTTON_KBD_BRIGHT_UP);
  gpm_button_xevent_key (button, XF86XK_KbdBrightnessDown, GPM_BUTTON_KBD_BRIGHT_DOWN);
  gpm_button_xevent_key (button, XF86XK_KbdLightOnOff, GPM_BUTTON_KBD_BRIGHT_TOGGLE);

> 2. On the Thinkpad T61 specific issue, I discussed it with Peter
> Hutterer. It seems to be that on this hardware, the numlock key doesn't
> actually send events when the fn is pressed so we have no way of knowing
> that it is pressed. This was verified via gdb on the xserver. Scroll
> lock and numlock are shared, so fn has to be pressed to trigger numlock.
>
> So it seems to be either a hardware or kernel bug.

I will open that one as a separate bug.

--
 - mdz

There is a package in my PPA with this patch:

https://edge.launchpad.net/~mdz/+archive

deb http://ppa.launchpad.net/mdz/ubuntu intrepid main
deb-src http://ppa.launchpad.net/mdz/ubuntu intrepid main

I haven't been able to test it on the T61 yet, but would appreciate regression testing nonetheless.

This bug was fixed in the package gnome-power-manager - 2.24.0-0ubuntu4

---------------
gnome-power-manager (2.24.0-0ubuntu4) intrepid; urgency=low

  * src/gpm-button.c:gpm_button_grab_keystring: use AnyModifier modmask with
    XGrabKey so that hotkeys being handled through gpm-button still work if
    e.g. numlock happens to be on (thanks, Bryce Harrington, LP: #280646)

 -- Matt Zimmerman <email address hidden> Fri, 10 Oct 2008 09:55:10 +0100

Hi Matt, since I did this upgrade, keyboard and mouse don't work after
I rebooted... not sure if this is caused by your updated package (or
one of their dependency like xinput).

I'm currently writing this from Hardy since my Intrepid install is
unusable... ;)

Matt Zimmerman <email address hidden> wrote:

> There is a package in my PPA with this patch:
>
> https://edge.launchpad.net/~mdz/+archive
>
> deb http://ppa.launchpad.net/mdz/ubuntu intrepid main
> deb-src http://ppa.launchpad.net/mdz/ubuntu intrepid main
>
> I haven't been able to test it on the T61 yet, but would appreciate
> regression testing nonetheless.
>
> --
> ACPI brightness events no longer work on ThinkPad T61
> https://bugs.launchpad.net/bugs/280646
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “gnome-power-manager” source package in Ubuntu: Triaged
> Status in “linux” source package in Ubuntu: Triaged
>
> Bug description:
> Binary package hint: gnome-power-manager
>
> Problem:
> The state of the numlock key affects how the brightness switching
> keys work. The OCD display does not display. On some systems (e.g.
> Thinkpad 61's), it also prevents brightness from changing. This
> seems to be a new behavior in Intrepid, and not reproducible on Hardy
>
> A further issue on Thinkpad T61's is that the numlock key does not
> signal toggle off properly. This can be seen in xkbwatch, which
> shows that some modifiers are not getting turned off when numlock is
> toggled off.
>
> Original Report:
> [regression from 8.04]
>
> I'm not sure about the root cause of this yet, but starting here.
>
> Pressing the brightness up/down keys on my ThinkPad T61 no longer
> changes the brightness of the LCD backlight. This worked fine in
> 8.04, and at some point in Intrepid as well.
>
> When I press the brightness-up key, I see two ACPI events:
> video LCD0 00000086 00000000
> ibm/hotkey HKEY 00000080 0000501
>
> brightness-down is similar:
> video LCD0 00000087 00000000
> ibm/hotkey HKEY 00000080 0000501
>
> In xev, I see KeyPress and KeyRelease events forXF86MonBrightnessUp
> and XF86MonBrightnessDown, respectively.
>
> However, the backlight is not actually changed, and
> gnome-power-manager does not display the brightness level OSD (both
> of which worked in 8.04)
>
> WORKAROUND: gconftool-2 --set --type bool
> /desktop/gnome/peripherals/keyboard/host-perseus/0/numlock_on false
>
> ProblemType: Bug
> Architecture: amd64
> DistroRelease: Ubuntu 8.10
> Package: linux-image-2.6.27-5-generic 2.6.27-5.8 [modified:
> lib/modules/2.6.27-5-generic/modules.pcimap
> lib/modules/2.6.27-5-generic/modules.dep
> lib/modules/2.6.27-5-generic/modules.ieee1394map
> lib/modules/2.6.27-5-generic/modules.usbmap
> lib/modules/2.6.27-5-generic/modules.isapnpmap
> lib/modules/2.6.27-5-generic/modules.inputmap
> lib/modules/2.6.27-5-generic/modules.seriomap
> lib/modules/2.6.27-5-generic/modules.alias
> lib/modules/2.6.27-5-generic/modules.symbols]
> ProcCmdLine: root=UUID=305dde78-d20a-4248-aaf4-09447b7c5791 ro quiet splash
> ProcEnviron:
> LC_COLLATE=C
>
> PATH=/home/username/bin:/usr/lib/ccache:/usr/local/bi...

On Fri, Oct 10, 2008 at 04:17:00PM -0000, Marc Jauvin wrote:
> Hi Matt, since I did this upgrade, keyboard and mouse don't work after
> I rebooted... not sure if this is caused by your updated package (or
> one of their dependency like xinput).
>
> I'm currently writing this from Hardy since my Intrepid install is
> unusable... ;)

I don't see how this change could cause that; it certainly doesn't break my
keyboard or mouse (I'm running with it right now).

Did you upgrade your kernel at the same time?

Please let us know if you can isolate the problem, regardless of whether
it's related to this bug.

--
 - mdz

I've confirmed the fix on my T61 with gnome-power-manager 2.24.0-0ubuntu4 in Intrepid.

Closing out the linux task; this is not a kernel bug.

I have filed bug 281669 about the sticky num lock key (Bryce's issue #2 in https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/280646/comments/41)

On Fri, 2008-10-10 at 16:17 +0000, Marc Jauvin wrote:
> Hi Matt, since I did this upgrade, keyboard and mouse don't work after
> I rebooted... not sure if this is caused by your updated package (or
> one of their dependency like xinput).

This is likely to be the same as this bug:

   https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/276857

Basically the work around is to restart X on reboot after HAL starts. I
have to do it on every login.

  --Ted

Ted Gould <email address hidden> wrote:

> On Fri, 2008-10-10 at 16:17 +0000, Marc Jauvin wrote:
>> Hi Matt, since I did this upgrade, keyboard and mouse don't work after
>> I rebooted... not sure if this is caused by your updated package (or
>> one of their dependency like xinput).
>
> This is likely to be the same as this bug:
>
> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/276857
>
> Basically the work around is to restart X on reboot after HAL starts. I
> have to do it on every login.

It turns out there were two packages that had been removed on the last
upgrade... not sure why:

    xserver-xorg-input-evdev
    xserver-xorg-input-synaptics

Once they were reinstalled, everything started working again, and the
brightness problem was solved by Matt's update to gnome-power-manager.

Thanks.

--
Marc Jauvin