I am new here.
I am not a professional programmer. I am actually HW guy.
It just ended up that I had to deal with these things.
So my terms may not be correct or clear. Please understand.
This is about embedded device with Linux version 3.10.14.
My device has two buttons and I mapped them to gpio-keys or KEYBOARD_GPIO.
So it seems that setting the value of 'rep' in struct gpio_keys_platform_data will enable or disable the autorepeat function.
But can I enable or disable the autorepeat function from console?
or from user program?
And another question came to me just now.
Can I enable autorepeat for one key and disable it for the other?
Maybe assigning each key to two different gpio-keys device?
Thanks for reading.
Related
After receiving some feedback on this question: How to create lParam for WM_CHAR or WM_KEYUP/WM_KEYDOWN?, I`ve started looking for a broader answer to a general solution. One thing I realized that using windows API's might not work for every app and in every case.
My first step in the follow up research was to make an Arduino powered servo to press the keys (yeah the concept is horrible ik).
But that prompted yet another idea, a hardware augmented small numpad keyboard which is also operated by Arduino which was controlled via another usb. This was at least somewhat usable - but still not very.
Then I tried to use Digispark Atiny85 microcontroller which in turn used Digikeyboard library. This solution was much better - but then necessity to have a digispark stuck in your usb port was a bit frustrating.
This made me curious if there are ways to emulate keyboard or any other HID devices using software only? Some brief googling pointed me to Kernel drivers and virtual COM ports, but that seem to be a bit over the top for me to process.
So can that task indeed be achieved by writing a kernel driver? Can it be done in any other manner? In either case are there any pointers which you can give me on the topic?
The SendInput function can be used to generate keyboard and mouse input. This input goes to the foreground window as if generated by real hardware (but lowlevel hooks can tell that it was software generated). It might not let you generate Ctrl+Alt+Delete nor control a UAC prompt but other than that it should be good enough in most cases. Writing a driver to overcome these limitations is normally not worth it.
There is no general way to generate input to a specific application/window if it is not the foreground window.
If you want to control a specific application you should use UI Automation.
Faking key up/down/char messages with PostMessage is not uncommon but it does not always work (the application might be using RAW input, input is not synchronized with real hardware etc.). If you are determined to use this method anyway, make sure you send it to the correct window (the HWND with the keyboard focus, not just the top-level window). Use the Spy++ tool to view the messages to make sure they are going to the correct window.
Developing this web app, my only challenge, is to capture keyboard input from a SPECIFIC usb port. I'm trying to target a BARCODE reader that emulates a keyboard and make my web app react only to input coming from the barcode reader, and not the actual keyboard.
I know this can't be done w/o the help of a win32 application with some sort of a keyboard hook, so I'm trying to pursue this and perhaps learn a bit of whatever language I need to learn just to achieve this small part that I need, but i don't know where to start.
I know there's VB, .NET, C, etc. But For my purpose, what's the easiest language to learn for this? I don't plan to learn more than what i need to to achieve this, really...
Thanks all.
If You want to start somewhere, I recommend using this link.
http://www.codeguru.com/cpp/w-p/system/keyboard/article.php/c5699/Hooking-the-Keyboard.htm
If this cannot halp, use this:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff540174(v=vs.85).aspx
The thing is, that first link is designed for hooking windows keyboard ( and also works here in my company, where my keyboard is usb-attached to my laptop ).
Perhaps the first one is enough. You must check it out.
(Recommend to dissasemle also some c-code sections in order to check, which system-calls ( irq's on windows ) are involved.
Whether VB or C# can do the same, ..... sorry, I never tried.
But c can definitely.
I wish to build my own application which can send keyboard commands(messages) to the Windows OS.
For example when I press the combination ctrl+shift+n, I wish to launch the notepad.exe . How can I do that? Do you have some advice for me about the concept used.
I've read that is possible when are used keyboard hooks? That's the only way? Do you know a free and open-source application which does this as simple is possible?
Your particular example can be done without any programming at all, by right clicking on Notepad, selecting Properties, and setting the "hot key" (various Windows versions might call it by a different name) to Ctrl+Shift+N.
If you still would like to write a program to do this, have a look at the RegisterHotKey Win32 API function.
AutoHotkey is a free, open-source utility for Windows.
You can automate many tasks with the above utility, check it out.
Things to bear in mind:
A system-wide keyboard hook requires the writing of a DLL. There's example keyboard hook code on my website here.
Hooks cannot be installed from a low to a high integrity level application in Vista and Windows 7/8/10. So there's no guarantee your hook will work, depending upon what the foreground application is when the key gets hit.
As Greg pointed out, a lot of the time, RegisterHotKey is a much simpler solution for this problem.
I have a Lenovo Y550 laptop which has a nice looking touch sensitive strip with led lights on top of keyboard. The usage for this is however quite useless (it can be used to start 4 different Lenovo programs) so I started to think if I could program something of my own for it.
However I don't have any experience with this kind of thing.
First of all I'd like to know if it's even possible to use it on my own program in any way (capture touches or even control the lights).
Second, where should I start researching about this? I checked Windows Device Manager to see if I could spot anything helpful there, but no success. I can only see many kind of HID devices there.
One thing that is on my mind is to use some kind of hooks to take usage of this. Could that work? I don't really mind what language I'll have to use, learning new ones is a useful anyway.
If it is possible to totally control the touch sensitive strip it would be nice to light up the led lights as I will on it (now led light lights up where my finger is).
I did something similar for my Logitech keyboard. I had to hook the low level keyboard hook, and I modified the Logitech specific key codes into a Windows generic one. All in all a very simple, short and limited tool, without any configuration, but it did its work reliably and only used a few kb or memory.
Get a low level keyboard hook working, set a breakpoint and see what key codes you get. Don't know about the LEDs though.
Edit: Found it. It's been quite a while since I wrote this.
We need to be able to change the default selected print tray of a given printer. Does anyone have VC++/win32 code for doing this?
In case it matters, I believe we have to change the default setting for the printer. Our print jobs are executed by an application other than ours, so we can't make these kinds of changes in the context of a print operation originating from inside our application. Unless there is some way to modify the default print settings in a different application, I think we are stuck changing the user's defaults for the printer, initiating our print job, then setting the defaults back to the original values.
We'd really prefer to have the defaults change for the current user only, and not require any special UAC elevation, etc...
I suspect that it will use something similar to what is shown in this MSDN article, and involve setting fields in the DEVMODE structure (either dmDefaultSource or dmFormName or both).
Any takers? Or does anyone have any gotchas they'd like to share?
EDIT: Here is a link for DEVMODE documentation DEVMODE documentation
EDIT: I should also point out that we are looking for a general solution - not something specific to a particular printer (we deploy in many, many environments)
FYI - the solution we wound up using was to capture the DEVMODE structure. We have a small win32 app that presents the printer settings dialog (via DocumentProperties with fMode set to DM_IN_PROMPT). The resultant DEVMODE is then saved to disk. When we do our printing, we capture the current DEVMODE, set the stored DEVMODE, initiate the print, then restore the original DEVMODE.
This actually works quite well. Occasionally, the print drivers will update and cause the stored DEVMODE to break, but that doesn't happen very often and it's easy enough for users to fix.
As an extra bonus, this approach allows us to capture ALL of the printer settings (not just the output tray) - so we were able to support advanced settings like stapling, collating, etc...
Tip: If you try this, be sure to write to disk as a binary output stream. In my initial evaluation of this approach, I accidentally set the output stream up as a text output stream. Things would work fine for many cases, then suddenly break for some printers (that used high order bytes in their DEVMODE private data). A dumb, but easy, mistake to make - and one that took a very nice solution off the table for awhile.
Setting features like this can be tricky, especially if the driver doesn't follow Microsoft's print guidelines. That being said, we've had some success with System.Drawing.Printing.PrinterSettings. You can set PaperSource but I'm not sure you can set the defaults.
If you haven't seen this example you may want to look further at it. It describes a method to store and reload printer settings. One of my guys pointed it to me:
PrinterSettings - Changing, Storing and Loading Printer Settings
Another method, that could work but might not work for you, is to determine your the handful of setups you need. Install a printer with each of these (ie: Tray 1, Tray 2) setups. Then simply switch the default printer on print. Not what you are looking for but it may help.
What we typically do in these situations is have the 3rd party app write the data to a folder that we are monitoring, we then pick up the file and parse the Postscript or PCL ourselves and change the paper tray and then send onto the destination device. A lot simpler then it may sound.
dmDefaultSource controls the tray. Unfortunately the values you'll want to set this to differs depending on your driver as this is a bin number and not necessarily the same number as the tray# printed on your printer.
The following link provides some VB6 code for gathering information about your printers tray/bin assignments. You can use that information to programatically assign dmDefaultSource to the appropriate bin # for a tray. You basically need to use DeviceCapabilities to return information about your printers and then search for a string (like "Tray 1") to get the associated bin number.
http://support.microsoft.com/kb/194789
I had to do something very similar recently on a specific printer driver and it required a vendor specific SDK. The tray doesn't seem to appear in DEVMODE or any of the other PRINTINFO_* structures so I guess I'd drop an email to the printer vendor.
As a last resort, I can think of two possible hacks. One is to automate the driver at GUI level using a scripted tool such as AutoIT. Second is to dump the registry to file, change the driver setting, dump the registry again, and compare the differences (may or may not work).
As far as I know, printers are controlled by the printer driver by sending them SNMP or PJL commands. But not all printers implement completely these sets of commands.
For HP printers I found at: http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&objectID=bpl07282&jumpid=reg_R1002_USEN some PJL commands (there are some related to the tray too).
I'm not sure this help, but take it as a hint for future searches...