Up arrow key mapped to Print [screen]

Bug #255008 reported by Matt Zimmerman
198
This bug affects 18 people
Affects Status Importance Assigned to Milestone
GNOME Settings Daemon
Won't Fix
Medium
Gentoo Linux
Won't Fix
Medium
gnome-settings-daemon (Ubuntu)
Fix Released
High
Ubuntu Desktop Bugs
Nominated for Lucid by Friedrich Strohmaier
Intrepid
Fix Released
High
Ubuntu Desktop Bugs
xorg-server (Ubuntu)
Fix Released
High
Unassigned
Nominated for Lucid by Friedrich Strohmaier
Intrepid
Won't Fix
High
Unassigned

Bug Description

On current Intrepid, when I press the Up arrow on my keyboard, the GNOME screenshot dialog comes up. I usually notice this when I'm navigating in a text dialog (like the one I'm typing into now) and have pressed Up several times (triggering a sequence of screenshot windows which take several seconds to appear).

<mdz> my up arrow key is now a shortcut for print screen
<ogra_cmpc> how handy
<tjaalton> mdz: change the kb model to evdev
<mdz> it is actually extremely inconvenient, because it is a key I tend to press several times before I realize what is happening
<tjaalton> that should be forced though
<mdz> tjaalton: thanks...is there a more permanent and automatic fix on the way?
<mdz> tjaalton: my xorg.conf is entirely autogenerated
<tjaalton> mdz: yes, it should be forced always
<mdz> tjaalton: setxkbmap -model evdev didn't fix it
<tjaalton> mdz: as evdev, because gnome is borked
<mdz> tjaalton: is there a bug number for this?
<tjaalton> hm, maybe I need to test the latest fedora patches for real..
<tjaalton> mdz: nope
<tjaalton> not that I know of anyway
<mdz> tjaalton: on which package should I file it?
<tjaalton> mdz: xorg-server

ProblemType: Bug
Architecture: i386
Date: Tue Aug 5 15:56:42 2008
DistroRelease: Ubuntu 8.10
NonfreeKernelModules: nvidia
Package: xserver-xorg 1:7.4~0ubuntu2
PackageArchitecture: i386
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
SourcePackage: xorg
Uname: Linux 2.6.26-5-generic i686

Revision history for this message
Matt Zimmerman (mdz) wrote :
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

18:41 < tjaalton> hm, shouldn't the kb model be forced to evdev when i-h is used?
18:45 < daniels> tjaalton: it is
18:45 < daniels> well, the xkb model is forced to evdev by the evdev driver
18:46 < daniels> gnome, however, wants to compile keymaps on the client side and then send
                 them to the server
18:46 < tjaalton> yes, that's what I'm seeing..
18:46 < daniels> right
18:46 < tjaalton> and the fedora patches don't seem to help :)
18:46 < tjaalton> whot: ^^
18:46 < daniels> yeah, xkb needs fixing there

Changed in xorg-server:
importance: Undecided → High
status: New → Confirmed
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

so the workaround is to use the gnome keyboard capplet and change the model as "generic - evdev", until a permanent solution is in place.

Revision history for this message
Matt Zimmerman (mdz) wrote : Re: [Bug 255008] Re: Up arrow key mapped to Print [screen]

On Tue, Aug 05, 2008 at 04:04:16PM -0000, Timo Aaltonen wrote:
> so the workaround is to use the gnome keyboard capplet and change the
> model as "generic - evdev", until a permanent solution is in place.

That doesn't fix it for me.

--
 - mdz

Revision history for this message
Hew (hew) wrote :

I get this issue as well with my Logitech G15 keyboard. My left/right/down keys don't work either, but don't seem to be mapped to some extra function. The insert/delete/home/end/page_up/page_down keys are also dead/remapped. Happened with the last batch of updates, so I suspect it was caused in this latest xorg:

xserver-xorg-core/intrepid uptodate 2:1.4.99.906-1ubuntu1

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Matt: what layout do you use? There are patches in Fedora which allow changing the layout, but the model should always be evdev, and that should be forced in gnome.

Revision history for this message
Matt Zimmerman (mdz) wrote :

On Wed, Aug 06, 2008 at 05:21:42AM -0000, Timo Aaltonen wrote:
> Matt: what layout do you use? There are patches in Fedora which allow
> changing the layout, but the model should always be evdev, and that
> should be forced in gnome.

I use layout "us", variant "dvorak".

--
 - mdz

Revision history for this message
Matt Zimmerman (mdz) wrote :

Actually, no...on my desktop, my keyboard maps dvorak in hardware, so I use layout "us" with no variant:

Section "InputDevice"
        Identifier "Generic Keyboard"
        Driver "kbd"
        Option "XkbRules" "xorg"
        Option "XkbModel" "pc104"
        Option "XkbLayout" "us"
EndSection

My laptop (which I haven't upgraded yet for fear of this bug) uses variant "dvorak".

Revision history for this message
Colin Watson (cjwatson) wrote :

For comparison, I independently discovered 'setxkbmap -model evdev -layout gb -option lv3:ralt_switch' upon encountering this bug, and it worked fine for me.

I do hope somebody has made sure that the special cases (abnt2 and jp106 for Brazilian and Japanese keymaps) continue to work. :-)

Revision history for this message
Timo Aaltonen (tjaalton) wrote :
Revision history for this message
Matt Zimmerman (mdz) wrote :

I confirmed this bug on my laptop, using the dvorak variant:

Section "InputDevice"
        Identifier "Generic Keyboard"
 Driver "kbd"
 Option "XkbRules" "xorg"
 Option "XkbModel" "pc105"
 Option "XkbLayout" "us"
 Option "XkbVariant" "dvorak"
 Option "XkbOptions" "lv3:ralt_switch"
EndSection

However, this time, I was able to fix it with:

setxkbmap -model evdev -layout us -variant dvorak

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Matt, could you check that you have the latest hal installed on the broken machine. See bug 254939 where one guy had the same problem.

Revision history for this message
Matt Zimmerman (mdz) wrote :

On Wed, Aug 06, 2008 at 02:01:16PM -0000, Timo Aaltonen wrote:
> Matt, could you check that you have the latest hal installed on the
> broken machine. See bug 254939 where one guy had the same problem.

