[stoli]

I am not sure when/why it stopped, but SkipNext (comma in 99% of the cases) has stopped working for me on Nightly builds and even when reverting to Dharma. SkipPrevious works fine as well as all other commands that I have tried.

In checking the debug, it appears to be reading it is a numeric keypad entry:

Code:

19:17:19 T:5820 M:1325785088   DEBUG: SDLKeyboard: scancode: 34, sym: 002f, unicode: 002e, modifier: 0
19:17:19 T:5820 M:1325785088   DEBUG: CApplication::OnKey: numpadperiod (f06e) pressed, action is

When I actually use the keypad it's a different scan code:

Code:

19:22:44 T:5820 M:1268752384   DEBUG: SDLKeyboard: scancode: 53, sym: 010a, unicode: 002e, modifier: 0
19:22:44 T:5820 M:1268752384   DEBUG: CApplication::OnKey: numpadperiod (f06e) pressed, action is

So - what did I do?

[jhsrennie]

So - what did I do?

Nothing! This will be due to my messing around with the keyboard handling. See 120 (PR) for the gory details.

Period on the main keyboard and period on the numeric keypad are now treated as different; before my change they were handled in the same way. Using the 13th May build on my UK keyboard the main keyboard generates a <period> keypress and the numeric keypad generates a <numpadperiod>. Are you using a different keyboard layout, and if so which one? I'll check it to make sure I haven't introduced a bug.

PS I've just noticed you say it's stopped working on Dharma. That's odd as obviously I haven't changed Dharma. Also I note that scan code 0x34 should map to sym 0x2e but it maps to 0x2f in your log. sym 0x2f is slash not period.

JR

[stoli]

I tried again on my office PC and this was the result:

Code:

12:38:24 T:2536 M:1325088768   DEBUG: SDLKeyboard: scancode: 34, sym: 002e, unicode: 002e, modifier: 0
12:38:24 T:2536 M:1325088768   DEBUG: CApplication::OnKey: numpadperiod (f06e) pressed, action is

The previous post was with the Win build from May 15th. The one above was from May 9th. Both instances were coming from Logitech wireless keyboards on Win7.

Edit: Hmmm.... just tried the May 15 build again and it seemed to work correctly. Will have to check when I get home.

Office w/MAy 15th Build - works correct

Code:

12:46:06 T:1464 M:1473581056   DEBUG: SDLKeyboard: scancode: 34, sym: 002e, unicode: 002e, modifier: 0
12:46:06 T:1464 M:1473581056   DEBUG: CApplication::OnKey: period (f0be) pressed, action is StepForward

[jhsrennie]

Ok it looks as if the current builds are OK. Please let me know if this or any similar problem recurs.

JR

[stoli]

Ok it looks as if the current builds are OK. Please let me know if this or any similar problem recurs.

JR

Finally got a change to test it at home and still not working for some reason:

Code:

19:26:11 T:1156 M:1516113920  NOTICE: -----------------------------------------------------------------------
19:26:11 T:1156 M:1516105728  NOTICE: Starting XBMC, Platform: Windows 7, 32-bit build 7600. Built on May 17 2011 (Git:20110516-a0d6b41, compiler 1600)

Regular period:

19:26:49 T:1156 M:1413767168   DEBUG: SDLKeyboard: scancode: 34, sym: 002f, unicode: 002e, modifier: 0
19:26:49 T:1156 M:1413767168   DEBUG: CApplication::OnKey: numpadperiod (f06e) pressed, action is

Number pad Period:

19:26:51 T:1156 M:1410613248   DEBUG: SDLKeyboard: scancode: 53, sym: 010a, unicode: 002e, modifier: 0
19:26:51 T:1156 M:1410613248   DEBUG: CApplication::OnKey: numpadperiod (f06e) pressed, action is

Entire log here: http://pastebin.com/bZzUFXK1

As noted, it worked on the 15th build on my office keyboard... Both are logitech wireless.

[jhsrennie]

There's something weird about your home PC. If you look at the log entry:

Code:

DEBUG: SDLKeyboard: scancode: 34, sym: 002f, unicode: 002e, modifier: 0

The sym identifies the key pressed, and 0x002f is the / key. By contrast, on your office PC the line looks like:

Code:

DEBUG: SDLKeyboard: scancode: 34, sym: 002e, unicode: 002e, modifier: 0

so the sym is 0x002e as it should be. There has to be some difference between the setups on the two PCs.

However, I agree that regardless of the PC setup XBMC should be treating the keypress as <period> not <numpadperiod> and I'll make this change today. This is what's going on:

Both the period and numpad period keys generate a unicode of 0x002e, so XBMC can't tell them apart, but they generate different sym values. Period (normally) generates a sym of 0x002e and numpad period generates 0x010a. When it looks at a key press XBMC first attempts to match both the sym and unicode, and this means it can tell the difference between the period and numpad period keys.

However, in your case the period key is generating an unexpected value of the sym, 0x002f, and XBMC can't find any keypress with a sym of 0x002f and unicode of 0x002e. In that case it falls back to just looking at the unicode, but as mentioned above, this means it can't tell the numpad from the main keyboard, and it's assuming it's a numpad key. I suggest changing XBMC so that if it can't distinguish between the numpad and the main keyboard it will assume the keypress was on the main keyboard.