In XScreensaver unlock screen it is not possible to insert "€" sign

Bug #671923 reported by Mart Mangus on 2010-11-06
This bug affects 4 people
Affects Status Importance Assigned to Milestone
xscreensaver (Ubuntu)

Bug Description

Binary package hint: xscreensaver

When trying to unlock the screen (locked by pressing Ctrl+Alt+Del or coming from suspend/hibernate) XScreensaver asks for user password. But in password field it is not possible to insert "€" sign (any other input is showing one more "*" in password field). So, when user's password is including "€" sign, then it is not possible to unlock the screen!

Using Estonian keyboard and "€" sign comes with keys AltGr+e and it works in all other programs.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: xscreensaver 5.11-1ubuntu2
ProcVersionSignature: Ubuntu 2.6.35-22.35-generic
Uname: Linux 2.6.35-22-generic x86_64
Architecture: amd64
Date: Sat Nov 6 21:22:22 2010
InstallationMedia: Xubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101008.1)
SourcePackage: xscreensaver

Related branches

Mart Mangus (mart-idnet) wrote :
Mart Mangus (mart-idnet) wrote :

Also: it is possible to insert signs like "$%&" and so on, but only "€" is failing.

Charlie Kravetz (charlie-tca) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. We need some more information from you before we can start working on this bug. If the problem is reproducible, please type the following into a terminal:

      xscreensaver-command -exit
      xscreensaver -verbose -log xscreensaver-log.txt

That will re-start xscreensaver and append diagnostics to the "xscreensaver-log.txt" file. When the problem happens again, attach the xscreensaver-log.txt file to this report.

Changed in xscreensaver (Ubuntu):
status: New → Incomplete
Charlie Kravetz (charlie-tca) wrote :

We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!

Mart Mangus (mart-idnet) wrote :
Charlie Kravetz (charlie-tca) wrote :

Thanks for reporting this bug and any supporting documentation. Since this bug has enough information provided for a developer to begin work, I'm going to mark it as confirmed and let them handle it from here.

This bug has been reported to the developers of the software. It was reported to jwz, the developer, following the procedure at

Thanks for taking the time to make Ubuntu better!

Changed in xscreensaver (Ubuntu):
importance: Undecided → Medium
status: Incomplete → Triaged
Jamie Zawinski (jwz) wrote :

I don't know why this would fail, and I don't know how to debug it. The code looks correct to me. I suspect the place to start looking is somewhere around

  int size = XLookupString (event, s, 1, 0, compose_status);

on line 1701 of driver/lock.c.

Please let me know if you figure it out...

Nokir (nokir) wrote :

I can reproduce this with umlaut 'ö'. Seems to be a problem with chars higher than 127.

Nokir (nokir) wrote :

Forgot to mention: Happens with Xuuntu Natty Alpha 2

Nokir (nokir) wrote :

I found the problem. Your code expects one byte per character, but XLookupString returns an utf-8 character which can have up to 4 bytes. I patched lock.c to support up to 4 bytes, a diff is attached. Of course it's just a dirty hack, detection of non-printable characters is partially disabled, stars are shown for each byte instead of each entered letter, backspace works bytewise instead of character-wise and it may have further shortcomings. But it works for me with umlaut ö in my password.

tags: added: patch
Nokir (nokir) wrote :

Here is another patch which makes backspace work character-wise .

Nokir (nokir) wrote :

Jus noticed: Last patch will introduce wrong backspace behaviour for iso-charsets.

Jamie Zawinski (jwz) wrote :

I appreciate the effort, but this patch cannot be correct.

First of all, the documentation for XLookupString clearly says, "the KeySym is mapped, if possible, to an ISO Latin-1 character or (if the Control modifier is on) to an ASCII control character".

In other words, XLookupString only works on Latin1 single-byte characters.

You seem to be in an environment where XLookupString is returning 4-byte characters that also happen to be Unicode. I see no documentation to suggest that A) this can ever happen, or B) if it did happen, that those bytes would be Unicode! Unless you can find some documentation to this effect, I cannot depend on this behavior in XScreenSaver.

