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

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

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

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

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.

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.

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

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?

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.

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

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!

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!)

I don't know what to say now.