Hi there, I added Persian to my keyboard layouts. When I'm in Persian state, pressing both alt keys will change it to English mode, but when I'm in English mode, when I press both alts, no change is made and I have to click on the keyboard indicator to change it. # rpm -qa | grep keyboard xorg-x11-drv-keyboard-1.3.0-3.fc9.i386 system-config-keyboard-1.2.15-2.fc9.noarch xkeyboard-config-1.2-3.fc9.noarch Best, adrin.
You could not have added a layout with system-config-keyboard, it supports only one keyboard layout. You probably used gnome-keyboard-properties. This sounds like an issue with the keyboard layout itself, I've seen a similar thing with ALT key and Slovak keyboard before, reassigning to xkeyboard-config
I just didn't know which component to choose :D I asked from #fedora@freenode and #fedora-devel@freenode but none of them responded. So I chose the one I thought it might be relative to my problem.
By the way, changing settings to alt+shift keys is a workarround
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server config file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. Could you please also try to run without any /etc/X11/xorg.conf whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Sorry, don't bother with running Xorg without /etc/X11/xorg.conf -- we just need to know, what Xorg thinks your keyboard is.
Created attachment 304481 [details] xorg.conf If it's needed, I can start my X without xorg.conf
Created attachment 304482 [details] xorg log
is it related ? : here is the result: $ mplayer any_media MPlayer SVN-r25979 rpm.livna.org (C) 2000-2007 MPlayer Team CPU: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz (Family: 6, Model: 15, Stepping: 6) CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Compiled with runtime CPU detection. Creating config file: /home/artemis/.mplayer/config mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Playing /media/Local_Disk/Video/superman_electric_earthquake.mpg. MPEG-PS file format detected. VIDEO: MPEG1 320x240 (aspect 1) 29.970 fps 1024.0 kbps (128.0 kbyte/s) ========================================================================== Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough VDec: vo config request - 320 x 240 (preferred colorspace: Mpeg PES) Could not find matching colorspace - retrying with -vf scale... Opening video filter: [scale] The selected video_out device is incompatible with this codec. Try appending the scale filter to your filter list, e.g. -vf spp,scale instead of -vf spp. VDecoder init failed :( Opening video decoder: [libmpeg2] MPEG 1/2 Video decoder libmpeg2-v0.4.0b Selected video codec: [mpeg12] vfm: libmpeg2 (MPEG-1 or 2 (libmpeg2)) ========================================================================== ========================================================================== Opening audio decoder: [mp3lib] MPEG layer-2, layer-3 AUDIO: 44100 Hz, 2 ch, s16le, 64.0 kbit/4.54% (ratio: 8000->176400) Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3) ========================================================================== AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample) Starting playback... VDec: vo config request - 320 x 240 (preferred colorspace: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 1.33:1 - prescaling to correct movie aspect. VO: [xv] 320x240 => 320x240 Planar YV12 X11 error: BadAlloc (insufficient resources for operation)?,?% 1 0 X11 error: BadAlloc (insufficient resources for operation)?,?% 1 0 X11 error: BadAlloc (insufficient resources for operation)?,?% 1 0 X11 error: BadAlloc (insufficient resources for operation)?,?% 1 0 X11 error: BadAlloc (insufficient resources for operation)?,?% 1 0 X11 error: BadAlloc (insufficient resources for operation)?,?% 1 0 X11 error: BadAlloc (insufficient resources for operation)?,?% 1 0 X11 error: BadAlloc (insufficient resources for operation)?,?% 1 0 X11 error: BadAlloc (insufficient resources for operation)?,?% 1 0 X11 error: BadAlloc (insufficient resources for operation)?,?% 1 0 X11 error: BadAlloc (insufficient resources for operation)?,?% 1 0 X11 error: BadAlloc (insufficient resources for operation)?,?% 1 0 X11 error: BadAlloc (insufficient resources for operation)?,?% 1 0 X11 error: BadAlloc (insufficient resources for operation)0.4% 1 0 X11 error: BadAlloc (insufficient resources for operation)0.4% 1 0 X11 error: BadAlloc (insufficient resources for operation)0.4% 1 0 X11 error: BadAlloc (insufficient resources for operation)0.3% 1 0 X11 error: BadAlloc (insufficient resources for operation) X11 error: BadAlloc (insufficient resources for operation)0.4% 1 0 X11 error: BadAlloc (insufficient resources for operation)0.3% 1 0 X11 error: BadAlloc (insufficient resources for operation) X11 error: BadAlloc (insufficient resources for operation)0.3% 1 0 X11 error: BadAlloc (insufficient resources for operation)0.3% 1 0 X11 error: BadAlloc (insufficient resources for operation)0.3% 1 0 X11 error: BadAlloc (insufficient resources for operation)0.3% 1 0 X11 error: BadAlloc (insufficient resources for operation)0.3% 1 0 X11 error: BadAlloc (insufficient resources for operation)0.3% 1 0 X11 error: BadAlloc (insufficient resources for operation)0.3% 1 0 X11 error: BadAlloc (insufficient resources for operation)0.3% 1 0 X11 error: BadAlloc (insufficient resources for operation)0.3% 1 0 X11 error: BadAlloc (insufficient resources for operation)0.3% 1 0
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I confirm the bug on F9. Alt+Alt Gr doesn't work on the USA layout, but it does on the LAm one.
For a user who has fingers which are used to switch keyboard layout this is a major annoyance after upgrading. I hope a good solution will be found even tough the priority is low - right now I think it should be quite high. I was about to file a new bug against gnome-applets-2.22.1-2.fc9.i386 but found and will use this instead. I assumed the problem was in the "Keyboard Layout Indicator", but I really don't know how the components play together. I have tried to nail the problem down, but hasn't found any pattern yet. Changing the xorg.conf layout from "us+inet" to "us" (see bug bug 367441) seemed to help ... but perhaps was it just the restart of X that did something. Changing Keyboard Model from Generic 105 intl to Dell USB Multimedia keyboard seemed to change something ... but not really anyway. Using another US layout than the default (which for me was us+inet) seemed to solve it .. but suddenly it didn't. And sometimes the Alt key didn't work at all so that I couldn't switch application with Alt+Tab. So right now I can only conclude that I'm confused and that there definitely is going something on which shouldn't be going on...
I would like to add that "Show Current Layout" shows that it (always?) understands when which keys are pressed. So we can see on the on-screen-keyboard that it knows when both alt keys are pressed, and we know that when we click on the panel icon then the layout is changed. So the ends are quite close to each other, and we have verified that it gets the correct input (key presses) and that the output (changing layout) works. So it must be a problem internally in the keyboard applet.
It's not a problem of the applet, changing the layout is not working for me. I can see on the "current layout" dialog that the keys seem to be recognized, whatever ISO_L... actually means. By the way, it would be nice if the dialog changed as the keyboard layout changes too.
I've changed the order of my layouts and added the Finnish layout. The first layout is always having the problem, now LAm (#1) doesn't change, where as Fin (#2) and USA (#3) does.
I have done some research, and now I know more than I ever wanted to know about x keyboard configuration. This issue is tracked upstream on http://bugs.freedesktop.org/show_bug.cgi?id=16164 I have proposed a patch which works for me. Is it fixing your problem too?
(mcepl just added keyword Patch) Be aware of the upstream discussion: The patch might be usable as a workaround, but it reintroduces another bug. The other bug might be the same as Fedora Bug 203978.
(In reply to comment #16) > (mcepl just added keyword Patch) > > Be aware of the upstream discussion: The patch might be usable as a > workaround, but it reintroduces another bug. > > The other bug might be the same as Fedora Bug 203978. Don't worry, adding Patch has no relevance whatsoever -- it means "There is something resembling patch", but I have no right whatsoever to say anything about its quality. And even if I say anything, no-one would believe me ;-) -- which is good.
I have the same bug when switching between USA and Armenian keyboard layouts. I also don't have an xorg.conf file. Changing the layout switching key combination to "Alt+Shift" works as a workaround. "Alt+Alt" key combination never worked for me.
Just as a summary: The major cause of the whole issue is the XKM format used by xkbcomp and the server to exchange xkb settings. XKM lacks a specific bit, thus losing the virtualModifiers lines in the key_types section. http://bugs.freedesktop.org/show_bug.cgi?id=4927 This bug was triggered by merging the fix to another bug which caused modifier releases to send different keysyms on release. http://bugs.freedesktop.org/show_bug.cgi?id=7430 In short, upstream needs to drop the xkm format. Until then, there isn't much we can do and the best "fix" is to use alt+shift instead of alts.
I agree. But that seems to be a major task which won't happen "soon". Meanwhile the keyboard config should use another default - and perhaps remove the bogus options completely. That seems to be the best resolution for this specific bz issue.
I play(In reply to comment #20) > Meanwhile the keyboard config should use another default - and perhaps remove > the bogus options completely. That seems to be the best resolution for this > specific bz issue. I played around with it today and this is not a xkeyboard-config default. Try it yourself: setxkbmap -layout us -option "" (if you had alts_toggle set before, this unsets it) setxkbmap -layout us,de setxkbmap -print There's no alts_toggle option anywhere, you'd have to specify this explicitly, e.g. through setxkbmap -layout us,de -option "grp(alts_toggle)" Or by ticking the box GUI tool of course. Can you please clarify what you're referring to as "default" here?
In GNOME in Fedora 9 and Fedora 10 beta every time I add the keyboard layout switcher applet to the panel the layout switching key combination is set to "Both Alts" which does not work. I have to manually set it to "Alt+Shift" combination which works fine.
maybe this is a gnome-applets bug?
Opened Bug 465403 for control-center for this issue. I'm taking this bug off the F10Blocker bug because there's no way we can fix the xkeyboard-config issue in time for F10. Bug 465403 is on F10Blocker instead. UPSTREAM it is for this bug.
*** Bug 458532 has been marked as a duplicate of this bug. ***