Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

Physical State of Media Keys not detected by GetKeyState


  • Please log in to reply
33 replies to this topic
Tertius
  • Members
  • 62 posts
  • Last active: Aug 07 2008 11:43 AM
  • Joined: 05 Jun 2008
Yes, SKAN that should work fine most of the time, however I have other scripts that call Send, {Media_Next down}, and this will result in a getkeystate (logical) to return true, which is not desirable for the script I was hoping to use with the keyboard. Yes, there are work arounds but none of them as simple as just a good old GetKeyState "P".
- Tertius

Tertius
  • Members
  • 62 posts
  • Last active: Aug 07 2008 11:43 AM
  • Joined: 05 Jun 2008
As for the numpadhome and home being indistinguishable, perhaps AutoHotkey could use combination of scan code and virtual key code (where relevant) for getkeystate "P" - as far as I can see regular getkeystate only can know definitively the virtual key code. This way, for example, numpadhome and home can be accurately differentiated by getkeystate "P".
- Tertius

SKAN
  • Administrators
  • 9115 posts
  • Last active:
  • Joined: 26 Dec 2005

should work fine most of the time, however I have other scripts that call Send, {Media_Next down}, and this will result in a getkeystate (logical) to return true,


Are you sure about that ? In the following code, Send does not trigger KeyDown :

Loop {
If GetKeyState("Browser_Home" ) 
   MsgBox, Browser_Home
Sleep 1
}

F2::Send {Browser_Home}

:)
kWo4Lk1.png

Tertius
  • Members
  • 62 posts
  • Last active: Aug 07 2008 11:43 AM
  • Joined: 05 Jun 2008
The send command, without specifying down or up, issues both down and up events. Your loop does not detect it because it was interrupted and its "thread" restored after the key up event. Fortunately enough, when such Send commands as Media_Next down and Media Prev down are issued by certain scripts of mine, they are only for short periods, so the likelihood of inaccuracy is quite small.

I am just really baffled by the fact that all the other keys (besides certain numpad keys) on this keyboard are accurately detected as down by getkeystate "P" but not these media keys.
- Tertius

engunneer
  • Moderators
  • 9162 posts
  • Last active: Sep 12 2014 10:36 PM
  • Joined: 30 Aug 2005

However, the following test should confirm that typematic delay is not the issue


That is exactly my point. I think the keyboard could be doing this to prevent the typematic delay taking effect on this key (for example on PlayPause so it does not repeatedly switch between play and pause in case you hold down the key.)

Tertius
  • Members
  • 62 posts
  • Last active: Aug 07 2008 11:43 AM
  • Joined: 05 Jun 2008
SKAN, here's an example
OnExit, ExitSub
Send, {Media_Next}
Return

ExitSub:
Tooltip
ExitApp

Media_Next::
Tooltip, Media_Next pressed down
Sleep 3000
Tooltip
Return
You will find that a down event (hotkey Media_Next is called) is indeed the result of a Send, Media_Next.


That is exactly my point. I think the keyboard could be doing this to prevent the typematic delay taking effect on this key (for example on PlayPause so it does not repeatedly switch between play and pause in case you hold down the key.)

No, I don't believe this is the case because I have hotkeys that work just fine, utilizing autorepeat (not requiring GetKeyState "P"), for the Media_Next and Media_Prev on the USB keyboard. So, typematic delay is indeed in effect for these two. So, for example, if I hold down Media_Next in Windows Media Player it doesn't skip a track, but fast forwards through the track utilizing autorepeat. This of course seems quite strange given that in order for autorepeat to work the key must be held down that delay time, yet getkeystate "P" doesn't see it as down - but it MUST be down in order for Windows Media Player to begin fast forwarding otherwise it would skip tracks based off it receiving Media_Next up events before autorepeat kicked in.
[Edit] I thought I remembered this working in WMP but apparently it was some other player. Anyway, this code may illustrate this better
OnExit, ExitSub
Return

ExitSub:
Tooltip, , , , 2
Tooltip
ExitApp

~Media_Next UP::
Tooltip,  Media_Next was released, 40, 80, 2
SetTimer, Tooltip2, -3000
Return

~Media_Next::
Tooltip, Media_Next is Down, 40, 40
SetTimer, Tooltip1, -3000
Return

Tooltip2:
Tooltip, , , , 2
Return

Tooltip1:
Tooltip
Return
If one holds down Media_Next then one will find that the tooltip will stay there well past 3 seconds (of course this goes until you release the key), but never is the toolip for Media_Next up generated until you release the physical key. This is so even on my USB keyboard. So, why doesn't GetKeyState "P" see the media_next as down?
- Tertius

engunneer
  • Moderators
  • 9162 posts
  • Last active: Sep 12 2014 10:36 PM
  • Joined: 30 Aug 2005
I agree that this is wonky, and likely a bug, but for clarification, the behaviour you describe is another indicator that it is not typematic repeat causing it to fastforward, but instead the long time between key down and key up. if typematic repeat (my bad for calling it typematic delay before) was in effect for this key, it would skip multiple tracks, unless it is doing some A_TimeSincePriorHotkey thing.

I don't mean for this to be an argument, but want to be technically correct on this one
(See <!-- m -->http://xkcd.com/386/<!-- m -->)

Tertius
  • Members
  • 62 posts
  • Last active: Aug 07 2008 11:43 AM
  • Joined: 05 Jun 2008

I don't mean for this to be an argument, but want to be technically correct on this one
(See <!-- m -->http://xkcd.com/386/<!-- m -->)

:lol: That image is quite funny. For clarification on my part, I don't intend for such either, and if my words have come across as such please forgive me as I have no such desire for this.

Note: I updated my post above with an example illustrating that there are no keyup events so long as the key is down, at least by the hook or even to hotkeys. This is irrespective to the keyboard being USB or PS/2.

I agree that this is wonky, and likely a bug, but for clarification, the behaviour you describe is another indicator that it is not typematic repeat causing it to fastforward, but instead the long time between key down and key up. if typematic repeat (my bad for calling it typematic delay before) was in effect for this key, it would skip multiple tracks, unless it is doing some A_TimeSincePriorHotkey thing.

Yes, there is not a key up event after these key down events until the key is physically released. Obviously there is some other logic to this particular media player. We both understand that in order for typematic repeat to work the key must be physically down. So, since the Media_Next key does work with auto-repeat and therefore the key must be be detected as down in order for this to work, why then does Getkeystate "P" fail to see this?

Again, GetKeystate "P" works fine on my PS/2 keyboard, so this has something to do with USB. Just an FYI I am not using any special software for the keyboard, just the OS's built in support.
- Tertius

engunneer
  • Moderators
  • 9162 posts
  • Last active: Sep 12 2014 10:36 PM
  • Joined: 30 Aug 2005
you might see if making your own special software can detect it (See Micha's excellent DLL here: <!-- m -->http://www.autohotke...opic.php?t=6367<!-- m --> )

also, his documentation here: <!-- m -->https://ahknet.autoh... ... otkey.html<!-- m --> (He links to it too)

Perhaps you can really see exactly what is sent when the key is pressed and released.

I am glad we are on the same page, as far as discussion goes.

Tertius
  • Members
  • 62 posts
  • Last active: Aug 07 2008 11:43 AM
  • Joined: 05 Jun 2008
I am glad too. You and SKAN have been quite helpful in attempting to nail this one down.

I will try Micha's support for HID devices and see what it says.

Just to be clear, I have no problem executing the hotkeys, it is only the GetKeyState "P", and that only for Media Keys - all other keys are fine - , so it's not as if I can not detect the scan/virtual key codes of these presses - I can - but the problem is that only for USB devices the GetKeyState "P" for media keys fails. Autorepeat, the built in OS feature, works fine for the USB keyboard's Media_Next and Media_Prev keys, as well as Volume_Down and Volume_Up; however, I have since found, interestingly enough, that the USB keyboard's Volume_Mute, Media_Stop and Media_Play_Pause keys do not trigger autorepeat (but, all except Volume_Mute trigger autorepeat on my PS/2 keyboard). You probably already understand this after two pages of discussion, but just wanted to make sure.

Again, thanks for the help.

I am thinking of starting a thread in the wish list in order that scan codes can be used as part of the GetKeyState "P" call. This way, for example, numpadhome and home can be differentiated with such calls. Otherwise GetKeyState "P" calls to determine if the home key is down, when actually only numpadhome is down, will result in the erronous determination that the home key is down.
- Tertius

engunneer
  • Moderators
  • 9162 posts
  • Last active: Sep 12 2014 10:36 PM
  • Joined: 30 Aug 2005
I was thinking (without getting into too much detail) that Micha's HID script may let you replace the GetKeyState function somehow, and possible differentiate between the two home keys. I don't even know if it's possible, but it seemed like it should be able to work.

Tertius
  • Members
  • 62 posts
  • Last active: Aug 07 2008 11:43 AM
  • Joined: 05 Jun 2008
Thanks again for the link. Although fine when I run XP machines, I don't believe this is a good idea because OS's before XP are not supported, so it's use is limited. Also, I am not sure if I was clear on this issue, but the numpadhome and home key issue is not restricted to USB keyboards, it doesn't work on PS/2 either (try my previous numpadhome code for reference). I was thinking of posting this as a Wish List item because I have already submitted two bug reports, and I don't want to seem like I'm being ungrateful. However, I think, in general, there would be users who would appreciate knowing, via the help file, that even with the keyboard hook installed and using getkeystate "p" AutoHotkey exe's/scripts can not differentiate keys with the same virtual key code, but different scan codes. I'll give it a few days though, since Chris may not like me if I bombard the bug report board three times in a week. :shock:

I still intend to look more into this USB issue with the media keys when I have the time/focus to deal with it.

Anyway, thanks again SKAN and engunneer. You two have made my first experiences with the bug board pleasant ones.
- Tertius

VxE
  • Moderators
  • 3622 posts
  • Last active: Dec 24 2015 02:21 AM
  • Joined: 07 Oct 2006
Um.... I'm not sure whether it's been determined yet, but at least on my media_next key, the up event is generated instantly after the down event, regardless of how long I hold the key.

B0 119 h d 1.27 P
B0 119 h u 0.00 P
B0 119 h d 0.97 P
B0 119 h u 0.00 P

code:
$~*Media_Next::return
$~*Media_Next Up::return

But it may be worthwhile to see if micha's HID support can catch a unique 'up' message when the key is physically released.

Tertius
  • Members
  • 62 posts
  • Last active: Aug 07 2008 11:43 AM
  • Joined: 05 Jun 2008
Hi all,


Here's a little update:

I have learned through both Micha's HIDSupport script, as well as a custom hook, that USB keyboards utilizing the OS's built in USB support (kbdhid.sys driver and HID Input Service) result in hook chains seeing a scan code of 0 for all keys that generate wm_appcommand messages, but the correct virtual key code. This may also apply to support provided custom for the keyboard (Logitech's or MS's Intellitype etc), but I am unsure because I am not up to installing such software at the time. However, I would like to hear from SKAN, as well as others who find that GetKeyState "P" fails for their USB keyboard's media keys, as to what software supports their USB keyboard (OS's built-in support or custom software like Logitech etc). One interesting revelation from this find is that apparently AutoHotkey uses some sort of default data list to draw scan codes from because the correct scan code shows up in the Keyhistory list despite my finds that 0 is sent as the scan code to the hook chains, and even before that (Micha's script works before the hook chains, which is why it is able to see my USB fn key presses but the hooks can not, and it also sees a scan code of 0).

Also, the injected flag is set for the hook chain of all media keys pressed/released from a usb keyboard using OS's built in support (you can see this by looking in the keyhistory list and observing that the "a"(artificial) flag is set). I have not gone through the AHK source, but it seems that if the injected flag is set for such keys then GetKeyState "P" does not recognize the key as physically anything.

I have briefly looked for an explanation as to what is happening with these keys from the time it meets the driver to the time it meets the hooks which causes the scan code to be set to 0 and the injected flag to be set, but I have not had success. If anyone has some information as to what is going on, sharing it here will prove to be quite beneficial for a good many.
- Tertius

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

... apparently AutoHotkey uses some sort of default data list to draw scan codes from because the correct scan code shows up in the Keyhistory list despite my finds that 0 is sent as the scan code to the hook chains ...

With some exceptions, AutoHotkey uses MapVirtualKey to determine the scan code if one is not received. This is handled in keyboard_mouse.cpp, vk_to_sc().

Also, the injected flag is set for the hook chain of all media keys pressed/released from a usb keyboard using OS's built in support (you can see this by looking in the keyhistory list and observing that the "a"(artificial) flag is set).

My Logitech wireless keyboard does this when the receiver is connected via USB. Fortunately for me, I use PS/2 (via an adapter.)

I have not gone through the AHK source, but it seems that if the injected flag is set for such keys then GetKeyState "P" does not recognize the key as physically anything.

If the injected flag is set, the event is "artificial." It is the way AutoHotkey can distinguish between physical key-presses and events sent by keybd_event (SendEvent), SendInput and similar.