Ok I've fixed the bugs that Badablek mentioned in the last release. The issue with the AltGr key was actually a bug in my keymap compiler that didn't really show up til the changes in how modifier keys are delt with.

Keymap Compiler
- Fixes keymap generation bug

ScummVM r36278
- Fixes issue with e, j and x keys
- Includes fixed version of keymaps

   

Thanks briijohn. This is greatly appreciated. I felt a bit awkward asking and after I felt I should of tried to understand it a bit more myself instead.
I've been busy for a few days but now I have a long weekend off. I've been going through the 2 Indy games recently, to completion, and the key/b number pad has been handy for all the fights and boxing I keep starting. I wonder how Lucas will handle the boxing when the Wii version of Staff of Kings is released with it's Atlantis bonus.
Once again a big thanks.

   

Thanks for the quick bugfix (again)

Now eveyrything works as expected, nice job.


I have updated my french keymap, made some mistakes on the previous one : ù <> ü, ¨ <> " and added Euro symbol (even if scummvm does not support it and does not display it)

http://www.gx-mod.com/team/perso/Badablek/French_keymap_updated.zip


little question : adding capslock support (press once > enable, press again, disable) is in your TODO list ? and Numlock ? I should update my keymap in consequence.

   

Great job brijohn!

However, the 0-9 number keys of the virtual keyboard still don't work for me.
I am not using a keymap at all (not copied, not enabled). Could that be it?

I can't test further anymore unfortunately. Will try tomorrow.

[edit]Seems to be a virtualkeyboard bug, not your patch bug
I am going to file a bug and see what happens.

[edit2]Simple fix. I updated the xml in the vkeybd.zip.
Uploaded the new version and submitted it, hope it will be in trunk soon.
See link in sig for it.

   

quote:

---

Originally posted by Badablek

little question : adding capslock support (press once > enable, press again, disable) is in your TODO list ? and Numlock ? I should update my keymap in consequence.

---

   

i finally found the time to look at libwiikeyboard and your changes, brijohn.

With some changes to the code i commited libwiikeyboard plus your patches to my libogc git branch, which you can find here since today.

What i did change:
- got rid of keyboard_priv.h and keymapper.c, the code is in keyboard.c now. the "_manager" var shouldn't be public and its struct has been defined twice (and differently!)
- i removed the ability to load keymaps from a filesystem, since these maps are tiny in compiled size. there's currently only the english and german map in there (got bored ). the map gets chosen by the language the wii is set to, but an application can just load another one.

i also commited your ScummVM patch to trunk, again with some changes. Its mostly cleanup work, but i'd like to hear your opinion on what i changed, especially why you used this code:

code:

---

      } else if (kbdEvent.type == KEYBOARD_RELEASED) {
         event.type = Common::EVENT_KEYUP;
         if (prevScan == kbdEvent.keysym.scancode)
            kbdEvent.keysym.sym = KEYBOARD_GetKeySym(prevScan, prevMod);
      } else {

---

   

I took a closer look at the code yesterday and noticed alot of problems:

- memory leaks
- missing error checking
- inconsistency
- not so useful features like multiple keyboards support and multiple event callbacks
- scan for new keyboards with every event poll

I messed around and changed alot of code, but i believe its better now. I would appreciate it if you take a look and give me some feedback, brijohn.

   

dhewg,

Thanks for getting this including in the in the main scummvm repositories.

A few of my comments about your integration of libwiikeyboard.

First you really should not remove loading of the keymaps from the SD card. I know the keymaps themselves do not take up much space if compiled in but size is not really the reason for that design decision. I chose to do loading of keymaps as well as choosing whcih keymap to use from the SD card because it offers the most flexibility. If the keymaps are compiled int either adding or updating a keymap becomes a huge pain since it requires recompiling not just libwiikeyboard but any program that is compiled against it. This in my opinion is quite undesirable. Furthormore while trying to select a keymap based on the language settings of the wii may seem like a good idea it too offers problems. for instance i have and use a japanese based keyboard however my WII is a US one how then am i supposed to seelct the right keymap for my keyboard? Not to mention things like that fact i can think of at least 4 different US layouts alone how can i choose a different one if its simply based on the language setting of the wii? When I originally wrote the keymapper i berifly considered using built in keymaps and possibly choosing one based on the language setting as well but quickly discarded those ideas for the above reasons.

Also in regards to the code snippet you posted that is to fix and issue regarding a difference in how libwiikeyboard is designed to behave vs what is expected by scummvm. When libwiikeyboard gets a press or release event it sends the scancode, keysym and modifiers that were pressed both the modifiers and symbol CAN be different from the press to release event of a certain key, whereas the scancode whcih represents a physical key on the keyboard will always be the same. Scummvm however will use the keysym to try and determine when to stop repeating a key that is continually held down. If that differs on keyrelease it will continue repeating the last key pressed. You can try this by holding down shift pressing a key till it starts repeating, then release shift followed by releasing the other key and it should continue to repeat till you press some other key. The code I added was designed to make scummvm agree on the keysym. This also means that the function for translating keysyms form scancodes should be publicly available to applications to use if they want. Also in scummvm you probably don't really need to catch the connected/disconnected events since you don't really need to do anything with them anyways.


Your other changes i haven't gone over as much but that look fine. I've been flip-flopping back and forth on getting rid of multiple keyboards, but i suppose it does simplify some things and i've had some trouble thinking when you would actually need to be able to use more then one at a single time anyways so i suppose I'm fine with that.

Also my current version of the library is available using git from here. It includes an update that handles ShiftLock and NumLock when translating keysyms.

   

Ok updated version of the keyboard build. This one includes support for CapsLock and Numlock in libwiikeyboard also added key repeat to libwiikeyboard as well as many of the patches dhweg made to clean up some of the code and fix memory leaks.

ScummVM rev38377
- supports CapsLock(ShiftLock) and NumLock
- disable scummvm keyrepeat in favor of using libwiikeyboard
- fixes issue with 0-9 on virtual keypad
- fix return key on virtual keypad to work

   

Just tryed the last version, but it takes more than usual to enter, and using the keyboard i get the symbols inside the [], did i install it wrong??? i plugged a keyboard in the console and it seems to be working at least pressing space pauses the game. When i quit it goes all black and doesnt return to hb menu.

   

quote:

---

Originally posted by Maxrunner
it takes more than usual to enter

---

quote:

---

Originally posted by Maxrunner
using the keyboard i get the symbols inside the []

---

quote:

---

Originally posted by Maxrunner
i plugged a keyboard in the console and it seems to be working at least pressing space pauses the game. When i quit it goes all black and doesnt return to hb menu.

---

   

quote:

---

Originally posted by brijohn

quote:

---

Originally posted by Maxrunner
it takes more than usual to enter

---

Not sure what you mean by this.

quote:

---

Originally posted by Maxrunner
using the keyboard i get the symbols inside the []

---

do you mean when using the virtual keyboard? if so that is normal.

quote:

---

Originally posted by Maxrunner
i plugged a keyboard in the console and it seems to be working at least pressing space pauses the game. When i quit it goes all black and doesnt return to hb menu.

---

I have no issues exiting back to the homebrew channel myself. so I'm not sure what the issue is here. does it do this for all games or just certain ones?

---

   

If you are using a real USB keyboard you do not need to use the virtual one. The virtual keyboard is only necessary if you do not have a physical keyboard.

If you are going to use the virtual keyboard just use the pointer to select the characters you want and then close the virtual keyboard. Also don' unzip vkeybd.zip either.

   

quote:

---

Originally posted by brijohn
If you are using a real USB keyboard you do not need to use the virtual one. The virtual keyboard is only necessary if you do not have a physical keyboard.

If you are going to use the virtual keyboard just use the pointer to select the characters you want and then close the virtual keyboard. Also don' unzip vkeybd.zip either.

---

   

If you're asking how do I pull up the virtual key/b it's down on the wiimote d-pad.

Briijohn I have noticed that when quitting sometimes ScummVM 'hangs'. Using Esc on the USB key/b always gets me back to the Homebrew Channel though.
Thing is I can't remember what menu I've been using to quit when I've had this hanging. I seem to remember you can quit from the in-game GMM menu as well as the main launcher menu.
Or maybe like you say it's game related.