0.5.11-3~ubuntu5

--
 - mdz

Revision history for this message
Hew (hew) wrote :

I had bug 254939 before, but switching with ctrl+alt+F1 and sudo apt-get update/upgrade fixed that issue. I now have this different problem.

My earlier issue with the keys other than the up arrow have currently disappeared (during this session, without updating), but Ins and Del are still dead.

hal/intrepid uptodate 0.5.11-3~ubuntu5
xserver-xorg-core/intrepid uptodate 2:1.4.99.906-1ubuntu3
xserver-xorg-input-evdev/intrepid uptodate 1:2.0.3-2

Revision history for this message
sojourner (itsmealso2) wrote :

I also have this bug after intrepid updates of aug 5 ,2008 . gereric qwerty keyboard and US keymap .

Revision history for this message
Tanath (tanath) wrote :

This bug appears to be caused by imwheel. I suggest removing it if you have it.

Revision history for this message
Hew (hew) wrote :

I do not have imwheel installed and still have this issue.

Also, upon restarting today, the issue has gone back to affecting all ten keys. Page_up is mapped to / (as well as the / key itself), and page_down is mapped to something that brings up a context menu in the focussed window. As well as up_arrow being print_screen, these are the only three of the ten that seem to be mapped to something.

Revision history for this message
Tanath (tanath) wrote :

Hm, well I removed imwheel, which fixed a few things, and after logging out and back in, my up arrow is no longer mapped to prtscn. Have you tried resetting the keyboard in the Keyboard applet? System > Prefs > Keyboard > Layout > Reset. After that you may need to check your Keyboard Shortcuts applet.

Revision history for this message
Paul Weiss (interweiss) wrote :

I'm experiencing the same bug, and reseting the keyboard applet did nothing.

Revision history for this message
Paul Weiss (interweiss) wrote :

...and I don't have imwheel running.

Revision history for this message
Tanath (tanath) wrote :

Well, I still have a couple keyboard issues too, but something I did fixed the up arrow issue. Now my main problem is that holding the right Ctrl key causes it to rapidly repeat.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Please keep only one issue per bug. The ctrl repeating is known upstream and fixed in master. This OTOH should be fixed in the latest xserver-xorg-core, please make sure you have 1.4.99.906-1ubuntu3 installed.

And if you still have the original problem even when the keyboard model is evdev, attach /var/log/Xorg.0.log, thanks.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

..and the output of 'setxkbmap -print', and xorg.conf.

Revision history for this message
whwi (whitewindow) wrote :

hi
i have this problem too

ii xserver-xorg 1:7.4~0ubuntu2 the X.Org X server
ii xserver-xorg-core 2:1.4.99.906-1ubuntu3 Xorg X server - core server

setxkbmap -print
xkb_keymap {
 xkb_keycodes { include "xfree86+aliases(qwertz)" };
 xkb_types { include "complete" };
 xkb_compat { include "complete" };
 xkb_symbols { include "pc+de(mac)+level3(ralt_switch_for_alts_toggle)+group(alts_toggle)" };
 xkb_geometry { include "pc(pc104)" };
};

Revision history for this message
Matt Zimmerman (mdz) wrote :

Here is setxkbmap -print for the system where I still experienced this
problem after setxkbmap -model evdev:

xkb_keymap {
 xkb_keycodes { include "evdev+aliases(qwerty)" };
 xkb_types { include "complete" };
 xkb_compat { include "complete" };
 xkb_symbols { include "pc+us+inet(evdev)" };
 xkb_geometry { include "pc(pc104)" };
};

--
 - mdz

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

whwi: you need to set the keyboard model as evdev.

Revision history for this message
Matt Zimmerman (mdz) wrote :
Revision history for this message
whwi (whitewindow) wrote :

Timo Aaltonen same problem

