From 0b17a67a30a48ffed7b4fe0c34854baad45492fa Mon Sep 17 00:00:00 2001
From: Martin Kiewitz
Date: Mon, 1 Feb 2016 15:04:03 +0100
Subject: SCI: Revert revert the keyboard handling changes

It seems the issues on AmigaOS aren't actually caused by the new
code. Reverting the revert.
---
 engines/sci/event.cpp | 13 ++-----------
 1 file changed, 2 insertions(+), 11 deletions(-)

(limited to 'engines')

diff --git a/engines/sci/event.cpp b/engines/sci/event.cpp
index e8744b8f60..90ddaaf967 100644
--- a/engines/sci/event.cpp
+++ b/engines/sci/event.cpp
@@ -214,8 +214,6 @@ SciEvent EventManager::getScummVMEvent() {
 		//((ev.kbd.flags & Common::KBD_CAPS) ? SCI_KEYMOD_CAPSLOCK : 0) |
 		//((ev.kbd.flags & Common::KBD_SCRL) ? SCI_KEYMOD_SCRLOCK : 0) |
 
-	// FIXME: this hack should also not be here, see below
-#if 0
 	if (input.data >= Common::KEYCODE_KP0 && input.data <= Common::KEYCODE_KP9) {
 		if (!(ev.kbd.flags & Common::KBD_NUM)) {
 			// HACK: Num-Lock not enabled
@@ -224,15 +222,8 @@ SciEvent EventManager::getScummVMEvent() {
 			input.character = 0;
 		}
 	}
-#endif
-
-	// FIXME: using .ascii (.character) in here somewhat works on Windows+Linux, but it seems that
-	//        at least SDL on AmigaOS returns valid .ascii characters when Fx keys are pressed etc.
-	//        Check bug #7009. For now I reverted my changes. This needs to get fixed properly in backend / SDL itself.
-	//        On Windows .ascii field gets values, when Fx keys are pressed as well, but it's above 0xFF.
-	//        On AmigaOS it seems to return a value <= 0xFF.
-	//if ((input.character) && (input.character <= 0xFF)) {
-	if (!(input.data & 0xFF00)) {
+
+	if ((input.character) && (input.character <= 0xFF)) {
 		// Directly accept most common keys without conversion
 		if ((input.character >= 0x80) && (input.character <= 0xFF)) {
 			// If there is no extended font, we will just clear the
-- 
cgit v1.2.3