> The "don't enqueue stuff" semantics of K_OFF shouldn't be a function of > the keyboard map state; we should be able to switch among cooked/raw/ > unicode without changing whether events are delivered. Otherwise - if > changing to K_UNICODE undoes K_OFF - then suddenly Alt-F2 under > Gnome will switch VT instead of summoning the "run command" dialog.
A patch to disable the muting should be added to the SysRq handler for the "unRaw" action. I do not think that KBMODE is only about the keyboard map. The behaviours that KBMODE influences are: -Whether input is generated. -Whether input is buffered by line. -Whether key events are put through the keymap and translated by modifiers or sent as raw keyup/down events. -Whether the keymap is unicode. -Whether special keys are interpreted by the kernel. The meaning of KBMODE is a bit overloaded It does make sense to split the generate / don't generate input into its own ioctl. However, IMO this change is part of an incomplete fix to a user space problem. The issue creating a need for moving the generate / don't generate input to its own ioctl was that through some plumbing, when changing the keymap setting in an X graphical environment session systemd is told to switch the console keymap. As part of switching the keymap, if unicode is selected, systemd blindly calls KDSKBMODE with K_UNICODE. This currently messes up X, which this change attempts to address. I'm not sure if letting systemd freely meddle with KBMODE and moving the important-for-X behaviour to another ioctl is such a wise idea. systemd already changes the kernel default KBMODE to/from unicode by a module parameter. Further, this will only work with newer or patched X servers. Depending on the input configuration and drivers used by X, either the input system is used directly and the virtual console keyboard is ignored, or X uses the virtual console keyboard for input and switches it into RAW mode. In both modes X does not want the kernel to interpret special keys. In the former mode X doesn't want the kernel to generate input (as otherwise it needs to periodically flush a buffer it never reads to stop it from overflowing and causing a kworker to go nuts), in the later mode X wants raw key up/down events which are not line buffered. Setting the console to K_UNICODE is none of these things and causes one of many possible problems. KBMODE (like the console keymap) is a virtual console setting which is stored in the virtual terminal and saved/restored from the console upon a VT switch. X is usually run on a VT it allocates and then closes on exit, but you can also specify a VT for X to run on which could already have been open by another process (say getty.) In either case, X saves the KBMODE of the VT during initialization and restores it upon exit. systemd calling KDSKBMODE on a VT which X is running either has no affect or a negative affect on X. In the rare case that X is started on a VT with another text mode cooked input process, KBMODE is unaffected after X exits. -Art -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/