And this, especially, is wrong:

> /* Bytes with bitmask 10xxxxxx are aditional bytes, search for first byte of character */

Bytes with 10 as their highest two bits are perfectly valid Latin1 characters, ranging from A0 (nonbreaking space) through BF (inverted question-mark), and including many common symbols like "copyright", "paragraph", and "1/4".

I suspect the "right" way to fix this is to use XwcLookupString(), which returns a wchar_t, instead of XLookupString(), but I couldn't begin to guess how I take the wchar_t* array and convert it into something that I can stick in a pam_response structure and have it work. (Or, even worse, run it through crypt() and compare it to what's in /etc/passwd.)

In summary: I'm glad you found a way to make it work on your particular computer, with your particular set of environment variable settings, but until someone shows me a theory of operation explaining why this should work at all, I can't use this code.


tags: added: patch-needswork
removed: patch
Nokir (nokir) wrote :

XLockupString() does (in contrary to the documentation) respect the locale-settings. I startet xev with three different LC_ALL settings and pressed the euro-key each time (see below).

You're right, my second patch only works for utf-8 charset which can't be assumed. But the first patch will work always as long as XLockupString() and pam or /etc/shadow use the same charset and the charset has not more than four bytes per char (As far as I know no such charset is in use). The first patch won't break any existing functionality.

If this problem isn't going to be solved, I think I should file a bug to use gnome-screensaver as default since a password dialog that doesn't support all common characters is simply broken.


LC_ALL=de_DE.iso885915 xev

KeyPress event, serial 34, synthetic NO, window 0x3e00001,
    root 0xb0, subw 0x0, time 233087494, (426,266), root:(856,597),
    state 0x90, keycode 26 (keysym 0x20ac, EuroSign), same_screen YES,
    XLookupString gives 1 bytes: (a4) "�"
    XmbLookupString gives 1 bytes: (a4) "�"
    XFilterEvent returns: False

LC_ALL=de_DE.utf8 xev

KeyPress event, serial 34, synthetic NO, window 0x4200001,
    root 0xb0, subw 0x0, time 233163518, (88,257), root:(518,588),
    state 0x90, keycode 26 (keysym 0x20ac, EuroSign), same_screen YES,
    XLookupString gives 3 bytes: (e2 82 ac) "€"
    XmbLookupString gives 3 bytes: (e2 82 ac) "€"
    XFilterEvent returns: False

LC_ALL=ru_RU.koi8r xev

KeyPress event, serial 34, synthetic NO, window 0x4200001,
    root 0xb0, subw 0x0, time 233219414, (-27,405), root:(403,736),
    state 0x90, keycode 26 (keysym 0x20ac, EuroSign), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

Nokir (nokir) wrote :

But you're right, XwcLookupString() would be the better way since it can deal with dead keys (as much as XmbLookupString()). Find below the output of xev when pressing dead-´ and then e, which should be combined to é.
If you don't want to deal with wchar, you could use XmbLookupString() and handle the backspace and number-of-stars-to-display issues yourself by saving the number of bytes for each character somewhere.


KeyPress event, serial 31, synthetic NO, window 0x4400001,
    root 0xb0, subw 0x0, time 235600638, (16,71), root:(446,402),
    state 0x10, keycode 21 (keysym 0xfe51, dead_acute), same_screen YES,
    XLookupString gives 2 bytes: (c2 b4) "´"
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: True

KeyPress event, serial 34, synthetic NO, window 0x4400001,
    root 0xb0, subw 0x0, time 235606934, (16,71), root:(446,402),
    state 0x10, keycode 26 (keysym 0x65, e), same_screen YES,
    XLookupString gives 1 bytes: (65) "e"
    XmbLookupString gives 1 bytes: (65) "e"
    XFilterEvent returns: True

KeyPress event, serial 34, synthetic NO, window 0x4400001,
    root 0xb0, subw 0x0, time 235606934, (16,71), root:(446,402),
    state 0x10, keycode 0 (keysym 0xe9, eacute), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 2 bytes: (c3 a9) "é"
    XFilterEvent returns: False

