[Input methods] Keyboard stops working after Ctrl+Shift+U followed by 7 alphanumeric keys

[Egmont Koblinger]

Press Ctrl+Shift+U (start entering a Unicode character by its hex code), followed by seven alphanumeric characters.

The keyboard stops working. It's no longer possible to enter any keys into any application, making the system completely unusable. (Tested with gnome-terminal, firefox, gedit, konsole, xterm.)

Unity shortcut keys (Alt+Tab etc.) still work.

The keyboard layout switcher (Alt+Shift for me) works and resets the keyboard so it's back to normal, although it shouldn't be required, and many users probably don't have such a key defined, or wouldn't figure out they need to press it after the lockup.

Side note: After Ctrl+Shift+U, not only hex digits but any letters are accepted and accumulated as the hexadecimal character code, this doesn't make any sense to me.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: xorg 1:7.7+1ubuntu6
ProcVersionSignature: Ubuntu 3.11.0-14.21-generic 3.11.7
Uname: Linux 3.11.0-14-generic x86_64
.tmp.unity.support.test.0:

ApportVersion: 2.12.5-0ubuntu2.1
Architecture: amd64
CompizPlugins: [core,composite,opengl,compiztoolbox,decor,move,resize,place,imgpng,snap,session,mousepoll,scale,resizeinfo,gnomecompat,regex,animation,expo,workarounds,ezoom,unityshell]
CompositorRunning: compiz
CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
CompositorUnredirectFSW: true
Date: Sat Dec 21 00:00:22 2013
DistroCodename: saucy
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes
GpuHangFrequency: I don't know
GraphicsCard:
 Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0116] (rev 09) (prog-if 00 [VGA controller])
   Subsystem: Samsung Electronics Co Ltd Device [144d:c606]
InstallationDate: Installed on 2012-05-30 (569 days ago)
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
MachineType: SAMSUNG ELECTRONICS CO., LTD. 300E4Z/300E5Z/300E7Z
MarkForUpload: True
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.11.0-14-generic root=UUID=570ce59e-b28f-434e-9aef-b608ff12622d ro quiet splash vt.handoff=7
SourcePackage: xorg
Symptom: display
Title: Xorg freeze
UpgradeStatus: Upgraded to saucy on 2013-10-12 (69 days ago)
dmi.bios.date: 12/14/2011
dmi.bios.vendor: Phoenix Technologies Ltd.
dmi.bios.version: 03QB
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: 300E4Z/300E5Z/300E7Z
dmi.board.vendor: SAMSUNG ELECTRONICS CO., LTD.
dmi.board.version: FAB1
dmi.chassis.asset.tag: Asset Tag
dmi.chassis.type: 9
dmi.chassis.vendor: SAMSUNG ELECTRONICS CO., LTD.
dmi.chassis.version: 0.1
dmi.modalias: dmi:bvnPhoenixTechnologiesLtd.:bvr03QB:bd12/14/2011:svnSAMSUNGELECTRONICSCO.,LTD.:pn300E4Z/300E5Z/300E7Z:pvr0.1:rvnSAMSUNGELECTRONICSCO.,LTD.:rn300E4Z/300E5Z/300E7Z:rvrFAB1:cvnSAMSUNGELECTRONICSCO.,LTD.:ct9:cvr0.1:
dmi.product.name: 300E4Z/300E5Z/300E7Z
dmi.product.version: 0.1
dmi.sys.vendor: SAMSUNG ELECTRONICS CO., LTD.
version.compiz: compiz 1:0.9.10+13.10.20131011-0ubuntu1
version.ia32-libs: ia32-libs 20090808ubuntu36
version.libdrm2: libdrm2 2.4.46-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 9.2.1-1ubuntu3
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 9.2.1-1ubuntu3
version.xserver-xorg-core: xserver-xorg-core 2:1.14.3-3ubuntu2
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.3-0ubuntu3.1
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.2.0-0ubuntu10
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.904-0ubuntu2
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.9-2ubuntu1
xserver.bootTime: Fri Dec 20 23:57:12 2013
xserver.configfile: default
xserver.errors:

xserver.logfile: /var/log/Xorg.0.log
xserver.outputs:
 product id 12874
 vendor SEC
xserver.version: 2:1.14.3-3ubuntu2

[penalvch (penalvch)]

Egmont Koblinger, could you please provide the full computer model as noted on the sticker (ex. NP-RF511-S03SE)?

[Egmont Koblinger (egmont-gmail)]

