Menu ▾ ▴

#556 Typing with US-International got broken

Next_release
open
Wouter Vermaelen
regression (5) keyboard (1)
5
2015-01-03
2014-11-23
Manuel Bilderbeek
No

If you're (at least under Windows, other OSes not tested) use a US International keyboard setting in openMSX 0.10.1 and type: PRINT"HI"<enter>, you also simply get that typed in the MSX.
But after commit 7bd9111ba394ac0942cec6ca6925edcc8a1bcdc8 (RTScheduler), this doesn't work properly anymore, you get:
PRINT""OI"" (and cursor is on the same line still)</enter>

In other words, as of that commit, the compose suppression (type "a to get ä) is not working anymore.

Originally reported on IRC:

* Guest438976 (4daae7ae@gateway/web/freenode/ip.77.170.231.174) has joined #openmsx
<Guest438976> Hi, i have a problem with keyboard in openmsx 0.11.0... if i type a " (Shift + ' ) ... the next caracter i type will allso be a " ... very strange
<Guest438976> This problem does not happen in openmsx 0.10.1 ... i think it is a keyboard setting thing
<Quibus> which machine are you emulating?
<grauw> sounds like an IME issue
<Guest438976> nms 8250 Philips
<Quibus> on which OS?
<Guest438976> it happens in windows 7 .. allso in windows 8 ... in verion 0.10.1 is works normal on same machine ?
<Quibus> Are you sure? Sounds like you set your input to US International in Windows
<Quibus> Whcih keyboard setting in Windows are you using?
<Guest438976> Nederlands (nederlands) - Verenigde staten (internationaal )
<Quibus> Yes, so it's US International
<Guest438976> yes
<grauw> try changing it and see if the problem persists
<Quibus> The thing is with US International that it's doing weird stuff when you type " and e to get an ë
<Guest438976> strange thing that it works OK in version 0.10.1 and not in 0.11.0
<Quibus> I really doubt that, this problem is known for a very long time
<grauw> you may have unknowingly switched from Dutch to US International (alt-shift does that I believe) and attributed the difference to the openMSX upgrade you may have done at the same time
<grauw> have you tried installing 10.1 again and does the problem disappear?
<Guest438976> installed 0.10.1  again .. problem is gone :S
<Quibus> keyboard settings in Windows are the same?
<Guest438976> yes did not change it

And indeed, it's easily reproducible and I could find the revision that broke it with bisecting. (On Windows XP.)

Discussion

  • Manuel Bilderbeek

    Manuel Bilderbeek - 2014-11-23
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -6,6 +6,7 @@

 Originally reported on IRC:

+~~~~

 * Guest438976 (4daae7ae@gateway/web/freenode/ip.77.170.231.174) has joined #openmsx
 <Guest438976> Hi, i have a problem with keyboard in openmsx 0.11.0... if i type a " (Shift + ' ) ... the next caracter i type will allso be a " ... very strange
 <Guest438976> This problem does not happen in openmsx 0.10.1 ... i think it is a keyboard setting thing
@@ -28,5 +29,6 @@
 <Guest438976> installed 0.10.1  again .. problem is gone :S
 <Quibus> keyboard settings in Windows are the same?
 <Guest438976> yes did not change it
+~~~~

 And indeed, it's easily reproducible and I could find the revision that broke it with bisecting. (On Windows XP.)
     

  • Manuel Bilderbeek

    Manuel Bilderbeek - 2014-12-10

    From that patch, this is the exact change that breaks it, after incrementally applying it:

    diff --git a/src/events/EventDistributor.cc b/src/events/EventDistributor.cc              
index 6252ff8..034bc0d 100644                                                             
--- a/src/events/EventDistributor.cc
+++ b/src/events/EventDistributor.cc
@@ -81,6 +81,7 @@ void EventDistributor::deliverEvents()
 {
        assert(Thread::isMainThread());


+       reactor.getInputEventGenerator().poll();
        reactor.getInterpreter().poll();
        reactor.getRTScheduler().execute();

diff --git a/src/events/InputEventGenerator.cc b/src/events/InputEventGenerator.cc
index b30af9d..ead82a3 100644
--- a/src/events/InputEventGenerator.cc
+++ b/src/events/InputEventGenerator.cc
@@ -399,7 +399,7 @@ int InputEventGenerator::signalEvent(const std::shared_ptr<const Event>& event)
                                UNREACHABLE;
                }
        } else if (event->getType() == OPENMSX_POLL_EVENT) {

-               poll();
+//             poll();
        }
        return 0;
 }
diff --git a/src/events/InputEventGenerator.hh b/src/events/InputEventGenerator.hh
index 8cfb4b0..176db98 100644
--- a/src/events/InputEventGenerator.hh
+++ b/src/events/InputEventGenerator.hh
@@ -51,10 +51,10 @@ public:
        static int joystickNumButtons(SDL_Joystick* joystick);
        static bool joystickGetButton(SDL_Joystick* joystick, int button);


+       void poll();
 private:
        typedef std::shared_ptr<const Event> EventPtr;