setxkbmap -print
xkb_keymap {
 xkb_keycodes { include "evdev+aliases(qwertz)" };
 xkb_types { include "complete" };
 xkb_compat { include "complete" };
 xkb_symbols { include "pc+de(mac)+inet(evdev)+level3(ralt_switch_for_alts_toggle)+group(alts_toggle)" };
 xkb_geometry { include "pc(pc104)" };

Revision history for this message
Timo Aaltonen (tjaalton) wrote :
Revision history for this message
Matt Zimmerman (mdz) wrote :
Revision history for this message
Hew (hew) wrote :

"Reset to Defaults" (Evdev-managed keyboard) solved the problem for me (after a restart). Switching back to the layout I was using before, Logitech G15, causes the keys to go dead again.

Revision history for this message
phenest (steve-clark) wrote :

setxkbmap -print:
xkb_keymap {
 xkb_keycodes { include "xfree86+aliases(qwerty)" };
 xkb_types { include "complete" };
 xkb_compat { include "complete" };
 xkb_symbols { include "pc+gb(dvorak)+inet(precision_m)" };
 xkb_geometry { include "pc(pc104)" };
};

xorg.conf:
Section "InputDevice"
        Identifier "Generic Keyboard"
        Driver "kbd"
        Option "CoreKeyboard"
        Option "XkbRules" "xorg"
        Option "XkbModel" "pc105"
        Option "XkbLayout" "gb"
        Option "XkbVariant" "dvorak"
EndSection

Using setxkbmap -model evdev -layout gb -variant dvorak fixes it. But how do I make this stick?

Revision history for this message
phenest (steve-clark) wrote :

Didn't read Hew's post. I used "Reset to Defaults" (Evdev-managed keyboard). Same results as Hew. I have a Dell Precision M90.

Revision history for this message
Nick Colgan (nick-colgan) wrote :

I experienced and subsequently filed the same bug (without realizing it was a duplicate, of course). The generic->evdev fixed did work for me as a temporary fix. More info and data here: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/255608

Revision history for this message
Nick Colgan (nick-colgan) wrote :

CORRECTION: although switching to generic-evdev did fix the HOME,PGUP,PGDN,END, left arrow, down arrow, and arrow keys, my right arrow key is still not performing as expected. Pressing it switches one workspace to the left. The "Keyboard Shortcuts" preferences seem to bind the correct key sequence (Alt+CTRL+Right), so I don't know what is causing this problem. Again, I have more information listed at bug #255608.

Also, setxkbmap -print results:
xkb_keymap {
 xkb_keycodes { include "evdev+aliases(qwerty)" };
 xkb_types { include "complete" };
 xkb_compat { include "complete" };
 xkb_symbols { include "pc+us+inet(evdev)" };
 xkb_geometry { include "pc(pc104)" };
};

Relevant xorg.conf info:
Section "InputDevice"
        Identifier "Generic Keyboard"
        Driver "kbd"
        Option "XkbRules" "xorg"
        Option "XkbModel" "pc105"
        Option "XkbLayout" "us"
EndSection

Attatched is my Xorg.0.log

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Nick, that's something new, please file another bug and tell what events xev shows with that key.

all those who still see this bug, please create a new user and test if you can reproduce the problem..

Revision history for this message
Paul Weiss (interweiss) wrote :

Sorry guys, rebooting after reseting my keyboard in the menu fixed my problem.

Revision history for this message
Matt Zimmerman (mdz) wrote :

I never was able to fix this with setxkbmap, but after installing updates and rebooting, everything is OK

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

<phew> so it was some update missing from your system.. that's good news. Closing the bug.

Changed in xorg-server:
status: Confirmed → Fix Released
Revision history for this message
Jonh Wendell (wendell) wrote :

Hey, this is still an issue to me, with an intrepid up-to-date.

I've put my layout to ev-managed but my "/" key doesn't work. With my wife, up arrow brings gnome-screenshot.

Revision history for this message
Matt Zimmerman (mdz) wrote :

I'm still having problems on one of my two affected systems as well. Forcing the model to evdev was only a temporary workaround, and after a reboot, it's back to the same behaviour.

perseus:[~] setxkbmap -print
xkb_keymap {
 xkb_keycodes { include "xfree86+aliases(qwerty)" };
 xkb_types { include "complete" };
 xkb_compat { include "complete" };
 xkb_symbols { include "pc+us(dvorak)+level3(ralt_switch_for_alts_toggle)+altwin(meta_alt)+group(alts_toggle)" };
 xkb_geometry { include "pc(pc105)" };
};

PageUp produces '/', home and end do nothing, and the up arrow is Print.

Timo, which version of which package do you believe fixes this?

Changed in xorg-server:
status: Fix Released → Triaged
Revision history for this message
Matt Zimmerman (mdz) wrote :

...and in fact, the same command which fixed it last time (setxkbmap -model evdev -layout us -variant dvorak) doesn't help anymore!

xkb_keymap {
 xkb_keycodes { include "evdev+aliases(qwerty)" };
 xkb_types { include "complete" };
 xkb_compat { include "complete" };
 xkb_symbols { include "pc+us(dvorak)+inet(evdev)+level3(ralt_switch_for_alts_toggle)+altwin(meta_alt)+group(alts_toggle)" };
 xkb_geometry { include "pc(pc104)" };
};

Revision history for this message
Loïc Minier (lool) wrote :

Here, setting layout to "Evdev-managed" in gnome-keyboard-properties and "Reset to defaults" fixed it after a reboot.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Matt: you need xserver-xorg-core .906-1ubuntu3 and hal -3~ubuntu6. Without the xserver update, setxkbmap only seemingly changes the model..

Revision history for this message
Matt Zimmerman (mdz) wrote :

On Wed, Aug 13, 2008 at 06:39:26AM -0000, Timo Aaltonen wrote:
> Matt: you need xserver-xorg-core .906-1ubuntu3 and hal -3~ubuntu6.
> Without the xserver update, setxkbmap only seemingly changes the model..

I have both of those installed, and had them prior to the reboot, but I
still have a problem.

My GNOME keyboard settings show "Generic 105-key (intl) PC".

--
 - mdz

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Change that to evdev and it should work.

Revision history for this message
Matt Zimmerman (mdz) wrote :

On Wed, Aug 13, 2008 at 09:13:59AM -0000, Timo Aaltonen wrote:
> Change that to evdev and it should work.

I clicked "Reset to defaults" which changed it to "Evdev-managed keyboard"
but the up arrow is still Print.

--
 - mdz

Revision history for this message
Matt Zimmerman (mdz) wrote :

On Wed, Aug 13, 2008 at 10:26:42AM +0100, Matt Zimmerman wrote:
> On Wed, Aug 13, 2008 at 09:13:59AM -0000, Timo Aaltonen wrote:
> > Change that to evdev and it should work.
>
> I clicked "Reset to defaults" which changed it to "Evdev-managed keyboard"
> but the up arrow is still Print.

...and furthermore, I am surely not the only one with this configuration,
and we can't expect all users to manually fix this after upgrading.

--
 - mdz

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Please test with a new user as I asked earlier.

this could be forced in gnome, but then non-evdev setups would break.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

or make the evdev driver force the model so that it cannot be changed.

Revision history for this message
Matt Zimmerman (mdz) wrote :

On Wed, Aug 13, 2008 at 09:38:43AM -0000, Timo Aaltonen wrote:
> Please test with a new user as I asked earlier.

This was tricky as I encountered unrelated bugs along the way
(gnome-session, compiz).

I just tested with a guest session, and was unable to reproduce the problem
there.

"setxkbmap -print" shows exactly the same thing in my session (which
exhibits the problem) and in the guest session (which doesn't).

The GNOME settings are almost exactly the same. The only difference is that
the radio button "Default" is checked in my session, but not in the guest's.
I don't know what this means.

> this could be forced in gnome, but then non-evdev setups would break.

If we silently change the user's keyboard settings on upgrade, we need to
adjust the configuration appropriately. This problem makes the system
nearly unusable.

--
 - mdz

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Ok, forcing it in GNOME is not a proper solution, as one would expect. A possible solution (quoting daniels):

"libxklavier likes to compile the entire keymap on the client side, so the client doesn't know that the keyboard is evdev, and the server can't force the model. However, now we have (input-device) properties, the driver could set a xorg.driver prop or something, and if evdev, libxklavier could unconditionally force the evdev model."

That should work. We'll most likely have input-device properties backported in Intrepid on top of current inputproto, libXi and xserver (I already have them built locallly), so only libxklavier needs to be patched so it'll force the model if evdev is used.

Revision history for this message
Bryce Harrington (bryce) wrote :

That's good news that there's a solution in concept now. However, alpha-4 is coming out tomorrow and I'm guessing this solution won't be ready in time. How about we revert back to non-input-hotplug for keyboards for alpha-4. Then we can switch back once the input-device properties and libxklavier fixes are available.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Seb found a patch in Fedora against gnome-settings-daemon, that'll ignore the model if we are using evdev. This is much easier than the suggested libxklavier change, so it'll get in alpha4.

Changed in libxklavier:
importance: Undecided → High
milestone: none → intrepid-alpha-4
status: New → In Progress
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Marking again as fixed for xorg-server, since it already has the necessary patches for the layout stuff.

Changed in xorg-server:
status: Triaged → Fix Released
Changed in gnome-settings-daemon:
assignee: nobody → desktop-bugs
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-settings-daemon - 2.23.6-0ubuntu2

---------------
gnome-settings-daemon (2.23.6-0ubuntu2) intrepid; urgency=low

  * debian/patches/80_evdev_no_model.patch:
    - don't set a keyboard model when evdev is being used (lp: #255008)

 -- Sebastien Bacher <email address hidden> Wed, 13 Aug 2008 23:27:21 +0200

Changed in gnome-settings-daemon:
status: In Progress → Fix Released
Changed in gnome-settings-daemon:
status: Unknown → Confirmed
Revision history for this message
TomasR (tomas-rgp) wrote :

I've found a solution!

I commented out all xkb-options in xorg.conf.

Section "InputDevice"
 Identifier "Generic Keyboard"
 Driver "kbd"
 Option "CoreKeyboard"
# Option "XkbRules" "xorg"
# Option "XkbModel" "pc105"
# Option "XkbLayout" "se"
EndSection

Now everything is back to normal. :D

Revision history for this message
Iñaki García Etxebarria (inaki-garetxe) wrote :

I have a japanese keyboard (pc106) and some keys still do not work after upgrading to gnome-settings-daemon (2.23.6-0ubuntu2), although the Up -> PrtScr problem is indeed fixed (I am using evdev managed keyboard, as recommended).

The symbols that do not work and used to work before are ']' and '}' (which in the japanese keyboard are in the same key), and the key for '\' and '_' (underscore, one key again).

It still works fine in the console, and it used to work fine in hardy with the appropriate xorg.conf. (The yen key has always been kind of borken too, but that's a different bug, and not a regression like this).

 Option "XkbRules" "xorg"
 Option "XkbModel" "jp106"
 Option "XkbLayout" "jp,jp"
 Option "XkbVariant" "106,"
 Option "XkbOptions" "grp:alt_shift_toggle,grp_led:scroll"

A simple way to see that something is broken (some keys are missing) is when I try to add a japanese layout, attached goes a screenshot of that.

Notice that there is no key for ']', '}', which in the japanese keyboard are on the same key (you use shift to select '}'), and take half of the space assigned to 'Return' in the attached layout. Similarly for '\', '_', this key should be taking half of the space assigned to 'Shift_R'.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Iñaki: that's a problem in the layout, please file a bug against xkeyboard-config.

TomasR: those settings have no meaning when using evdev, so it was likely the updates that fixed it for you.

Revision history for this message
Iñaki García Etxebarria (inaki-garetxe) wrote :

Thanks for the reply.

I think it is the same basic issue as in bug #255372 (both japanese and brazilian keyboards are special cases that used to work before whatever caused bug #255008), I added the same information there.

Revision history for this message
Paul Weiss (interweiss) wrote :

This bug doesn't exist for me in Alpha 4 anymore...

Revision history for this message
Matt Zimmerman (mdz) wrote :

On Sat, Aug 16, 2008 at 08:20:14AM -0000, Paul Weiss wrote:
> This bug doesn't exist for me in Alpha 4 anymore...

Working fine for me as well now, on both affected systems. Thanks, all.

--
 - mdz

Revision history for this message
Luka Renko (lure) wrote :

Still a problem here: Kubuntu Intrepid, up-to-date as of today. Workaround with "setxkbmap -model evdev -layout us" helps.

Revision history for this message
Matt Zimmerman (mdz) wrote :

On Sat, Aug 16, 2008 at 06:45:25PM -0000, Luka Renko wrote:
> Still a problem here: Kubuntu Intrepid, up-to-date as of today.
> Workaround with "setxkbmap -model evdev -layout us" helps.

Not surprising, since the fix was in a GNOME component. Probably KDE needs
to do the same, but I don't know what the relevant package is.

--
 - mdz

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

actually, the evdev change broke ABNT2 and jp106 cases partially, and the most sane way to fix it was to force the rules (not model) to be evdev when evdev driver is used. This has been changed in xkeyboard-config upstream, and it also means that there is no need for gnome-settings-daemon (or KDE) to force the model as evdev. It should be configurable like before.

It'll take a while until the situation is cleared, so hang on while updates arrive. Those that had problems with "normal(ish) setups" before should not notice the change, but those with ABTN2 or jp106 might be pleasantly surprised. The bugs that were opened for those cases should be enough for now, though.

Changed in gnome-settings-daemon:
status: Confirmed → Won't Fix
Revision history for this message
Jan Rathmann (kaiserclaudius) wrote :

I am setting the status to Confirmed again, since I still experienced the bug in daily-live image 20080903 (amd64) (The behaviour is still the same like in description of my first report: https://bugs.launchpad.net/ubuntu/+bug/257855 ).

Kind regards,
Jan

Changed in gnome-settings-daemon:
status: Fix Released → Confirmed
Changed in xorg-server:
status: Fix Released → Confirmed
Revision history for this message
Matt Zimmerman (mdz) wrote :

It's working fine here, and this bug report is already very long and confused, so I think it would be better to take your issue to bug 257855. I've unmarked it as a duplicate as your issue may be slightly different.

Changed in gnome-settings-daemon:
status: Confirmed → Fix Released
Changed in xorg-server:
status: Confirmed → Fix Released
Revision history for this message
Matt Zimmerman (mdz) wrote :

Scratch that, I've just confirmed the bug in a fresh installation using intrepid-desktop-i386 20080903. This seems to have regressed.

Changed in gnome-settings-daemon:
status: Fix Released → Triaged
milestone: intrepid-alpha-4 → none
Revision history for this message
Matt Zimmerman (mdz) wrote :

My test was in KVM. Jan, were you testing on real hardware or in a VM?

Revision history for this message
Matt Zimmerman (mdz) wrote :

In fact, this only happens to me when I forget the -k switch to kvm. Sorry about the noise, I think the original issue remains fixed, and kvm is just broken.

Changed in gnome-settings-daemon:
status: Triaged → Fix Released
Revision history for this message
Jan Rathmann (kaiserclaudius) wrote :

@Matt
It was on real hardware, so there still seems to be an issue.

Kind regards,
Jan

Salih EMIN (salih-emin)
Changed in xorg-server:
status: Fix Released → Incomplete
Changed in gnome-settings-daemon:
status: Fix Released → Incomplete
Revision history for this message
Jan Rathmann (kaiserclaudius) wrote :

Can't reproduce this anymore on my system with current daily live, so I'm setting it to fix released.

Kind regards,
Jan

Changed in gnome-settings-daemon:
status: Incomplete → Fix Released
Changed in xorg-server:
status: Incomplete → Fix Released
Revision history for this message
Muelli (ubuntu-bugs-auftrags-killer) wrote :

On 17.09.2008 21:07 Jan Rathmann wrote:
> Can't reproduce this anymore on my system with current daily live, so
> I'm setting it to fix released.
>
You better revert that since am still affected.

muelli@xbox:~$ apt-cache policy xserver-xorg xserver-xorg-input-evdev
xserver-xorg:
   Installed: 1:7.4~2ubuntu1
   Candidate: 1:7.4~2ubuntu1
   Version table:
  *** 1:7.4~2ubuntu1 0
         500 http://de.archive.ubuntu.com intrepid/main Packages
         100 /var/lib/dpkg/status
      1:7.3+10ubuntu10.2 0
         500 http://de.archive.ubuntu.com hardy-updates/main Packages
      1:7.3+10ubuntu10 0
         450 http://de.archive.ubuntu.com hardy/main Packages
xserver-xorg-input-evdev:
   Installed: 1:2.0.99+git20080912-0ubuntu1
   Candidate: 1:2.0.99+git20080912-0ubuntu1
   Version table:
  *** 1:2.0.99+git20080912-0ubuntu1 0
         500 http://de.archive.ubuntu.com intrepid/main Packages
         100 /var/lib/dpkg/status
      1:1.2.0-1ubuntu2 0
         450 http://de.archive.ubuntu.com hardy/main Packages
muelli@xbox:~$

Revision history for this message
Muelli (ubuntu-bugs-auftrags-killer) wrote :

Reverting the "fix released" status to something more accurate

Changed in xorg-server:
status: Fix Released → New
Revision history for this message
pbhj (pbhj) wrote :

I just got this bug ... arrow keys fail along with the cluster of keys around insert, pagedown. PgUp gives me a "/", but / works as normal. I use a GB keyboard map.

I've just run some updates from Hardy to Intrepid but I can't narrow down what is at fault. Also I'm getting wrong keymapping in some text entry areas (eg the Alt-F2 run dialog, the mapping for #, @, | is all wrong.

Finally I use ET:RtCW (Enemy Territory) and the dgamouse appears to be screwed up, I have to switch it off to get any mouse control but then the game is barely playable because the mouse's motion is lumpy.

Could these all be related?

---

"setxkbmap -print" gives:

xkb_keymap {
        xkb_keycodes { include "xfree86+aliases(qwerty)" };
        xkb_types { include "complete" };
        xkb_compat { include "complete" };
        xkb_symbols { include "pc+gb" };
        xkb_geometry { include "pc(pc104)" };
};

Revision history for this message
Martin Emrich (emme) wrote :

Hmm, I thought I got rid of this bug, but now it came back, in a more complex scenario:

I use the free version of NoMachine NX (www.nomachine.com) to connect from my home PC (current Intrepid, the one that had this bug a few weeks ago) to a PC at my university (current hardy). Inside the NX window, the keyboard exhibits the same behaviour as described here.

The "setxkbmap -model evdev" command does not help.

Revision history for this message
Martin Emrich (emme) wrote :

I just discovered: while "setxkbmap -model evdev" does not help, "setxkbmap -model evdev -layout de" does!

Revision history for this message
Dominique Quatravaux (dominique-quatravaux) wrote :

Another workaround that just worked for me: add

blacklist evdev

to /etc/modprobe.d/blacklist then run /sbin/update-modules as root, and reboot. The behavior of the keyboard and mouse is thereafter reverted to what it was under Hardy Heron, no xorg.conf changes or setxkbmap voodoo needed.

Revision history for this message
Aleksey Kirpichnikov (alexcoder) wrote :

With blacklist evdev sinaptic touchpad doesn't work. So still need a fix.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Closing again. Muelli, check your configuration. if you can reproduce this with a new user, open a new bug. Thanks.

Changed in xorg-server:
status: New → Fix Released
Revision history for this message
Bryce Harrington (bryce) wrote :

Re-closing. Muelli, you seem to have a different problem than everyone else, please file a new bug. You can try doing so via running `ubuntu-bug xserver-xorg-input-evdev`, which should attach the necessary files for troubleshooting.

Revision history for this message
Muelli (ubuntu-bugs-auftrags-killer) wrote :

Which package is the fix supposed to be released with?

Revision history for this message
Kevin Christmas (kachristmas) wrote :

>I use the free version of NoMachine NX (www.nomachine.com) to connect from my home PC (current Intrepid, the one
>that had this bug a few weeks ago) to a PC at my university (current hardy). Inside the NX window, the keyboard exhibits
>the same behaviour as described here.

I'm having the exact same problem. It's very frustrating. Intrepid is on my personal machine, connecting to a machine running hardy at work.

Revision history for this message
Kevin Christmas (kachristmas) wrote :

should have read the all the comments!

fixed by running 'setxkbmap -model evdev -layout us' on the machine running hardy.

Revision history for this message
mefiX (mefix) wrote :

in kde, "Evdev-managed Keyboard" has to be selected as keyboard type if the keyboard-layout-manager is activated, which overwrites the xorg/xkb-settings. This works fine in my case (Cherry G230). I chose "de-nodeadkeys" as layout.

Revision history for this message
Muelli (ubuntu-bugs-auftrags-killer) wrote :

On 24.09.2008 20:31, Bryce Harrington wrote:
> Re-closing. Muelli, you seem to have a different problem than everyone
> else, please file a new bug.
The issue still persists. But if I start with a newly created user, it
works. When copying the .gconf/ folder over to the old account, the
up-key works again. I diffed the .gconf/ folders but didn't find any key
that made it work. I probably didn't search hard enough. I do have the
old gconf folder in case anybody is interested in debugging this
further. I started over with a fresh ~/.gconf/ folder and hopefully
didn't forget to migrat any important setting. Having that said, it's
pretty annoying to have to clear the configuration data in order to get
a working desktop.

Cheers,
  Muelli

Revision history for this message
Sascha Grossenbacher (berdir) wrote :

I am on a thinkpad t61 with swiss keyboard layout.

Until yesterday i still had this bug, all the mentioned workarounds and/or updates didn't solved my problem (Actually i had this bug at the beginning, then it was solved (by changing xorg.conf if I remember correctly) and came up again a few weeks later).

Today, I updated my system and after a restart the problem seems to be gone... No idea why. Were there any changes to the related packages?

Revision history for this message
aiyeou (y4spam) wrote :

None of these fixes worked for me on Intrepid beta. I tried both Dell wired USB and Kensington MAC KBD.

Here are relevant inputs: setxkbmap -print
xkb_keymap {
        xkb_keycodes { include "evdev+aliases(qwerty)" };
        xkb_types { include "complete" };
        xkb_compat { include "complete" };
        xkb_symbols { include "pc+us(mac)+inet(evdev)" };
        xkb_geometry { include "pc(pc104)" };
};

and xorg.conf

Section "InputDevice"
    # generated from default
    Identifier "Keyboard0"
    Driver "kbd"
EndSection

The problem started after an update today, is also described here http://kubuntuforums.net/forums/index.php?topic=3097316.0

Thanks for your kind feedback.

Revision history for this message
Aurélien Leblond (blablack) wrote :

Have exactly the same problem on my laptop. Upgraded yesterday from Hardy to Intrepid.

blablack@igorito:~$ setxkbmap -print
xkb_keymap {
 xkb_keycodes { include "evdev+aliases(qwerty)" };
 xkb_types { include "complete" };
 xkb_compat { include "complete" };
 xkb_symbols { include "pc+ie+inet(evdev)" };
 xkb_geometry { include "pc(pc105)" };
};

and xorg.conf
Section "InputDevice"
 Identifier "Generic Keyboard"
 Driver "kbd"
 Option "XkbRules" "xorg"
 Option "XkbModel" "pc105"
 Option "XkbLayout" "ie"
EndSection

Thanks in advance for your help!

Revision history for this message
Aurélien Leblond (blablack) wrote :

Starting with a new user did the trick, no problem with the up arrow anymore...

Revision history for this message
Ciso (cisoprogressivo) wrote :

Same problem here, since the today update.
Italian keyboard on Dell XPS M1330

Revision history for this message
midnightflash (midnightflash) wrote :

For me the solution was:

$ rm .gconf/desktop/gnome/peripherals/keyboard/

and relogin.

After this it's running as expected.

Revision history for this message
Muelli (ubuntu-bugs-auftrags-killer) wrote :

Hey,

On 23.10.2008 13:24, midnightflash wrote:
> For me the solution was:
>
> $ rm .gconf/desktop/gnome/peripherals/keyboard/
>
Congrats :)

But please consider using
    gcontool-2 --recursive-unset /desktop/gnome/peripherals/keyboard/

instead of removing the directory because gconf is a caching deamon and
unexpected bahaviour may occur if you delete the directory yourself.

Cheers

Revision history for this message
SARO (saravanan-subbiah) wrote :

Thanks Muelli,

That fixed the problem for me. Though the correct command is

gconftool-2 --recursive-unset /desktop/gnome/peripherals/keyboard

cheers

Revision history for this message
krixm (kixm) wrote :

Hi!
This solution doesn't work for me.

After using the command and logging in.

The System is asking me for a Xmodmap.

Also the evdev solution is not working for me.

Is there a fix or something else to do?

thx

Revision history for this message
krixm (kixm) wrote :

Got a solution.

First manually delete your old .Xmodmap Files in your Home-Directory.

then do a
sudo dpkg-reconfigure console-setup

to reconfigure your Keyboard.

After this perform

gconftool-2 --recursive-unset /desktop/gnome/peripherals/keyboard

and reboot.

So I hope you have no problems furtherlonger.

THX for your help

Revision history for this message
Vojtech Vitek (V-Teq) (v-teq) wrote :

This bug also affected my keyboard, but the only key that didn't work was LEFT ARROW (mapped to no action).
Changing the keyboard model to Evdev fixed this.

Revision history for this message
TheFinePrint (rolmol) wrote :

Judging by the remapping this appears to be the same issue that affects NX-sessions.

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

The difference here is that the keyboard works as expected with no ill effects *locally*, but broken when in an NX-session. I cannot find any .Xmodmap-files anywhere in my home directory or lower.

Revision history for this message
PeteJ (pj08) wrote :

I had a gutsy thinkpad t21 laptop nx client connecting to a gutsy plain wrap freenx server working fine. Upgraded to Intrepid this morning and got the broken nav key problem in the nx session (up arrow opened Take screenshot and the other nav keys were borken too).

After reading tons, having no clue, flailing around, on both client and server I did System, Preferences, Keyboard, Layouts, "Evdev-managed keyboard" or similar, and then in the nx session, on the server, I did System, Preference, Keyboard shortcuts, Desktop, Take a screenshot. It was "Print", I pressed "Ctrl+PrtSc", it changed to "Ctrl+Print", and now ALL the nav keys work fine.

Revision history for this message
Martin Emrich (emme) wrote :

Since I removed the keyboard config from my xorg.conf (to let X.Org decide automatically with HAL), I have to do "setxkbmap -model evdev -layout de -variant nodeadkeys" after every login :(

@PeteJ: For NX-Related problems, I found Bug #289918 (which affects me, too)

Revision history for this message
Matthäus Brandl (matthaeus) wrote :

Well, thanks Muelli, mv'ing .gconf helps me as well, but having to reconfigure everything is quite annoying. It would be great to find the responsible key...

Revision history for this message
Matthäus Brandl (matthaeus) wrote :

Actually I found the responsible key, at least in my case. It's the Compiz plugin ezoom (Enhanced Desktop Zoom) which I actually don't use anymore. I removed the key with gconftool-2 and almost everything works fine. (Well would be nice to have the menu key as compose, but I guess that's just some fdi configuration...

Revision history for this message
Ciso (cisoprogressivo) wrote :

I solved the problem changing my keyboard to Edev, but still reproducing this bug after some reboot. I really don't know why.

Revision history for this message
Clément Léger (clem-vangelis) wrote :

modifying my xorg.conf with my old informations from hardy solve the problem :

Section "InputDevice"
    # generated from default
    Identifier "Keyboard0"
    Driver "kbd"
    Option "CoreKeyboard"
    Option "XkbRules" "xorg"
    Option "XkbModel" "pc105"
    Option "XkbLayout" "fr"
    Option "XkbVariant" "oss"
EndSection

Revision history for this message
Clément Léger (clem-vangelis) wrote :

Forget what i mention before , doesn't work instead of that just put :
Section "InputDevice"
    Identifier "Keyboard0"
    Driver "evdev"
    Option "CoreKeyboard"
EndSection
it will do the trick , anyway intrepid seems to be affected by a serious bug related to default keyboard driver...

Revision history for this message
Jeremy Cantrell (jmcantrell) wrote :

I'm curious about something before I start playing with my xorg.conf... my keyboard driver was "keyboard". What is the difference between it and "evdev" and "kbd"? What is the default in intrepid?

Revision history for this message
frankie (frankie-etsetb) wrote :

Hi. I tried everything listed in the comments before but I'm still unable to use some keys. Arrow down and Page UP
won't work. Thou arrow up and page down do.

I tried different things in xorg.conf: no keyboard entry, keyboad evdev and keyboard as it was with hardy. I didn't see a
different behaviour after restarting.

I made sure I don't have any imwheel package nore daemon. I also removed all compiz packages.

I also tried to run:
  setxkbmap -model evdev -layout es -option lv3:ralt_switch

and this:

  gconftool-2 --recursive-unset /desktop/gnome/peripherals/keyboard

I blacklisted the evdev module but then I had no mouse nor keyboard, so I removed that entry there.

apt-cache policy xserver-xorgx server-xorg-input-evdev

xserver-xorg:
  Installed: 1:7.4~5ubuntu3
  Candidate: 1:7.4~5ubuntu3
  Version table:
 *** 1:7.4~5ubuntu3 0
        500 http://es.archive.ubuntu.com intrepid/main Packages
        100 /var/lib/dpkg/status
xserver-xorg-input-evdev:
  Installed: 1:2.0.99+git20080912-0ubuntu5
  Candidate: 1:2.0.99+git20080912-0ubuntu5
  Version table:
 *** 1:2.0.99+git20080912-0ubuntu5 0
        500 http://es.archive.ubuntu.com intrepid/main Packages
        100 /var/lib/dpkg/status

Currently xorg.conf entries for keyboard and mouse are commented.

$ setxkbmap -print
xkb_keymap {
 xkb_keycodes { include "evdev+aliases(qwerty)" };
 xkb_types { include "complete" };
 xkb_compat { include "complete" };
 xkb_symbols { include "pc+es(cat)+inet(evdev)+level3(ralt_switch_for_alts_toggle)+group(alts_toggle)" };
 xkb_geometry { include "pc(pc104)" };
};

Any help would be appreciated, missing arrow down is hard for me.

Revision history for this message
Nil (nicolas-limare) wrote :

I have a japanese keyboard, panasonic Y5 laptop. The PgDown key doesn't work. Up-to-date intrepid packages.

* setting the keyboard model to evdev in the gnome configuration tool doesn't fix it.
* `sudo setxkbmap -model evdev -layout jp -variant 106` fixes the issue, but I guess I will have to do it after every reboot

The commented-out part of my xorg.conf is:
    #Section "InputDevice"
    # Identifier "Generic Keyboard"
    # Driver "kbd"
    # Option "CoreKeyboard"
    # Option "XkbRules" "xorg"
    # Option "XkbModel" "jp106"
    # Option "XkbLayout" "jp"
    # Option "XkbVariant" "106,"
    #EndSection

Revision history for this message
Harley Stenzel (harley) wrote :

There's a report on this issue over on NoMachine's site:

http://www.nomachine.com/tr/view.php?id=TR11F02131

For me, this workaround is acceptable (it also disables evdev):

Section "ServerFlags"
    Option "AutoAddDevices" "false"
EndSection

However, that report also incorrectly states that this issue is limited to intrepid to intrepid. I believe that it's seen on an intrepid NX client connecting to any other host. In my case, I see it with NX client connecting to a server running RHEL4.

Revision history for this message
albinootje (albinootje) wrote :

Weeks ago I ran into the same problem after starting to use Ubuntu Intrepid on my desktop.
I was using a FreeNX-server on CentOS 5.x, but by coincidence I was also testing a FreeNX-server with Ubuntu Intrepid.
In the Ubuntu FreeNX-server desktop I could change the keyboard to evdev, and on my own desktop too, and eventually it worked. (And I gave up the CentOS one, because there I could not fix it

But.. yesterday night I removed all of my dot gnome files and all other dot files for my user (except .profile and .bash* files) on the Intrepid FreeNX server to test OpenBox and ... the same keyboard problems happened

This page claims that there's a released fix :
https://bugs.launchpad.net/ubuntu/in...er/+bug/255008
but I didn't see any xorg updates for Intrepid, nor did the problem get fixed for my situation.
Am I missing something ?

Revision history for this message
Jos Dehaes (jos-dehaes) wrote :

Not fixed for me! If I connect from an intrepid client to a dapper nxserver, I get this problem. The printscreen key sends delete, arrow up sends print screen... How can I fix this?

Revision history for this message
Harley Stenzel (harley) wrote :

I also found that it helps to move up to most recent nx, if using the nomachine version. It seems that some keyboard mapping issues were fixed in recent updates.

Revision history for this message
mabawsa (mabawsa) wrote :

These commands fix the keyboard mapping for me. Please swap the -layout for your keyboard.

setxkbmap -model evdev -layout us
killall metacity

Revision history for this message
Tyson Williams (bender2k14) wrote :

This bug says that a fix is released (several times), but I still have this problem and have all updates installed.

Revision history for this message
Martin Emrich (emme) wrote :

Yes, I have it, too, I still have to run "setxkbmap -model evdev -layout de" after login.

Revision history for this message
mabawsa (mabawsa) wrote :

Did you try

killall metacity

?

Revision history for this message
Tyson Williams (bender2k14) wrote :

@mabawsa

I have the "us" layout and those two commands do not fix the problem for me. Also, there was no "metacity" running before executing the second command.

Revision history for this message
mabawsa (mabawsa) wrote :

@Bender2k14
Is this with an nx session? If so then this may help, if not I think its a different bug from what I have been seeing.

https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/289918/comments/26

Revision history for this message
Tyson Williams (bender2k14) wrote :

I am not in any remote session. I would be surprised if it were a different bug, but I do not know enough to make a stronger claim.

Revision history for this message
Tyson Williams (bender2k14) wrote :

Up (by itself) is still maps to PrintScreen fr me, but I realized today that both Ctrl-Up and Shift-Up work correctly (if that matters).

I have never consciously used Ctrl-Up before (normally Ctrl-Left and -Right jump the cursor over text), but it appears to be a workaround, at least in the context of text.

Revision history for this message
Tyson Williams (bender2k14) wrote :

I no long have this problem. I did try to do anything to fix it, and I did not notice any updates that would have fixed this bug for me.

Revision history for this message
Peter Hagen (peter-willowmedia) wrote :

I have the same problem with the arrow keys, but I'm trying to connect through an Ubuntu 8.10 server with freenx 0.7.3+svn612-0freenxteam11~intrepid1 to windows machines (vm's and real machines). I use the NX Java applet, but also when I try to connect from my Ubuntu 8.10 machine it won't work.

I also installed the NXServer from NoMachine on my workstation, and if I connect through that one to the win32 machines, and the keyboard does work correctly.

I also have a Debian server I can use to connect to the Win32 machines, which has the free NoMachine NXServer on it (with just 2 connections) and it has the same affect. Both servers are not configured to use X11. Might this have anything to do with it?

Revision history for this message
sam.watkins (swatkins) wrote :

To fix this bug, on the server type:

  apt-get install xkb-data

then type:

  setxkbmap

(or restart nx)

The file /usr/share/X11/xkb/rules/xorg is the file that was needed.

This could be fixed with a dependency in one of the nx packages.

As of now, the problem still occurs with the latest nx packages for debian and ubuntu (3.3.0) because they do not depend on xkb-data.

Revision history for this message
sam.watkins (swatkins) wrote :

sorry I didn't realise this bug report was not specifically about nx.

Revision history for this message
noamik (spam-noamik) wrote :

Problem still present when upgrading from 8.04 to 8.10 and even persists when upgrading further to 9.04.
It only affects existing users. When I create a new user, the keyboard is working as expected. However none of the above workarounds does fix all the issues for my existing user.
Best I can achieve is when setting keyboard to evdev after login to get any key working but the down cursor ...

Is there nobody who knows what I can do to get the keyboard settings of a new user to apply to my existing user?

Revision history for this message
noamik (spam-noamik) wrote :

I made and upgrade from ubuntu 8.04 to ubuntu 8.10 and experienced this very same problem. What ever has been done to fix the issue does only work for new installations and new users. The issue even persists when upgrading further to 9.04.
Proposed work arounds do not entirely fix the issue in all cases either ...

Changed in xorg-server (Ubuntu Intrepid):
status: Fix Released → Incomplete
Revision history for this message
noamik (spam-noamik) wrote :

As a work around I could fix remaining issues by "deleting" any xmodmap-related file of the affected users and changing keyboard layout again. I still consider it a bug when an dist-upgrade breaks prior keyboard configuration. It may be of minor importance though ...

tags: added: iso-testing
Revision history for this message
Friedrich Strohmaier (bitsfritz) wrote :

I've marked Bug #512622, filed myself, as duplcate of this bug. It is describing the "wiredness" mentioned in Bug #254939 which I also marked as duplcate. I'm aware it does so in a confusing manner.

Lucid Lynx is also affected.

In the essence my search which also led me here, ends up to following:

Introducing evdev managing keybords resulted in changing keymapping of the non ascii keys (guess!) in a non reasonable way. Did all that keyboards out there change the same? ;o))

At least this is incompatible to xmodmapfiles created for xfree86 driven keyboards.

from my point of view solution could be:

most elegant:
- make evdev output reasonble (i.e xfree86/xmodmap compatible, for all that
  keyboards out there already are ;o)) )

if evdev output is reasonable in any way (I don't believe):
- make xmodmap detect evdev driven keyboard and handle apropriately

or worse:
- kick xmodmap to avoid confusion

grml.org team (recent debian testing) solved that problem by managing the keybord by xfree86 and all the rest by evdev (don't know how, but it works as expected with my "old" xmodmap files)

Worst case in my opinion is to kick xmodmap, because we will loose "xkeycaps" - a great tool to manage complexity of keybord issues in a quit easy and portable manner.

I'm not really an expert, so maybe I'm lost completely with this.

Other conclusions ending in a working solution for this pain always apreciated. :o))

Revision history for this message
Friedrich Strohmaier (bitsfritz) wrote :

I think it is a good idea to make a decision how to handle this for lucid release.

Every LTS upgrader with a customized keyboardmapping will run in big trouble - every!

Revision history for this message
Sergio Zanchetta (primes2h) wrote :

Thank you for reporting this bug to Ubuntu. Intrepid Ibex 8.10 reached EOL on 30 March 2010.
Please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

Please feel free to report any other bugs you may find.
Thank you.

Changed in xorg-server (Ubuntu Intrepid):
status: Incomplete → Won't Fix
Revision history for this message
Sergio Zanchetta (primes2h) wrote :

I realized I had made a mistake, Intrepid Ibex 8.10 "will reach" EOL on 30 "APRIL" 2010.

Sorry for this.

Anyway, I think that one month doesn't make any difference now.

Changed in gnome-settings-daemon:
importance: Unknown → Medium
Changed in gentoo:
status: Fix Released → Won't Fix
Changed in gentoo:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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