Red Hat Bugzilla – Bug 68216
the screen cannot be unlocked
Last modified: 2014-03-16 22:28:38 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; zh-CN; rv:1.0.1) Gecko/20020625
Description of problem:
In the gnome session, I cannot unlock the screen after I've locked it.
I entered the password, but the screensaver neither accept the password,
nor reject it.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.install limbo using Simplified Chinese as the default language.
2.lock the screen in Gnome.
3.try to unlock the screen
Actual Results: The screensaver neither accept the password, nor reject it.
When timeout, the screensaver continues.
Expected Results: If I enter the right password, the screen is unlocked.
There is some error message when the "enter password" dialog shows,
it says "***parse error *** markup ***"
The system is a clean "limbo" installation.
The versions of the components are:
Does this happen in non-chinese locales?
That's the point.
When I change the locale from zh_CN.GB18030 to en_US.UTF-8,
then everything is right.The error message I mentioned above disappears too.
By the way, the full error message is
"xscreensaver-lock Gtk-WARNING: failed to set label from markup due to error
But I do want to work under Chinese locale!
I hope this bug can be fixed.
This probably has something to do with bug 37632, but I don't know what to do
about that one either, so someone who actually understands handling of
non-english keyboards is gonna have to tackle this...
The "failure to set label" error message is almost certainly unrelated to the
I've found that the problem is caused by minichinput, which is a XIM based
Chinese input method. If I do "killall chinput" before lock the screen, then I
can unlock the screen without any problem. So, I could unlock the screen under
non-Chinese locale, just because in that locale, chinput did not start.
There is another strange problem in limbo caused by minichinput:
If chinput is running, then one cannot enter "<" in gnome-terminal.
So, I think this bug can be classified as the bug of minichinput, or the
incompatibility between minichinput and xcreensaver, gnome-terminal etc.
Since this problem occurs only in limbo, which uses gnome2.
Maybe this is a incompatibility between chinput and gnome2?
I didn't test other input methods. If other input methods using XIM
also have this problem, then this is a problem between XIM and gnome2.
Maybe the hackers of GNOME can help us.
When miniChinput is up, and you active xscreensaver, miniChinput as IM server
will receive Input Context(IC) create request and Input Focus request from the
GTK password input entry box, this is correct. But at the same time, miniChinput
also receives a extra Input Context request, but no following Input Focus
request, don't know where this is come from. xscreensaver will reports bad
And everytime you active the password input entry window from funncy graphics
when saver is on, miniChinput will get all new IC and foucs request, I think
xscreensaver should send re-focus request instead.
Those are the weird things.
Following Owen Taylor's advice, putting following one line in lock-Gtk.c will fix.
I am more believe the bug is in XIM... I will build new xscreensaver package and
do more test.
Please test the latest xscreensaver-4.05-3 and gtk2-2.0.6-2.
The problem no longer exists.I can now unlock the screen.
But the "no < in gnome-terminal" problem still exists.
I fixed the '<' problem a couple of days ago ... the fix is in gtk2-2.0.6-3
(not sure if it is in Raw Hide yet.)