-       void poll();
        void handle(const SDL_Event& event);
        void setGrabInput(bool grab);

    We have no clue why this would break this particular behaviour...

     

  • Manuel Bilderbeek

    Manuel Bilderbeek - 2014-12-10

    I've been testing to see what happens with the simplest test: typing "a. This gives "a in openMSX before it broke and "ä after it broke (of course with the US-International layout only, it works fine (as "a) with US-English).

    This is the logging of kbd_trace_keypresses and the SDL_KEYUP and SDL_KEYDOWN conversions in InputEventGenerator::handle (mixed), for US-English, AFTER it broke:

    SDL event converted to: keyb LSHIFT
Key pressed, unicode: 0x0000, keyCode: 0x00130, keyName: LSHIFT
SDL event converted to: keyb QUOTE+SHIFT unicode34
Key pressed, unicode: 0x0022, keyCode: 0x20027, keyName: QUOTE+SHIFT
SDL event converted to: keyb QUOTE+SHIFT,RELEASE
Key released, unicode: 0x0000, keyCode: 0x420027, keyName: QUOTE+SHIFT,RELEASE
SDL event converted to: keyb LSHIFT,RELEASE
Key released, unicode: 0x0000, keyCode: 0x400130, keyName: LSHIFT,RELEASE
SDL event converted to: keyb A unicode97
Key pressed, unicode: 0x0061, keyCode: 0x00061, keyName: A
SDL event converted to: keyb A,RELEASE
Key released, unicode: 0x0000, keyCode: 0x400061, keyName: A,RELEASE

    and this for the US-International layout:

    SDL event converted to: keyb LSHIFT
Key pressed, unicode: 0x0000, keyCode: 0x00130, keyName: LSHIFT
SDL event converted to: keyb QUOTE+SHIFT
Key pressed, unicode: 0x0000, keyCode: 0x20027, keyName: QUOTE+SHIFT
SDL event converted to: keyb QUOTE+SHIFT,RELEASE
Key released, unicode: 0x0000, keyCode: 0x420027, keyName: QUOTE+SHIFT,RELEASE
SDL event converted to: keyb LSHIFT,RELEASE
Key released, unicode: 0x0000, keyCode: 0x400130, keyName: LSHIFT,RELEASE
SDL event converted to: keyb A unicode228
Key pressed, unicode: 0x00e4, keyCode: 0x00061, keyName: A
SDL event converted to: keyb A,RELEASE
Key released, unicode: 0x0000, keyCode: 0x400061, keyName: A,RELEASE

    Notice the difference in unicode output, with the same unicode input!

    This is the same test with the version where I reverted that patch from last post:

    US-English:

    SDL event converted to: keyb LSHIFT
Key pressed, unicode: 0x0000, keyCode: 0x00130, keyName: LSHIFT
SDL event converted to: keyb QUOTE+SHIFT unicode34
Key pressed, unicode: 0x0022, keyCode: 0x20027, keyName: QUOTE+SHIFT
SDL event converted to: keyb QUOTE+SHIFT,RELEASE
Key released, unicode: 0x0000, keyCode: 0x420027, keyName: QUOTE+SHIFT,RELEASE
SDL event converted to: keyb LSHIFT,RELEASE
Key released, unicode: 0x0000, keyCode: 0x400130, keyName: LSHIFT,RELEASE
SDL event converted to: keyb A unicode97
Key pressed, unicode: 0x0061, keyCode: 0x00061, keyName: A
SDL event converted to: keyb A,RELEASE
Key released, unicode: 0x0000, keyCode: 0x400061, keyName: A,RELEASE

    US-International:

    SDL event converted to: keyb LSHIFT
Key pressed, unicode: 0x0000, keyCode: 0x00130, keyName: LSHIFT
SDL event converted to: keyb QUOTE+SHIFT unicode34
Key pressed, unicode: 0x0022, keyCode: 0x20027, keyName: QUOTE+SHIFT
SDL event converted to: keyb QUOTE+SHIFT,RELEASE
Key released, unicode: 0x0000, keyCode: 0x420027, keyName: QUOTE+SHIFT,RELEASE
SDL event converted to: keyb LSHIFT,RELEASE
Key released, unicode: 0x0000, keyCode: 0x400130, keyName: LSHIFT,RELEASE
SDL event converted to: keyb A unicode97
Key pressed, unicode: 0x0061, keyCode: 0x00061, keyName: A
SDL event converted to: keyb A,RELEASE
Key released, unicode: 0x0000, keyCode: 0x400061, keyName: A,RELEASE

    So, without the patch, all logging looks like US-English...

     

  • SD Snatcher

    SD Snatcher - 2015-01-03

    In OS-X, openMSX-0.11.0 support for US-International keeps as broken as it was (no pun/offense intended).

    The same dead key problem reported on bug #192 way back into 2005 (on Linux back then) still happens.

    The worst part is that when I type the [print "hi"] example, some keys get stuck in the emulator side and keep being repeated until I press them again (sometime multiple times).

    The result here for typing the test in lowercase was:

    print""Hih"hhhhhhhhhhhhhhhhhhhhhhhhhhh"hhhhhhhhhhhhhhhhhhhhhhhhh

    Please note that the h's that come after the i letter are produced by the h key being stuck. The uppercase H was also produced by the bug getting confused by the SHIFT state.

     

    Last edit: SD Snatcher 2015-01-03