Mamoru TASAKA (mtasaka) wrote :

Did someone try xscreensaver 5.14 for this issue?

b3nmore (b3nmore) wrote :

Yep, tested 5.14 with the i386 and amd64 oneiric binaries on my natty systems and it's still the same issue: when entering '€' no star appears and unlocking doesn't work.

On Jul 9, 2011, at 12:34 AM, Kiran Majer wrote:

> Yep, tested 5.14 with the i386 and amd64 oneiric binaries on my natty
> systems and it's still the same issue: when entering '€' no star appears
> and unlocking doesn't work.

Beats me. It works on my machine. So at this point, someone who is actually experiencing this problem is going to have to debug it.

Look at xscreensaver/lock.c around line 1741. There are some commented-out debugging printfs there.

Jamie Zawinski

Nokir (nokir) wrote :

I tried 5.12 with the patch attached (it makes xscreensaver handle multibyte chars as multiple single byte chars and adds the debugging from 5.14) and 5.14 unpatched on Natty.
I entered ö€ and got this (i made the debugging be in hex instead of oct):

xscreensaver 5.12:
## odiaeresis => 2 ö c3 b6
## ISO_Level3_Shift => 0
## EuroSign => 3 € e3 82 ac

xscreensaver 5.14:
## odiaeresis => 1 ö f6
## ISO_Level3_Shift => 0
## EuroSign => 0

So in 5.12 XLookupString() returns utf-8 chars and in 5.14 iso8859-1. So on Natty it won't work for ö because the shadow file is in utf-8 and it will work even less for € since this char can't be encoded in iso8859-1.

Jamie Zawinski (jwz) wrote :

Try playing around with the various locale-related environment variables before launching the xscreensaver daemon.

It *may* be that to make this work it's necessary for xscreensaver to call setlocale(), which it did briefly (possibly only in 5.12) but I turned that off because it screws everything up. See comment in xscreensaver.c:

  /* It turns out that if we do NLS stuff here, people running in Japanese
     locales get font craziness on the password dialog, presumably because
     it is displaying Japanese characters in a non-Japanese font. I don't
     understand how to automatically make all this crap work properly by
     default, so until someone sends me a better patch, just leave it off
     and run the daemon in English. -- jwz, 29-Sep-2010

  if (!setlocale (LC_ALL, ""))
    fprintf (stderr, "locale not supported by C library\n");

  bindtextdomain (GETTEXT_PACKAGE, LOCALEDIR);
  textdomain (GETTEXT_PACKAGE);
#endif /* ENABLE_NLS */

Nokir (nokir) wrote :

LANG is already set to de_DE.utf8, and `LC_ALL=de_DE.utf8 xscreensaver ` does the same as `xscreensaver`.
If I delete that line with #undef ENABLE_NLS, 5.14 works fine.

Jamie Zawinski (jwz) wrote :

On Jul 9, 2011, at 11:39 AM, Nokir wrote:

> If I delete that line with #undef ENABLE_NLS, 5.14 works fine.

Sigh... well it completely screws up the dialog box in Japanese, so that's not a complete fix.

I wonder if there's some combination of locale settings that would make it send multi-byte input without also putting it in screw-up-the-fonts mode.

If this attachment works, it's a picture of the failure mode with LANG=ja_JP.UTF-8 --

Mamoru TASAKA (mtasaka) wrote :

So something like attached is needed?

Jamie Zawinski (jwz) wrote :

