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

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

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.

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!

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 http://www.jwz.org/xscreensaver/bugs.html

Thanks for taking the time to make Ubuntu better!

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...

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

Forgot to mention: Happens with Xuuntu Natty Alpha 2

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.

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

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

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.

Thanks...

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

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

Did someone try xscreensaver 5.14 for this issue?

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 http://www.jwz.org/ http://www.dnalounge.com/

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.

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
   */
#undef ENABLE_NLS

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

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

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.

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

So something like attached is needed?

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".

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

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, "")

> 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.

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.

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

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

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

Just tried 5.15, it works fine.

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.
So PLEASE DISABLE ENTERING NON-ENLISH CHARACTERS INTO THE PASSWORD FIELD.
If your password contains an € sign, how about you stop being such a special snowflake and change it so that it doesn't.
Thanks.

How about displaying the keyboard layout in the password window?

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/source_xscreensaver.py:
      + 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/53_XScreenSaver.ad.in.patch:
      + 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
    place.

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