Yup, it's NP300E5Z -- is it really relevant? Sounds like a software only problem to me :)

[Egmont Koblinger (egmont-gmail)]

More precisely, as found on another sticker: NP300E5Z-S07HU (it has a Hungarian layout)

[penalvch (penalvch)]

Egmont Koblinger, thank you for providing the requested information. At this point, to say this is a software issue only is premature. Despite this, because Samsung does not easily reveal what the latest BIOS is for this model, could you please download the latest firmware software as per http://www.samsung.com/hu/support/model/NP300E5A-S07HU-downloads, and advise if a BIOS update is available? If so, when you update to this, does it change anything? If it doesn't, could you please both specify what happened, and provide the output of the following terminal command:
sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date

Please note your current BIOS is already in the Bug Description, so posting this on the old BIOS would not be helpful.

For more on BIOS updates and linux, please see https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette .

Thank you for your understanding.

[Egmont Koblinger (egmont-gmail)]

Hi Christopher,

This is most definitely *not* a hardware issue, but something with X or Gtk or Unity or Compiz, or something along these lines.

The bug is triggered by a certain key sequence of entering too many digits to Unicode characters. In the resulted state, certain keys (whichever are configured to do something in Unity, e.g. Alt+F2) still work, only the ones that are supposed to deliver letters into applications stop working. There's no way the hardware could know anything about this.

Moreover, I've just tried starting "xev" and pressing letters to this. xev properly reports all the keys I press. It's only the "normal" applications on my desktop (gnome-terminal, firefox, the window I get for Alt+F2 etc.) that stop accepting these letter in their input fields. Again, it's impossible that the hardware would properly generate letters for xev but not for firefox.

[Launchpad Janitor (janitor)]

[Expired for xorg (Ubuntu) because there has been no activity for 60 days.]

[Egmont Koblinger (egmont-gmail)]

The bug is still present in Trusty.

I've installed a Fedora 20, and it's working correctly there. Note that Ctrl+Shift+U works in xterm under Ubuntu, but does nothing in xterm under Fedora. This means that probably something is done substantially differenty in the two distros. I have a feeling that this keycombo is handled by Gtk+ in Fedora, but Ubuntu somehow made it more generic and patched it to X.Org – is this possible?

[Egmont Koblinger (egmont-gmail)]

Gtk+ apps: Reproducible with GTK_IM_MODULE=ibus and with GTK_IM_MODULE=xim. Not reproducible if GTK_IM_MODULE is unset before launching a Gtk+ app [I guess Ctrl+Shift+U is handled by Gtk+ in this case, rather than the X Input Method].

xterm: Reproducible with the default XMODIFIERS=@im=ibus, not reproducible after unsetting this variable [in this case Ctrl+Shift+U has no special effect].

Really looks that the bug resides in X Input Methods.

[Egmont Koblinger (egmont-gmail)]

I've located the bug. Upstream report: https://code.google.com/p/ibus/issues/detail?id=1715

[Egmont Koblinger (egmont-gmail)]

Dear Christopher,

Seeing that Ubuntu developers did nothing to locate this bug other than you guessing this might be a hardware issue – which was not an unreasonable guess, but I already proved wrong a long time ago – I finally took the time to locate this. I found which package causes the problem, located the bug in the source code, explained why it is buggy, and – even though I did not mention this – created for myself a one-line proof-of-concept patch (not suitable for mainstream commit), recompiled and installed the ibus package, and saw the bug indeed gone.

Please stop assuming it's a hardware or bios issue. It is absolutely clearly not.

Instead, please repeat the same steps I described in the original report on your default Ubuntu installations. I'm pretty sure you'll face the same behavior. (And in the unlikely case that you don't, you should clearly state this.) Thanks!

[Egmont Koblinger (egmont-gmail)]

To be absolutely clear: The keys have to pressed when the focus is in an input field, that is, where you'd normally type something. E.g. a gnome-terminal. Pressing Ctrl+Shift+U enters a special mode where you type a Unicode character by its hex code. If you type at most 6 digits and then press Enter or Space, the typed value is converted to a Unicode character of that codepoint. E.g. press Ctrl+Shift+U, type 4000 and press Space, you'll see a Japanese or Chinese (I don't know, sorry) symbol. But if you press Ctrl+Shift+U, followed by 7 digits, you'll see a nasty lockup. (Be sure to save all your data before!)

[Egmont Koblinger (egmont-gmail)]

I don't know what to say now.