Ubuntu

[Intrepid] Losing keyboard and mouse control when changing screen brightness with fn + arrow (Dell)

Reported by Saivann Carignan on 2008-10-18
224
This bug affects 34 people
Affects Status Importance Assigned to Milestone
Release Notes for Ubuntu
Undecided
Unassigned
gnome-power
Invalid
Unknown
acpid (Ubuntu)
Undecided
Unassigned
Intrepid
Undecided
Unassigned
gnome-power-manager (Ubuntu)
Medium
Ted Gould
Intrepid
Medium
Ted Gould
linux (Ubuntu)
Undecided
Unassigned
Intrepid
Medium
Unassigned
xserver-xorg-input-evdev (Ubuntu)
Undecided
Bryce Harrington
Intrepid
Undecided
Bryce Harrington

Bug Description

On my Dell inspiron 9300 laptop under intrepid (hardy did not have this problem), when I type FN + Arrow keys to change the screen brightness, Most of mouse and keyboard keys stop working.

For an example : I can't type any text anywhere, ALT + F4 does not close any window, mouse clicks "partially" opens the gnome-panel menus, isn't able to close windows with the right-top x, but mouse click is still able to move a window..

screencast : http://upload.leservicetechnique.com/bugs/mouse_keyboard_acpid.ogv

This bug is reproducible under both metacity and compiz, and not caused by a BIOS password.

A quick workaround to bring back things to normal is to switch to a VT and go back to Xorg with CTRL + ALT + F6 and CTRL + ALT + F7

When changing screen brightness, I get this in Xorg.0.log :

(II) AIGLX: Suspending AIGLX clients for VT switch
(II) Open ACPI successful (/var/run/acpid.socket)
(II) AIGLX: Resuming AIGLX clients after VT switch
(II) AlpsPS/2 ALPS GlidePoint: x-axis range 0 - 1023
(II) AlpsPS/2 ALPS GlidePoint: y-axis range 0 - 767
(--) AlpsPS/2 ALPS GlidePoint touchpad found
(II) Macintosh mouse button emulation: Device reopened after 10 attempts.
(**) Macintosh mouse button emulation: YAxisMapping: buttons 4 and 5
(**) Macintosh mouse button emulation: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
(II) PS/2 Mouse: Device reopened after 10 attempts.
(**) PS/2 Mouse: YAxisMapping: buttons 4 and 5
(**) PS/2 Mouse: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
(II) AT Translated Set 2 keyboard: Device reopened after 10 attempts.
(II) Video Bus: Device reopened after 10 attempts.

Saivann Carignan (oxmosys) wrote :
Saivann Carignan (oxmosys) wrote :
Saivann Carignan (oxmosys) wrote :
Saivann Carignan (oxmosys) wrote :

I'd like to add that my laptop often takes around 2 minutes to shutdown because it waits a very long time for acpid. Might be related to the same problem.

hrushikesh (hrushikesh) wrote :

Probably I am experiencing a similar bug on my Dell M1330: my keyboard becomes non-responsive in X after using any of the keyboard shortcuts (volume, brightness, etc.)

However, unlike Saïvann Carignan, I don't have any problems with shutdowns.

hrushikesh (hrushikesh) wrote :

Strangely, just switching to the text terminal (Ctrl-Alt-F1) and back (Alt-F1) seems to get the keyboard working again!

Saivann Carignan (oxmosys) wrote :

hrushikesh : Thanks for your feedback. Can you boot your computer, reproduce the bug and provide the files created by these 3 commands in a terminal?

dmesg > dmesg.log
sudo lspci -nnvv > lspci-nnvv.log
cat /var/log/Xorg.0.log > Xorg.0.log

Changed in acpid:
status: New → Confirmed
hrushikesh (hrushikesh) wrote :

Here you go:

hrushikesh (hrushikesh) wrote :
hrushikesh (hrushikesh) wrote :
Saivann Carignan (oxmosys) wrote :

Thank you for your fast answer. Changing status to Triaged and Importance to Medium.

Changed in acpid:
importance: Undecided → Medium
status: Confirmed → Triaged
Changed in xorg:
assignee: nobody → bryceharrington
Bryce Harrington (bryce) wrote :

By and large X is no longer involved in hotkey handling, however the new -evdev sometimes triggers weird conditions, so moving the xorg component to -evdev on that basis.

Changed in xorg:
importance: Undecided → High
status: New → Triaged

In the description you list log output that occurs when changing brightness. Does that output occur before or only after you do the vt switch workaround?

Saivann Carignan (oxmosys) wrote :

Bryce Harrington : The log outputs in the description appears *after* switching back to VT7 . I attach a modified Xorg.0.log that describes each of my actions followed by Xorg log outputs. This Xorg.0.log is on the same laptop opensource driver (not fglrx).

Saivann Carignan (oxmosys) wrote :

Bryce Harrington : Is there any task that should stay open for acpid, or this bug is entirely caused by evdev?

Bryce Harrington (bryce) wrote :

It should stay open for acpid. As I mentioned, by and large X is uninvolved with hotkey stuff now, so it's probably more likely to be in acpid or some other component than in X. But it needs deeper analysis to determine what component is at fault.

Especially since looking at your log, there isn't evidence that X is doing anything unusual at all when the hotkey is hit. The log's contents is entirely typical for performing a vt switch. In other words, so far there is no evidence that this is an X bug.