I strongly suspect that won't work, because calling setlocale() at all changes things in a way that setlocale(oldlocale) won't restore. I believe (though I can't prove it right now) that there's no way to return to the state of "I never called setlocale at all".

Jamie Zawinski (jwz) wrote :

FWIW, Here's the image I tried to email.

Nokir (nokir) wrote :

If I use `LANG=ja_JP.UTF-8 xscreensaver`, only the date is scrambled, but not the word "Password".

However, maybe this can be solved by using
    setlocale (LC_CTYPE, "")
instead of
    setlocale (LC_ALL, "")

Mamoru TASAKA (mtasaka) wrote :

> If I use `LANG=ja_JP.UTF-8 xscreensaver`, only the date is scrambled,
> but not the word "Password".

Well, if I comment out #undef ENABLE_NLS in xscreensaver.c around line 1410, I still see garbage messages on both date and "Password" in LANG=ja_JP.UTF-8 (note that you can see the name "tasaka1" in the picture Jamie attached).

The scrambled "Password" string is actually returned from pam. Maybe you are using other authentification mechanism.

Nokir (nokir) wrote :

I'm not sure, but I think xscreensaver uses /etc/shaddow on my machine.

setlocale (LC_CTYPE, "") should work, since the "Password" string is localized by LC_MESSAGES (At least I think it is, I can't test) and the date is localized by LC_TIME.

On my machine, the date is fine when using setlocale (LC_CTYPE, "") with LANG=ja_JP.UTF-8.

Jamie Zawinski (jwz) wrote :

So I guess we still don't know what the right thing is to do about this?

Nokir (nokir) wrote :

With setlocale(LC_TYPE, ""), everything works as expected on my machine, even with LANG=ja_JP.UTF-8. Maybe some others should test this.

Mamoru TASAKA (mtasaka) wrote :

I use ASCII characters only and currently I cannot check this. However do some people know some evidence that XLookupString checks LC_CTYPE?

Nokir (nokir) wrote :

Just tried 5.15, it works fine.

rm (rm) wrote :

Great, now I have to do three attempts on average, to enter my password.
You see, I have both English and Cyrillic (Russian) input layouts installed.
Before this change, typing in Russian in the password field simply did not work (did not add any characters), so I immediately knew the selected keyboard layout is wrong, and I have to switch it.
There is no other indication of the selected keyboard layout on the password entry window.
But now, typing Russian also works, so I have to guess that I in fact have the wrong layout by entering my whole password (it's in ******* so I can't see, obviously!), getting an Authentification failed, guessing "oh I must have mistyped somewhere", typing it again, getting one more Authentification failed, finally understanding "oh it must be the keyboard layout", switching it, and typing the password for the third time, successfully at last.
If your password contains an € sign, how about you stop being such a special snowflake and change it so that it doesn't.

Nokir (nokir) wrote :

How about displaying the keyboard layout in the password window?

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xscreensaver - 5.15-2ubuntu1

xscreensaver (5.15-2ubuntu1) precise; urgency=low

  * Merge with Debian testing, remaining Ubuntu changes:
    - debian/control:
      + Add Vcs-Bzr link
      + Add/Update replaces with Ubuntu versions
      + Update package descriptions to list Ubuntu screensavers
    - debian/rules:
      + Use /usr/share/backgrounds as image directory
      + Add translation domain to .desktop files
    - debian/
      + Add apport hook
    - debian/split-hacks.config:
      + Use different set of default hacks than Debian
    - debian/xscreensaver.dirs
      + Install /usr/share/backgrounds. By default, settings search in
        /usr/share/backgrounds and without it, it displays an error
    - debian/patches/
      + Use Ubuntu branding
    - debian/patches/60_sequential_glslideshow.patch:
      + Allow going through images sequentially rather than just at random in
        the GLSlideshow hack.
  * debian/changelog: really clean up changelog, some entries were still out of

xscreensaver (5.15-2) unstable; urgency=low

  * Build-dep on libjpeg-dev instead of libjpeg62-dev (Closes: #647110)

xscreensaver (5.15-1) unstable; urgency=low

  [ Tormod Volden ]
  * New upstream version 5.15
    - New hacks: hilbert, companioncube and tronbit
    - Turned on LC_CTYPE on Linux (LP: #671923)
  * debian/rules: Add build-arch and build-indep targets

  [ Jose Luis Rivas ]
  * postrm: Kill xscreensaver after removal (Closes: #558024)
 -- Mathieu Trudel-Lapierre <email address hidden> Wed, 21 Dec 2011 11:27:37 -0500

Changed in xscreensaver (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers