search

oblitum / Interception

The Interception API aims to build a portable programming interface that allows one to intercept and control a range of input devices.
http://oblita.com/interception
1.4k stars 275 forks source link

Additional keys on keyboards #2

Open spiwn opened 12 years ago

spiwn commented 12 years ago

Events such as pressing/releasing keys like "My computer", "Calculator", "Web Home" (and etc.) that can be found on some keyboards are not registered by Interception ( or atleast I am unable to make it happen ). They are a special case so this is no surpise.

Should you decide on adding support for such keys this may be of use to you: When reading raw input from such keys, the raw data values are: dwType = RIM_TYPEKEYBOARD ( equal to 1) hDevice = Null MakeCode = 0 Flags = 2 Reserved = 0 Message = 256 (like all other keys) ExtraInformation = 0 Those are the same for all such keys on my keyboard. However they have different VKey value. The values can be matched against those in http://msdn.microsoft.com/en-us/library/dd375731%28VS.85%29.aspx like: VK_BROWSER_HOME VK_LAUNCH_MAIL VK_LAUNCH_MEDIA_SELECT VK_LAUNCH_APP1

oblitum commented 12 years ago

They are, you may check this answer I've given at stackoverflow, http://stackoverflow.com/a/8844117/1000282. With Interception you can capture about any key, it's low level enough for not being filtered by nearly anything on the OS, only three special ones are commonly filtered before Interception: Sleep, Shutdown and Wake. If you want to add custom behavior to these ones, you need to disable their behavior at control panel to do nothing and then start capturing them. I think there isn't enough documentation on using Interception yet... but try to read the main page where I talk about special keys, see the sample I mentioned that captures the Windows key, and also, try to build a sample that just captures any keys through the INTERCEPTION_FILTER_KEY_ALL filter and see which scancode and flags this special keys get. I've done samples before that intercepted all media keys of a old keyboard I had.

spiwn commented 12 years ago

Well this is wierd, because I had done exactly what you suggested. That is to use 'INTERCEPTION_FILTER_KEY_ALL' with 'interception_is_keyboard' and display the scan code of the keystroke ( and 'Intercept' it - not call interception_send). By doing so, every key on the keyboard gets intercepted including the keys your refered to ('Delete' and the 'Windows key'), literally all keys on my keyboard except the 5 'Media Keys' that I have. When i press any of them, the script does not register any events and their normal effect happens (i.e. 'Calculator' -> opens 'calc.exe').

Maybe I am mistaken, but don't USB keyboards register multiple HIDs, hence the keystroke would come from a different device, a device that interception is not monitoring.

oblitum commented 12 years ago

I think I'm gonna reopen the issue but really have no idea of what's happening... Interception is able to capture USB and PS/2, and I've used with bluetooth mouse too, and that's why I've built API for device disambiguation. I remember testing long ago with a multimedia keyboard I had, for all those keys, calculator, browser keys and the like, all have been intercepted.... The only thing I can suspect with the knowledge I have of your case is whether your keyboard is a special one for which you have installed special vendor drivers. Do you? Regarding multiple HID for a single device I really have no idea whether this is the issue. If these multiple HID's are keyboard HID's, they should be intercepted, if not, then will not. My tests were on a USB keyboard (correction: it was PS/2), and I had not experienced this. I'm gonna look whether I still have this multimedia keyboard to test it again.

oblitum commented 12 years ago

No, now I see whether may lie the problem, my old multimedia keyboard was a PS/2 one... now to test this I may need to buy a multimedia usb one =P

oblitum commented 12 years ago

I just found a microsoft usb keyboard with some multimedia keys here at home, and indeed these keys are not being captured (although on a PS/2 device they were). This is going to be my next endeavor, thanks for the feedback!

spiwn commented 12 years ago

The drivers for my keyboard come with windows and as far as I know are generic/standard. When i plug my keyboard the following appear in Device Manager: HID Keyboard Device ( Manufacturer: Standard keyboards ) HID-compliant consumer control device ( Manufacturer: Microsoft ) HID-compliant device (Manufacturer: Standard system devices ) USB Human Interface Device x 2 ( Manufacturer: Standard system devices ; Location: Location 0 (USB Keyboard) )

My hunch is that the way you select devices excludes the virtual device that represents those keys. But I honestly cant say for sure.

P.s. I dont really care if the "Issue" is opened or closed. I just want Interception to be completed.

oblitum commented 12 years ago

Well, if the issue get closed, it'll be a sign of getting there isn't? I'll let it open till I solve it.

oblitum commented 12 years ago

I've checked and it seems I'll need to build a bunch of things at driver level to support these USB multimedia keys. They are treated completely different (and also, works through different device objects)... it's gonna take some time. Back to the drawing board... again spiwn, thanks for the feedback, I would never know by myself, at last, for a long time.

timstegeman2 commented 8 years ago

Hi, it's a long time ago you worked on this, but did you ever managed to get it working with the multimedia keys on a USB keyboard? I think I have the same problem with a Bluetooth remote shutter. One key is the enter key which I can capture, the other one is the volume up key which has the same problem as described above.

oblitum commented 8 years ago

@timstegeman I'm sorry, I coudn't address this matter. Besides that, it's really not simple to solve, since it's necessary to create an entire different kind of "Interception" just for those extra devices, which may or may not be possible.

archit9169 commented 5 years ago

Alright, it seems as long as there is a scan code, interception can recognize it and the device. The problem starts when there is not scan code and instead a virtual key code is send. A such example is my gaming mouse with a multimedia mode. In this mode, the scroll up sends Volume_Up, scroll down sends Volume_Down, and Dpi Down sends Browser_Home. In all theses three instances there are no scan codes. I check this via many software, all recognize only virtual codes and no scan codes.

When i do the same with my default keyboard, interception recognizes Volume_Up and Volume_Down perfectly.

So maybe the main problem is that interception does not interpret virtual key codes. So as long as there is a valid scan code, interception should work. Well this is my analysis.

@oblitum please test this. Am i wrong or is this the issue with major devices.

Rast1234 commented 2 years ago

Well that's unfortunate. I was trying to customize my Microsoft Ergonomic Keyboard with Capsicain app (which is built around Interception), found out it does not catch some keys. Tried Interception standalone, it does not see these keys too. But there's a vendor app to customize keys, so it receives data from keyboard somehow. I captured USB traffic with Wireshark and there's weird stuff going on:

I don't know anything about Windows drivers, but as far as i can see, Interception does not "talk" USB directly, so maybe there's some level of filtering done before which separates these packets from being processed as keystrokes?

PS Can share traffic dump if needed PPS Still looking for ways to gain control over my keyboard...

Rast1234 commented 2 years ago

After a lot of reading about USB-related stuff in Windows, i was able to capture media keys on my keyboard. I used HID directly (there are userspace libraries like Device.Net ). This method does not allow interaction with keyboard-like devices, but my keyboard showed up as several.. functions (?) which were separated into "keyboard" and something else. That "something else" is sending bytes when any non-standard key is pressed. So if anyone wants to deal with media keys, try enumerating your devices and try reading from HIDs resembling your keyboard.