At the same time, there isn't evidence that it's *not* an X bug, so we can't yet close out the task. But if it is X, -evdev should be the starting point to examine, since that's the thing that has changed the most with respect to keyboard stuff. (It could also be xorg-server).

I'll post another comment with some debugging advice.

Bryce Harrington (bryce) wrote :

Some hotkeys are handled by gnome-power-manager. Others are handled elsewhere (e.g. in hardware).

Experiment with using the brightness keys at the vt console, with and without X running. Experiment with them in X but with gnome-power-manager shut off. Use xev to see what key codes (if any) X sees. Here's a xev command string that makes the xev easier to read:

xev | sed -n 's/^.*state \([0-9].*\), keycode *\([0-9]\+\) *\(.*\), .*$/keycode \2 = \3, state = \1/p'

More info on debugging hotkey issues is available at this link:

https://wiki.ubuntu.com/X/Troubleshooting#Problem involves missing support for some keyboard keys

If the problem is in a binary application like gnome-power-manager or pm-utils, you may find strace output of it to shed some light.

If it's a hal problem, then comparing lshal output before and after the brightness hotkey is hit might be worth looking at; in theory the lshal output should be identical, so if there is any difference it might hint that the problem lays deeper down.

On some systems there are scripts from acpi-support that play a role in handling the brightness keys. These are in /etc/acpi/. I have a Dell laptop too, and these scripts don't have an effect for me, so I'm guessing this is unlikely to be the case either for you, but I don't know the specifics of your hardware so it's certainly a possibility.

Hope this helps

Changed in xserver-xorg-input-evdev:
status: Triaged → Incomplete
Bryan Quigley (bryanquigley) wrote :

Killing gnome-power-manager appears to fix the issue. Will debug further. Should this be nominated for release?

Bryan Quigley (bryanquigley) wrote :

This is output from gnome-power-manager --verbose --no-daemon. All I did was run it, press the Fn-Arrow Key once. Then try to type. Then switch to VT, then switch back and kill it.

Bryan Quigley (bryanquigley) wrote :

lshal output does not change (used diff)

The brightness still changes with gnome-power-manager isn't running.
I can still change the brightness when the rest of the keyboard and menus stop working.

Bryan Quigley (bryanquigley) wrote :

xev only reports a keypress after switching to VT1 and then back to VT7.
It is:
keycode 233 = (keysym 0x1008ff02, XF86MonBrightnessUp), state = 0x0

Bryce Harrington (bryce) wrote :

Given the above, and that it starts behaving once gnome-power-manager is turned off, it's starting to sound like a bug in gnome-power-manager. I'm adding a task for that package.

Given that your hotkeys work but the rest of the keyboard doesn't, and that lshal output hasn't changed, it sort of sounds like something is stealing your keyboard device. Presumably X is able to reclaim it from doing a vtswitch. Not sure what would cause that.

Please attach your lshal output.

Bryan Quigley (bryanquigley) wrote :
jrav (jravac) wrote :

Can confirm-Similar prob on a Dell 6000 Laptop that had a clean Intrepid install, when i press fn + up/down, it does adjust screen brightness and brings up the brightness level indicator, but the indicator bar doesn't move up/down (unlike volume indicator). Also, after that, the keyboard will not register anything under x, except for more fn + keystrokes. Also, the trackpad works, but right click doesn't work properly.ll, except when i press fn + up/down, it does adjust screen brightness and brings up the brightness level indicator, but the indicator bar doesn't move up/down (unlike volume indicator). Also, after that, the keyboard will not register anything under x, except for more fn + keystrokes. Also, the mouse trackpad works, but right click doesn't work properly.

Saivann Carignan (oxmosys) wrote :

Bryce Harrington : I confirm the same as Bryan Quigley, killing gnome-power-manager is a workaround, the bug does not appears when gnome-power-manager isn't running. Is there additional informations we can provide?

Bryan Quigley (bryanquigley) wrote :

I went through and tested:

2.23.1-0ubuntu1 is the last one that worked (https://launchpad.net/ubuntu/+source/gnome-power-manager/2.23.1-0ubuntu1)

And 2.23.6-0ubuntu1 introduced this bug. (https://launchpad.net/ubuntu/+source/gnome-power-manager/2.23.6-0ubuntu1)

wildman4god (wildman4god) wrote :

I have a simalar problem with 8.10 on a dell latitude d600 everything is fine untill the brightness changes (wether i doit using fn+up/down or ubuntu aotu changes because i don't have the ac power adapter plugged in). Then no keyboard key work except ctrl+alt+backspace and the mouse buttons don't work, only mouse movements do. also when I change brightness with keyboard it changes but the brightness indicator panel doen't show and cpu usage goes straight to 100% and stays there, I am thinking it is haveing a problem opening the indicator panel. also can't change volume with keyboard before or after the main problem insues.

Changed in gnome-power-manager:
status: New → Confirmed
captaintrav (captaintrav) wrote :

I have been experiencing this as well with Intrepid on a D600 as well. In fact I didn't realize the problem was related to the use of Fn + hotkeys to change the brightness, until googling the issue. When the issue occurs, the menus in the panel will not open. Clicking the mouse will highlight the Application Places menu, etc, but it won't open until I switch a console and then back to X with ctrl-alt-f1, and ctrl-alt-f7. Clicking on some of the other icons in the panel will work, but results vary.

captaintrav (captaintrav) wrote :
captaintrav (captaintrav) wrote :
Saivann Carignan (oxmosys) wrote :

This regression appeared with revision 2857 of gnome power manager which fixed another similar regression introduced by revision 2845. Revision 2845 caused "g", "k" and ";" keys to stop working.

Revision 2857 :
--- trunk/src/gpm-button.c 2008/07/29 01:31:15 2856
+++ trunk/src/gpm-button.c 2008/08/01 08:39:15 2857
@@ -166,11 +166,19 @@
  * Return value: TRUE if we parsed and grabbed okay
  **/
 static gboolean
-gpm_button_xevent_key (GpmButton *button, guint keycode, const gchar *hal_key)
+gpm_button_xevent_key (GpmButton *button, guint keysym, const gchar *hal_key)
 {
  gchar *key = NULL;
  gboolean ret;
  gchar *keycode_str;
+ guint keycode;
+
+ /* convert from keysym to keycode */
+ keycode = XKeysymToKeycode (GDK_DISPLAY (), keysym);
+ if (keycode == 0) {
+ gpm_warning ("could not map keysym %x to keycode", keysym);
+ return FALSE;
+ }

  /* is the key string already in our DB? */
  keycode_str = g_strdup_printf ("0x%x", keycode);

Bryce Harrington (bryce) wrote :

Unfortunately I'm just the X guy, I'm not really intimately knowledgeable about what's going on inside gnome-power-manager so can't give much advice here on out.

It sort of feels like something is stealing the keyboard/mouse devices away from X, and then the vt-switch remaps things back together possibly. I'm not at all certain what could do this. On a lot of hardware there are separate devices for the keyboard, mouse, and hotkeys; on others these are mixed together in weird ways. I could vaguely guess that some weird combination could lead to things getting stolen from X in unexpected ways, but that's just a vague guess. It would show up by running `xinput list` and analyzing how the hardware's inputs are mapped.

Ted Gould (ted) wrote :

@Saïvann Carignan

Could you please grab a gpm.log with and without that patch?

It would seem to me that without that patch that GPM would ignore all keypresses that come as keysymbols. I'm curious if backing that is just stopping GPM from responding to brighness, not actually solving the problem.

Thank you.

Bryce Harrington (bryce) wrote :

Mario suggested that this bug may be related to #261721, and that testing against an earlier 2.6.24 kernel with the same version of gnome-power-manager may be of use to identify if g-p-m is not bugged.

Changed in acpid:
status: Triaged → Incomplete
Bryce Harrington (bryce) wrote :

I found one of my systems reproduces the issue consistently. Of interest, booted to root with no X, showkey does not show any output when hitting the brightness keys, however the brightness does change correctly.

Bryce Harrington (bryce) wrote :

On further analysis, it's only the key release event that doesn't produce output. Key down generates a keycode press.

And I see what's going on in X - it's not that the device itself is stolen, just the focus. The mouse still works (you can click on the firefox icon and launch it, interactic with its buttons, etc.) but you just can't get the keyboard focus returned to it.

I'm not seeing the OCD displayed when gnome-power-manager running, but the issue clearly occurs only when g-p-m is running, so it's looking fairly solidly that g-p-m is taking the keyboard focus on the keydown brightness key events, and hanging on to it expecting a keyup event which never comes.

So I think the key up/down handling logic in g-p-m needs additional thought in light of situations like this, where the kernel isn't passing up the key-release events.

I'm unclear of the role the patch for 280646 is playing here. I *think* it is not causing the bug, but rather exposing the situation where the bug occurs. My guess is that the patch enables g-p-m to handle the key when previously it ignored it and let the hardware handle it.

In any case, I think we need g-p-m folks to analyze this more thoroughly. Ted?

Bryce Harrington (bryce) wrote :

Since it's narrowed to be a kernel and g-p-m issue, we can eliminate -evdev at this point.

Changed in xserver-xorg-input-evdev:
status: Incomplete → Invalid
Changed in gnome-power-manager:
assignee: nobody → ted-gould
Saivann Carignan (oxmosys) wrote :

I tested this bug with 2.6.24 kernel and it remains the same, there is not change with different kernel.

Ted : Here are the logs. In gpm-intrepid.log, each time I typed "CTRL + C" to stop gdm, it didn't stop and I just got this in terminal, until I used the tty switch trick to recover full keyboard keys.

TI:22:47:04 TH:0x91f3640 FI:gpm-button.c FN:gpm_button_filter_x_events,117
 - Key 54 not found in hash

Saivann Carignan (oxmosys) wrote :
Bryan Quigley (bryanquigley) wrote :

Same symptons, different cause, and gpm not the problem:
https://bugs.launchpad.net/ubuntu/+bug/278781

Perhaps the root cause is the same between both?

Changed in gnome-power-manager:
milestone: none → intrepid-updates
Changed in acpid:
importance: Medium → High
importance: High → Medium
Changed in gnome-power-manager:
importance: Undecided → Medium
importance: Undecided → Medium
Changed in xserver-xorg-input-evdev:
importance: High → Undecided
importance: High → Undecided
Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Medium
milestone: none → intrepid-updates
status: New → Triaged
Changed in linux:
status: Triaged → Fix Committed
Changed in acpid:
importance: Medium → Undecided
status: Incomplete → Invalid
importance: Medium → Undecided
status: Incomplete → Invalid
Changed in gnome-power-manager:
status: Confirmed → Invalid
status: Confirmed → Invalid
91 comments hidden view all 171 comments
Michael Braun (n3ca88) wrote :

Also affecting me, Dell XPS M170 laptop.

Daniel Knittl-Frank (knittl) wrote :

brightness OSD is working since recent updates – at least when on battery, couldn't test with AC plugged in yet.
x-brightness applet still has some problems getting correct brightness level, but that is low priority i'd say

Dell Precision M4300

xrayA4T (xraya4t) wrote :

Can confirm the birghtness applet and OSD is working on my Dell Inspiron 6000 since I updated yesterday.
Ray

Nico (nico-rdo) wrote :

the new gnome-power-manager in -updates fixes the last OSD issue on my Dell Precision M65. So all loks good to me.

I expect my Dell Precision M4300 to react the same way. If not, I'll report back once tested.

Many thanks for the efforts devs!

Wirawan Purwanto (wirawan0) wrote :

I installed the newest gnome-power-manager (2.24.0-0ubuntu8.1) on my Dell Lattitude D600. The result was mixed (I am using xubuntu 8.10, BTW):

* Now I can see the OSD when adjusting the brightness up and down. However, the keyboard was still locked as a result of pressing Fn+Up or Fn+Dn.

* On one occasion I did not see the OSD, but somehow pressing Fn+Up or Fn+Dn did NOT lock my keyboard. I will find out how I could get to this situation.

Bryan Quigley (bryanquigley) wrote :

Tried with the latest 2.6.27-11-generic and all other updates and bug still exists for me.
Dell Latitude D600 (Manufacturer: Dell Computer Corporation)

MatB (matteo-brusa) wrote :

I have the same issue on a Dell precision M4300. It also happens when not using hotkeys, almost randomly, a few times a hour. Under both 32 and 64 bits.
As a side note, when the problem happens, i press ctrl-alt-F1 and the screen flickers to text mode, but very often comes back "by itself" to graphic mode.

$ uname -a
Linux dell64 2.6.27-9-generic #1 SMP Thu Nov 20 22:15:32 UTC 2008 x86_64 GNU/Linux

$ dmidecode | grep -i -a1 -b1 vendor; sudo dmidecode | grep -i -a1 -b1 "Product Name"
2899-BIOS Information
2916: Vendor: Dell Inc.
2935- Version: A10
3860- Manufacturer: Dell Inc.
3885: Product Name: Precision M4300
3933- Version: Not Specified
--
4150- Manufacturer: Dell Inc.
4175: Product Name: 0UY141
4197- Version:

Kashi Gorton (flash87) wrote :

Same issues on a Inspiron 1100, adjust brightness using the hotkeys, OSD level comes up and can adjust brightness but then the rest of the keyboard is unresponsive.

$ uname -a
Linux deformedrabbit 2.6.27-9-generic #1 SMP Thu Nov 20 21:57:00 UTC 2008 i686 GNU/Linux

$ dmidecode | grep -i -a1 -b1 vendor; sudo dmidecode | grep -i -a1 -b1 "Product Name"
1278- Manufacturer: Dell Computer Corporation
1319: Product Name: Inspiron 1100
1367- Version: Not Specified
--
1546- Manufacturer: Dell Computer Corporation
1587: Product Name: 09U784
1609- Version:

Additionally, my BIOS version is A32 (the latest available) and this bug did not exist on the standard hardy distribution; the changing brightness (and volume) hotkeys worked perfectly. I upgraded to intrepid today because of the beautiful perl it contains... what's happening with this bug? Can I upload anything helpful?

sameer (sameer-indirock) wrote :

something similar has occured in my lenovo y500 laptop.
mouse clicks close/minimise windows but do not open panel menus or any other icon. even pressing enter doesn't open selected icons. i logout and log back(CTRL + ALT + BSPC) in to make it all right. this has happened while changing the volume in vlc or using the super key for the water effect of compiz-fusion or while the laptop was idle for a while.
here's what my xorg.conf looks like

sameer@Sameer-laptop:~$ cat /etc/X11/xorg.conf
# xorg.conf (X.Org X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type "man xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# Note that some configuration settings that could be done previously
# in this file, now are automatically configured by the server and settings
# here are ignored.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
# sudo dpkg-reconfigure -phigh xserver-xorg

Section "Device"
Identifier "Configured Video Device"
EndSection

Section "Monitor"
Identifier "Configured Monitor"
EndSection

Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Configured Video Device"
EndSection

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

Before ...

mitch@i8600:~$ uname -a
Linux i8600 2.6.27-9-generic #1 SMP Thu Nov 20 21:57:00 UTC 2008 i686 GNU/Linux

mitch@i8600:~$ sudo lsb_release -a|grep Description
Description: Ubuntu 8.10

mitch@i8600:~$ sudo dmidecode | grep -i -a1 -b1 "Vendor"; sudo dmidecode | grep -i -a1 -b1 "Product Name"
523-BIOS Information
540: Vendor: Dell Computer Corporation
575- Version: A14
1429- Manufacturer: Dell Computer Corporation
1470: Product Name: Inspiron 8600
1518- Version: Not Specified
--
1697- Manufacturer: Dell Computer Corporation
1738: Product Name: 0P3490
1760- Version:

* Confirming comment #56 by Endolith, 1st and 3rd observation: hald-addon-dell-backlight is taking much CPU, and strange behaviour of menus.

* Confirming comment #91 by Daniel Knitt-Frank: When I got locked due to Fn+up/dn, I had to press Ctrl+Alt+F{n} then Ctrl+Alt+F7 again to fully restore the functionality of keyboard.

* Confirming as well comments #126 and #131 by Wirawan Purwanto.

* Try last kernel from intrepid-proposed (2.6.27-11-generic, 22 dec.), no change.

* Apply patch from Richard Hughes in comment #68 with modification from Kārlis M. in comment #93 (sources from git, on 24 dec.)
static struct dmi_system_id atkbd_dmi_quirk_table[] __initdata = {
        {
                .ident = "Dell Laptop",
                .matches = {
                        DMI_MATCH(DMI_SYS_VENDOR, "Dell Computer Corporation"),
                        DMI_MATCH(DMI_CHASSIS_TYPE, "8"),
                },
                .callback = atkbd_setup_fixup,
                .driver_data = atkbd_dell_laptop_keymap_fixup,
        },
Not so easy to compile ;-) (I haven't done it from years...)
Reboot, and ... it works !

mitch@i8600:~$ uname -a
Linux i8600 2.6.27-9-generic #1 SMP Wed Dec 24 14:40:03 CET 2008 i686 GNU/Linux

I forget to change the flavor...

This point is still not taken in account in new kernel release ?

Chris Dellin (cdellin) wrote :

I am in an identical situation to the above comment (Guillaume LAURENT, Inspiron 8600, DMI Vendor "Dell Computer Corporation", Intrepid), applied modified Richard Hughes patch, recompiled, and the problem is fixed. The most recent kernel in ubuntu-proposed (-11 I believe) does not fix the problem.

Wirawan Purwanto (wirawan0) wrote :

Hi everybody,

There has been no further discussion from anyone for a little while; new posts seem to repeat the existing bug description. I am surprised that such a long bug report hasn't be acted upon promptly, although the fix is easy to make (albeit being a dirty workaround):

This dire situation we are having with Dell laptops can be easily fixed if the patch proposed in comment #142 is incorporated into the current file atkbd.c in the Linux kernel, by adding an additional record in the atkbd_dmi_quirk_table[] array using the second commonly-found DMI string match: "Dell Computer Corporation", in addition to the "Dell Inc." string. This is dirty indeed, as we have two records of similar things. But this would get rid of the problem for virtually all Dell users. Could one of the Ubuntu developers do this for us, please? The recent gnome power manager is not fixing the problem either.

Onno Zweers (onnozweers) wrote :

I agree totally with Wirawan. This bug, though small, is very serious. I found the workaround Ctrl+Alt+Fx by myself because I wanted to check the problem from the command line, but there are more and more users out there who have no idea that their Linux has six text terminals. The only thing they know is: if I use completely normal keys on my keyboard, Linux crashes. Their conclusion will be that Ubuntu, or Linux in general, sucks.

My setup, in case anybody is interested: Inspiron 1150, Linux inspiron1150 2.6.27-9-generic #1 SMP Thu Nov 20 21:57:00 UTC 2008 i686 GNU/Linux.

onno@inspiron1150:~$ sudo dmidecode | grep -i -a1 -b1 "Vendor"; sudo dmidecode | grep -i -a1 -b1 "Product Name"
372-BIOS Information
389: Vendor: Dell Computer Corporation
424- Version: A05
1278- Manufacturer: Dell Computer Corporation
1319: Product Name: Inspiron 1150
1367- Version: Not Specified
--
1546- Manufacturer: Dell Computer Corporation
1587: Product Name: 0F3553
1609- Version:

I am very grateful for all the people here who have spent time debugging this! Thank you all. I hope the patch is incorporated in the kernel soon.

Lethe (nick-ukfsn) wrote :

Guys, I have just asked the kernel people to apply the 'Dell Computer Corporation' patch as it was proposed, but didn't seem to make it into the lastest kernel release.

http://marc.info/?l=linux-kernel&m=123055061901679&w=2

Hopefully if it is applied, Ubuntu kernel team will pick it up and backport.

Nick

I'm not really fluent in kernel's code, but if we use :

DMI_MATCH(DMI_SYS_VENDOR, "Dell")

it might works for both :
Vendor: Dell Computer Corporation
and
Vendor: Dell Inc.

No ?

Lethe (nick-ukfsn) wrote :

No. I think DMI_MATCH(DMI_SYS_VENDOR, "...") requires a full match, not a substring.

Rich (cuda-rich) wrote :

quick & dirty workaround while the kernel is getting fixed:
xmodmap -e 'keycode 232 = XF86_Switch_VT_7'
xmodmap -e 'keycode 233 = XF86_Switch_VT_7'

I see this is targeting intrepid-updates, but that is not slated until 2010-04-30. Is there any other way to push this to Intrepid users faster?

Steve Langasek (vorlon) wrote :

The original upstream fix is present in the 2.6.27-11.22 kernel in intrepid-proposed, but this fix only covers the "Dell Inc." case; rolling back the bug state, since it appears another fix is still needed here.

Andrew, the date of "intrepid-updates" is actually the deadline after which updates for intrepid *stop* being published; this fix can be made available to users of Ubuntu 8.10 any time before that, developer time allowing.

Changed in linux:
status: Fix Committed → Triaged
Lethe (nick-ukfsn) wrote :

I prodded the kernel guys to get the "Dell Computer Corporation" one in, and it is now queued:

http://marc.info/?t=123056113700003&r=1&w=2

... but also on my thread in the forums, it appears there is now another bloody option, but the user doesn't state if he has same issues with keyboard quirks:

http://ubuntuforums.org/showthread.php?p=6488632#post6488632

261-BIOS Information
278: Vendor: Phoenix Technologies LTD
312- Version: A04
809- Manufacturer: Dell Inc.
834: Product Name: Inspiron 700m
869- Version: -1
--
1050- Manufacturer: DELL SYSTEM
1077: Product Name: 0D9593
1099- Version:

Eric O'Callaghan (eric1207) wrote :

I also have "Phoenix Technologies, LTD" on my dmidecode output..
This is on my Dell Studio 1535, I bought it from dell.com/ubuntu w/ Hardy on it originally and the brightness function key combo worked fine on Hardy, but after upgrading to Intrepid, weird things happened with the brightnes function keys and applet.

If I try to change the brightness, the bar on the brightness applet that comes up is not synchronized with the actual brightness of the screen. If i go to lower the brightness, the screen will get dimmer in increments as it's supposed to, but the bar on the applet with drop to the far left like I turned the brightness all the way down. The keyboard also doesn't respond properly after adjusting brightness, and the applet doesn't go away. If I switch to another tty and back again, all is normal, the brightness applet is gone and the keyboard works fine.

Handle 0x0000, DMI type 0, 20 bytes
BIOS Information
 Vendor: Phoenix Technologies, LTD
 Version: 6.00 PG
 Release Date: 08/03/2005
 Address: 0xE0000
 Runtime Size: 128 kB
 ROM Size: 512 kB

Eric O'Callaghan (eric1207) wrote :

Scratch that dmidecode information, I ran dmidecode on the wrong machine and I'm new to Launchpad
Sorry about that... everything before the dmidecode information is still true.

Here's the actual dmidecode information for my laptop:

BIOS Information
Vendor: Dell Inc.
Version: A05
Release Date: 07/30/2008
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 2048 kB

Lethe, I spoke to the user who reported the Phoenix BIOS and it looks like there is no problem with that version. The current kernel patches should fix the problem for all the known cases. This is what the user said:

"As of this date, and with the latest updates (as of yesterday)... Brightness and volume controls work perfectly. Volume controls interface perfectly with Ubuntu (that is, the volume indicator matches the volume settings). The Ubuntu brightness indicator does not work, but the keys do. I've never experienced any problems with function key locking behaviour"

Changed in gnome-power:
status: Unknown → Invalid
Chris Hillery (ceejatec) wrote :

Also happening here on a Dell Latitude D800. Confirmed that my Vendor is "Dell Computer Corporation" also.

On my system, at least, a variant of Rich's workaround is serving me just fine. I added the following to my ~/.xmodmaprc :

keycode 232 = Shift_L
keycode 233 = Shift_R

This prevents those keycodes from triggering the Gnome Brightness Applet entirely, which seems to bypass the problem. The screen brightness still changes. I think I personally may keep this enabled even after this bug gets resolved. I see no value in having a little slightly-out-of-sync bar graph pop up to tell me how bright my screen is anyway; my eyes will serve that purpose just fine. :)

nanotube (nanotube) wrote :

Hi
same problem here, with same symptoms.

using dell inspiron 5150, with ati mobility radeon 9000 graphics card, and using the foss ati driver

trying to change brightness causes the keyboard to stop working, mouse still works fine, panel menus fail to come up, though. CPU is being eaten, and changing brightness still works.

switching to a VTY and back fixes things good as new, though.

On Fri, Jan 9, 2009 at 7:04 AM, Chris Hillery <email address hidden> wrote:
> Also happening here on a Dell Latitude D800. Confirmed that my Vendor is
> "Dell Computer Corporation" also.

Chris, can you post the output from these commands?

dmidecode -t bios | head -8
dmidecode -t system | head -8

Here's mine for another example:

BIOS Information
 Vendor: Dell Computer Corporation
 Version: A14
 Release Date: 06/30/2005
System Information
 Manufacturer: Dell Computer Corporation
 Product Name: Inspiron 8600
 Version: Not Specified

nanotube (nanotube) wrote :

Here's my dmidecode info, in case it's needed. Again, this is a dell inspiron 5150.

dmidecode -t bios :
------
# dmidecode 2.9
SMBIOS 2.3 present.

Handle 0x0000, DMI type 0, 20 bytes
BIOS Information
 Vendor: Dell Computer Corporation
 Version: A37
 Release Date: 09/29/2004

dmidecode -t system
-------
# dmidecode 2.9
SMBIOS 2.3 present.

Handle 0x0100, DMI type 1, 25 bytes
System Information
 Manufacturer: Dell Computer Corporation
 Product Name: Inspiron 5150
 Version: Not Specified

Download full text (3.6 KiB)

I'm having the same problems. Here's my output to those last two commands:

~# dmidecode -t bios | head -8
# dmidecode 2.9
SMBIOS 2.3 present.

Handle 0x0000, DMI type 0, 20 bytes
BIOS Information
    Vendor: Dell Computer Corporation
    Version: A17
    Release Date: 06/29/2005

~# dmidecode -t system | head -8
# dmidecode 2.9
SMBIOS 2.3 present.

Handle 0x0100, DMI type 1, 25 bytes
System Information
    Manufacturer: Dell Computer Corporation
    Product Name: Inspiron 600m
    Version: Not Specified

On Sun, Jan 11, 2009 at 9:00 PM, nanotube <email address hidden> wrote:

> Here's my dmidecode info, in case it's needed. Again, this is a dell
> inspiron 5150.
>
> dmidecode -t bios :
> ------
> # dmidecode 2.9
> SMBIOS 2.3 present.
>
> Handle 0x0000, DMI type 0, 20 bytes
> BIOS Information
> Vendor: Dell Computer Corporation
> Version: A37
> Release Date: 09/29/2004
>
> dmidecode -t system
> -------
> # dmidecode 2.9
> SMBIOS 2.3 present.
>
> Handle 0x0100, DMI type 1, 25 bytes
> System Information
> Manufacturer: Dell Computer Corporation
> Product Name: Inspiron 5150
> Version: Not Specified
>
> --
> Losing keyboard and mouse control when changing screen brightness with fn +
> arrow under intrepid
> https://bugs.launchpad.net/bugs/285323
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Gnome Powermanager: Invalid
> Status in Ubuntu Release Notes: New
> Status in "acpid" source package in Ubuntu: Invalid
> Status in "gnome-power-manager" source package in Ubuntu: Invalid
> Status in "linux" source package in Ubuntu: New
> Status in "xserver-xorg-input-evdev" source package in Ubuntu: Invalid
> Status in acpid in Ubuntu Intrepid: Invalid
> Status in gnome-power-manager in Ubuntu Intrepid: Invalid
> Status in linux in Ubuntu Intrepid: Triaged
> Status in xserver-xorg-input-evdev in Ubuntu Intrepid: Invalid
>
> Bug description:
> On my Dell inspiron 9300 laptop under intrepid (hardy did not have this
> problem), when I type FN + Arrow keys to change the screen brightness, Most
> of mouse and keyboard keys stop working.
>
> For an example : I can't type any text anywhere, ALT + F4 does not close
> any window, mouse clicks "partially" opens the gnome-panel menus, isn't able
> to close windows with the right-top x, but mouse click is still able to move
> a window..
>
> screencast :
> http://upload.leservicetechnique.com/bugs/mouse_keyboard_acpid.ogv
>
> This bug is reproducible under both metacity and compiz, and not caused by
> a BIOS password.
>
> A quick workaround to bring back things to normal is to switch to a VT and
> go back to Xorg with CTRL + ALT + F6 and CTRL + ALT + F7
>
> When changing screen brightness, I get this in Xorg.0.log :
>
> (II) AIGLX: Suspending AIGLX clients for VT switch
> (II) Open ACPI successful (/var/run/acpid.socket)
> (II) AIGLX: Resuming AIGLX clients after VT switch
> (II) AlpsPS/2 ALPS GlidePoint: x-axis range 0 - 1023
> (II) AlpsPS/2 ALPS GlidePoint: y-axis range 0 - 767
> (--) AlpsPS/2 ALPS GlidePoint touchpad found
> (II) Macintosh mouse button emulation: Device reopened after 10 attempts.
> (**) Macintosh mous...

Read more...

As requested:

-----
janus# dmidecode -t bios | head -8
# dmidecode 2.9
SMBIOS 2.3 present.

Handle 0x0000, DMI type 0, 20 bytes
BIOS Information
 Vendor: Dell Computer Corporation
 Version: A11
 Release Date: 09/03/2004
janus# dmidecode -t system | head -8
# dmidecode 2.9
SMBIOS 2.3 present.

Handle 0x0100, DMI type 1, 25 bytes
System Information
 Manufacturer: Dell Computer Corporation
 Product Name: Latitude D800
 Version: Not Specified
-----

This is a Dell Latitude D800 laptop.

Peter Stein (ahobwfvhmfsr) wrote :

Hi all

It would be good to know why everything worked perfectly with 7.04, 7.10 and 8.04. If it were a question of BIOS issue/kernel workaround, why should if ever have worked before?

Thanks in advance for solving this problem!

dmidecode -t bios | head -8
# dmidecode 2.9
SMBIOS 2.3 present.

Handle 0x0000, DMI type 0, 20 bytes
BIOS Information
 Vendor: Dell Inc.
 Version: A09
 Release Date: 09/28/2005

# dmidecode -t system | head -8
# dmidecode 2.9
SMBIOS 2.3 present.

Handle 0x0100, DMI type 1, 25 bytes
System Information
 Manufacturer: Dell Inc.
 Product Name: Inspiron 6000
 Version: Not Specified

I haven't gotten any clear answer if I should create separate bug report for my non-Dell laptop, so I am assuming it's fine to paste respective parts of Mitac 8050QDA dmidecode:
------------------------------------------------------
# dmidecode -t bios | head -8
------------------------------------------------------
SMBIOS 2.3 present.

Handle 0x0000, DMI type 0, 20 bytes
BIOS Information
 Vendor: Insyde Software Corporation
 Version: R1.02
 Release Date: 09/15/2005
------------------------------------------------------
# dmidecode -t system | head -8
------------------------------------------------------
SMBIOS 2.3 present.

Handle 0x0001, DMI type 1, 25 bytes
System Information
 Manufacturer: MTC
 Product Name:
 Version: A0
------------------------------------------------------
Fn+VolumeUp/VolumeDown/ToggleMute are the only ones not working correctly, other Fn keys are just fine.

Kashi Gorton (flash87) wrote :

Since the vast majority of these are reporting a very specific set of Dell-only symptoms, and the solutions decided on are two work-arounds for Dells only, can I suggest that any non-Dell bugs marked as duplicates are de-tagged and that anyone here with a non-dell submit a separate bug report? Is that sensible?

https://help.ubuntu.com/community/ReportingBugs follow this guide!

Benjamin (tibasic-forever) wrote :

I have a Dell as well with this issue and it is Ubuntu Specific. Fedora works and so does openSuse. It seems to be related to gnome-power-manager because if I close this process I can change my brightness.

Mario Limonciello (superm1) wrote :

This bug is a duplicate of bug 261721 and solely affects Dell laptops. If you are having this on another vendor's machine, it is a different bug. It has been fixed in the -proposed kernel.

Sean-O (kain000) wrote :

Bug not present on my newer dell insprion using the 13 2.6.27-9 kernal and gnome 2.24.1

latest kernel update fixed mine
dell inspiron 1150
2.6.27-13-generic

On Mon, Jan 19, 2009 at 6:04 PM, Sean-O <email address hidden> wrote:

> *** This bug is a duplicate of bug 261721 ***
> https://bugs.launchpad.net/bugs/261721
>
> Bug not present on my newer dell insprion using the 13 2.6.27-9 kernal
> and gnome 2.24.1
>
> --
> [Intrepid] Losing keyboard and mouse control when changing screen
> brightness with fn + arrow (Dell)
> https://bugs.launchpad.net/bugs/285323
> You received this bug notification because you are a direct subscriber
> of the bug (via bug 261721).
>
> Status in The Dell Project: New
> Status in Gnome Powermanager: Invalid
> Status in Ubuntu Release Notes: New
> Status in “acpid” source package in Ubuntu: Invalid
> Status in “gnome-power-manager” source package in Ubuntu: Invalid
> Status in “linux” source package in Ubuntu: New
> Status in “xserver-xorg-input-evdev” source package in Ubuntu: Invalid
> Status in acpid in Ubuntu Intrepid: Invalid
> Status in gnome-power-manager in Ubuntu Intrepid: Invalid
> Status in linux in Ubuntu Intrepid: Triaged
> Status in xserver-xorg-input-evdev in Ubuntu Intrepid: Invalid
>
> Bug description:
> On my Dell inspiron 9300 laptop under intrepid (hardy did not have this
> problem), when I type FN + Arrow keys to change the screen brightness, Most
> of mouse and keyboard keys stop working.
>
> For an example : I can't type any text anywhere, ALT + F4 does not close
> any window, mouse clicks "partially" opens the gnome-panel menus, isn't able
> to close windows with the right-top x, but mouse click is still able to move
> a window..
>
> screencast :
> http://upload.leservicetechnique.com/bugs/mouse_keyboard_acpid.ogv
>
> This bug is reproducible under both metacity and compiz, and not caused by
> a BIOS password.
>
> A quick workaround to bring back things to normal is to switch to a VT and
> go back to Xorg with CTRL + ALT + F6 and CTRL + ALT + F7
>
> When changing screen brightness, I get this in Xorg.0.log :
>
> (II) AIGLX: Suspending AIGLX clients for VT switch
> (II) Open ACPI successful (/var/run/acpid.socket)
> (II) AIGLX: Resuming AIGLX clients after VT switch
> (II) AlpsPS/2 ALPS GlidePoint: x-axis range 0 - 1023
> (II) AlpsPS/2 ALPS GlidePoint: y-axis range 0 - 767
> (--) AlpsPS/2 ALPS GlidePoint touchpad found
> (II) Macintosh mouse button emulation: Device reopened after 10 attempts.
> (**) Macintosh mouse button emulation: YAxisMapping: buttons 4 and 5
> (**) Macintosh mouse button emulation: EmulateWheelButton: 4,
> EmulateWheelInertia: 10, EmulateWheelTimeout: 200
> (II) PS/2 Mouse: Device reopened after 10 attempts.
> (**) PS/2 Mouse: YAxisMapping: buttons 4 and 5
> (**) PS/2 Mouse: EmulateWheelButton: 4, EmulateWheelInertia: 10,
> EmulateWheelTimeout: 200
> (II) AT Translated Set 2 keyboard: Device reopened after 10 attempts.
> (II) Video Bus: Device reopened after 10 attempts.
>

no longer affects: dell

The bug task for the somerville project has been removed by an automated script. This bug has been cloned on that project and is available here: https://bugs.launchpad.net/bugs/1305910

no longer affects: somerville
Displaying first 40 and last 40 comments. View all 171 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.