us:intl selected instead of plain us

Hello, and thank you for taking the time to submit this bug report.

What sort of keyboard are you using, and what keyboard is set as your default in System -> Preferences -> Keyboard, in the Layouts tab?

One machine is a standard US keyboard, the other is a laptop (3000 N100).

Both are set to Generic 104-key pc US English

I'm using Kubuntu not Ubuntu.

I just tried something. I enabled in the KDE the Keyboard Layout, changed nothing else and everything works fine when in KDE.
What is strange is that without clicking enable the grayed out keyboard allocation was correct, just clicking it on fixed the issue in KDE.
However, when I switch to a VT I still have to type these chararters twice to get them.

I should have mentioned that the laptop is a Lenovo.

Below is the entry in both machine's my xorg.conf.

Section "InputDevice"
        Identifier "Generic Keyboard"
        Driver "kbd"
        Option "CoreKeyboard"
        Option "XkbRules" "xorg"
        Option "XkbModel" "pc105"
        Option "XkbLayout" "us"
        Option "XkbVariant" "intl"
EndSection

Is there any change after you run "setupcon" on the VT?

No there is no change on either machine.

However, I've been thinking. I used, as I mentioned above, the alternate CD to install Feisty and I did the same exact things with both machines. I found the process for determining the keyboard type to be a bit confusing. It asks if various international characters exist on your keyboard and I answered no to all except the last one which was ('"'). Then it said that my keyboard seems to be a 'us-en' which I thought was correct so I never gave this another thought. I did think this to be a little unusual since I would expect a double quote to be on almost any keyboard. Could I have made the wrong choice here?

That sounds right to me.

What are the contents of your /etc/default/console-setup ?

I'm attaching the file.

Save a copy of it and let me know what happens if you replace the corresponding lines:

XKBMODEL="pc104"
XKBLAYOUT="us"
XKBVARIANT=""
XKBOPTIONS=""

Nope, sorry to say it's the same thing. I tried this only on my laptop and rebooted after editing the file. My /etc/X11/xorg.conf file is still at the old setting, but, as mentioned above, I found a fix for this. Still there seems to be a setup bug when one first does the install for both KDE and the VT.

Just to verify, after making that change in /etc/default/console-setup, did you run setupcon again in the VT you were using?

I'd also like to verify an assumption: if you type "u, for example, does that produce ü?

Still no change, but yes "u will produce ü.

I'm at a loss. I'm assigning it to ubiquity, as it seems probable that whatever environmental difference is affecting the keyboard, was introduced via selections at install time; hopefully someone managing those bugs will have a better idea what package to forward this to.

The problem is that you're using the 'intl' variant of the 'us' keymap, which gives you what are known as "dead keys" - i.e. some punctuation characters turn into modifiers that attach accent marks to the next character, so that for example 'e might give you e-acute. Clearly this isn't what you want.

You mentioned that the installer told you that the detected keyboard layout was "us-en". Are you sure that's entirely accurate? I don't think it can ever say exactly that. I wonder if perhaps it said "us:intl" instead?

Would it be possible for you to boot the Feisty alternate CD again, go through keyboard layout detection, and note down exactly what you did? I can then go through that in more detail. You can press the reset button after keyboard detection, and it won't touch your existing installation in any way.

OK, I've done what you ask and I think I found the problem. At a certain point in the detection of the keyboard layout it asks if specific characters are present or at least accessible on your keyboard. Most of these characters are from non-English character sets. However one key can be in the English character set (at least in the way it is represented in text mode) and that is where it asks if '"' is present. In my original install I said yes then it told me my keyboard appeared to be "us:intl" (you are correct, I didn't remember properly). This time I went back and said no for the '"' choice and the keyboard was determined to be "us". This was definitely confusing especially for a first time Alternate CD user. I assume that the '"' that is asked for is not actually what I just typed. I suppose that somehow this needs to be better explained or a different character needs to be tested to derive the correct keyboard type.

OK, how do I fix this? As I mentioned above I was able to get KDE to work correctly, but am still having this issue when I go to a VT.
Thanks.

I had forgotten two things:

In your /etc/default/console-setup, set VERBOSE_OUTPUT=yes; and make sure that you run setupcon as root.

Any change? If not, please include the output that console-setup gives (you may want to run it as "sudo setupcon >&/tmp/setupcon.out" or some such, to obtain the output so you can paste it into your response).

I had to change the command a bit, but this seems to have fixed my VT.

This is what I ran:

# setupcon --force >& /tmp/setupcon.out

It seems that without the "--force" it complains with: "We are not on the Linux console, exiting.".

The results in /tmp/setupcon.out are:

Loading 256-chars 8x16 font from file `/etc/console-setup/Lat15-VGA16.psf.gz'.
Setting kernel SFM.
Loading 256-chars 8x16 font from file `/etc/console-setup/Lat15-VGA16.psf.gz'.
Setting kernel SFM.
Loading 256-chars 8x16 font from file `/etc/console-setup/Lat15-VGA16.psf.gz'.
Setting kernel SFM.
Loading 256-chars 8x16 font from file `/etc/console-setup/Lat15-VGA16.psf.gz'.
Setting kernel SFM.
Loading 256-chars 8x16 font from file `/etc/console-setup/Lat15-VGA16.psf.gz'.
Setting kernel SFM.
Loading 256-chars 8x16 font from file `/etc/console-setup/Lat15-VGA16.psf.gz'.
Setting kernel SFM.

A caveat here is that the fix only worked until a reboot, it's back to what it was before.
So I'm still looking for a permanent fix to this issue.

Right; otherwise I would have closed this out. This would be looking like a support issue rather than a bug (except that, as you say, the (") character, which I suspect was actually a diaresis ( ̈), may be confusing―but that should probably be a separate bug report).

However, the documentation I've read so far seems to indicate that after a reboot, the console should be setup via the setupcon program. The fact that it requires --force may have something to do with it, though this may also have something to do with bug 60600 (via usplash).

There is also the fact that --force is even required.

Micah, I already identified the problem in my comment above - it's that the keyboard variant is wrongly set to "intl". There is no need to investigate setupcon further, as it's only doing what it's told.

Colin, yes, you identified the root problem, but no one had correctly informed him how to _solve_ the issue, permanently, and there were apparent issues with his setupcon. Note that the comment to which you refer is over 10 months old.

cnobile: Ah. The thing is that it wasn't actually asking about '"' - it was asking about '¨' (an umlaut/diaeresis). The intl variant of us has that symbol, but plain us doesn't. This is still open on Hardy.

Perhaps we should avoid asking about that symbol due to ambiguity.

This has been a while, I was using Feisty at the time and am now using
Gutsy. I have as of yet not update to Hardy. Yes, my main point was the
AMBIGUITY and for that reason alone at least a comment should be added to
the screen mentioning the issue.

On 4/29/08, Colin Watson <email address hidden> wrote:
>
> cnobile: Ah. The thing is that it wasn't actually asking about '"' - it
> was asking about '¨' (an umlaut/diaeresis). The intl variant of us has
> that symbol, but plain us doesn't. This is still open on Hardy.
>
> Perhaps we should avoid asking about that symbol due to ambiguity.
>
> ** Changed in: keymapper (Ubuntu)
> Sourcepackagename: console-setup => keymapper
>
>
> --
> us:intl selected instead of plain us
> https://bugs.launchpad.net/bugs/113444
> You received this bug notification because you are a direct subscriber
> of the bug.
>

This problem is back with 8.04 and 8.10 but doesn´t have a quick fix in 8.10

I'm using a Lenova Thinkpad R60, and had this problem in 8.04 before my upgrade. setupcon didn't seem to fix the problem, but I could use the system menu of Applications->Other->Keyboard Layout and switch between different manufacturers and in the process fix the problem until the next boot.

The keyboard layout functionality has changed in 8.10, switched to a tab on the System->Preferences->Keyboard menu
While I can change the configuration in the config file, these settings remain in the menu. The fix is to "add" the standard USA keyboard, select it and then redo this step every single time the machine restarts. Is it possible the problem is in some sort of auto-detection at boot, that detects the keyboard on the laptop?