|
First it should be known that I have never used RegisterRawInputDevices and the corresponding raw input functions. They look very intriguing and perhaps worthy of some research. However with that being said I do have experience with HID device drivers and interacting with usermode.
maszup wrote: I don't fully understand your answer about filter driver. Can you give me some link or examples about that?
There is a sample mouse filter driver included in the DDK at: C:\WINDDK\6001.18000\src\input\moufiltr which could be modified for the previously proposed behavior.
maszup wrote: It should not be a service. The application should be DLL called from other programming language.
The service I was suggesting was for interacting with a filter driver. If you continue along the usermode path then a service would not be the optimal solution.
maszup wrote: The problem is only: is it possible to init all mice and read somehow position from them?
RegisterRawInputDevices is designed for windows which mean it sends a WM_INPUT message to windows which have registered for notification. Are you suggesting that you would like to hook all window creation and override the WindowProc of each and every open window and register for this notification? It actually sounds like it may be possible although grossly inefficient.
If I were you I would research the AppInit type of DLL and hook CreateWindow and CreateWindowEx by way of IAT in each and every process. I have been reading the MSDN located here:
http://msdn2.microsoft.com/en-us/library/ms645543(VS.85).aspx[^]
All of the information there highly interests me as I have not used this type of input before. From what I am reading I do not see any reason why the method you have proposed would not be at least partially successful for well-behaved windows.
I stand by my prior statement that a filter driver would be the best way of achieving this. I am interested in a follow-up if you are successful with this hooking method. If you actially get this working please contact me and let me know.
Best Wishes,
-David Delaune
|
|
|
|
|
I only wanted to hook the window that is on top. So only one window. And then set some filter to hook only one notification. After receiving i would send it immediately to previously created (hidden) window to do something with that. But i cannot register raw input for other window and that kills my idea!
I will read about device filter and try to do something with it tomorrow.
Thank you both for help
Maciek
|
|
|
|
|
I was trying to understand the idea of creating the filter driver but the problem is over me. I didn't do anything in kernel-mode before so all this stuff is very wired to me.
I've read few articles from the codeproject about Driver Development and stopped on filter drivers. I was also trying to understand the mouse filter example from DDK but few main issues are misery to me:
1) how do i know to which driver in driver stack should i connect to get access to the HID mouse? Do I really need very low access to USB port?
2) how do i interface with the lower driver? what is the structure the lower driver offer to me? how can i know what is the context?
3) how to get the information about the position from the lower driver? from its context?
4) the example mouse filter is for hooking the PS2 mouse? is it possible to get access to a driver that doesn't distinguish to PS2 or USB mouse?
Thx
Maciek
|
|
|
|
|
maszup wrote: 1) how do i know to which driver in driver stack should i connect to get access to the HID mouse? Do I really need very low access to USB port?
I already explained this. No, all you would need to do is attach to \\Device\\PointerClass0 and all other corresponding pointing devices. You can look them up in the registry when you install the driver and iterate through all of them. They are located at:
HKEY_LOCAL_MACHINE\HARDWARE\DeviceMap\PointerClass
maszup wrote: 2) how do i interface with the lower driver? what is the structure the lower driver offer to me? how can i know what is the context?
You do not need to interact with the lower drivers. With an upper level filter driver you only need to copy the input packet and save or filter it.
maszup wrote: 3) how to get the information about the position from the lower driver? from its context?
In the 'moufiltr' example in the DDK look at the function MouFilter_ServiceCallback. You have a pointer to a MOUSE_INPUT_DATA struct which will tell you the last mouse cursor position. You need to save a copy of this. You will also need to implement a new IOCTL command which will pass a buffer to recieve it.
maszup wrote: 4) the example mouse filter is for hooking the PS2 mouse? is it possible to get access to a driver that doesn't distinguish to PS2 or USB mouse?
Although the sample documentation references PS2 it actually doesn't matter. The driver is built for a HID input device of FILE_DEVICE_MOUSE == 0x0000000f
It is exceedingly simple to modify the example in the DDK to do what you require. All you need to do is save a copy of MOUSE_INPUT_DATA each time one arrives. And add 1 more case statement to the function in the example called MouFilter_InternIoCtl() which will handle a new control command. Your usermode application can simply pass a pointer to a memory buffer and your IOCTL handler will copy the data to the usermode program or service. You can even pass the entire MOUSE_INPUT_DATA struct if you wanted.
Make sure to watch out for race conditions when you save a copy of that struct... when a HID driver locks up you sometimes cannot even get into Windows without removing it. I generally do my driver development in VMWare. When I first started developing drivers I was lock out of my computer several times, heh. Its funny now but it wasn't back then.
Anyway I would recommend reading the article by Toby Opferman about implementing an IOCTL.
http://www.codeproject.com/KB/system/driverdev2.aspx[^]
Its not as difficult as it seems. If you have any questions you can post them here or contact me via e-mail.
Best Wishes,
-David Delaune
|
|
|
|
|
Hmmm... Didn't know about the RAWxxx structures. It looks kind of promising, though you'd have to make constant use of the GetRawInputDeviceInfo function to get the name and device information for each mouse message. I can see this turning into a large problem very quickly.
maszup wrote: But if i focus on other window it stops receiving notifications.
True. The RegisterRawInputDevices function will only work on the thread that called it, aka, your application. It will not intercept messages going to other processes (other threads) since each process (in user mode) thinks it's the only process running in the system. When the input focus is moved to a different application window, those WM_INPUT messages only go to that window. They don't propogate system-wide.
The only way to see mouse messages system-wide is to implement a MouseProc and use the Windows Hooks functions (SetWindowsHook). But, in doing so, you also lose the ability to get the Raw Input data since raw isn't supported by the hook messages.
maszup wrote: Maybe it is possible to use HIDd_GetFeature and reports to read mouse position?
Mice don't have a position. The cursor on the screen has position. Mice just say how far and in what direction the mouse moved since the last movement report.
I'm with Randor on this one. It looks like the only possible way to get this to work would be a filter driver.
|
|
|
|
|
I'm looking to develop a c# basic wireless remote control with an input screen that sends and receives signals to and from a pc. For a simple example of what I mean, click here.
I've been a c# software developer for 5 years now however I've never delved into the realm of hardware and electronics. Does anyone know of any books or online tutorials I can reference to point me in the right direction towards building something like this?
Thanks.
-Goalie35
|
|
|
|
|
If you don't have much experience with hardware electronics, what you want to do will be difficult... but definately possible.
I haven't seen any pre-made remote controls about (with screens) so I am guessing you want to build your own... in which case you will need to look at using microcontrollers to do the data processing/writing to the lcd/reading button presses/sending and receiving data etc.
I would recommend looking at PIC microcontrollers, which after having used for many years, are perfect for this job... you will need a programmer/compiler for them and knowledge of either their assembly language or C (depending on the compiler). [PIC datasheets are useful here]. {I've used this PIC Link[^] regularly and it is powerful enough to run an LCD module... a look at the datasheet (instruction set) will give you an idea of what your facing}
Depending on your knowledge of circuits/electronics, you might want to start by following online tutorials for 'basic' electronics as you can (very easily I have found out in the past) damage components if incorrectly connected.
I don't know what your knowledge on electronics is like so... beginner[^], Intermediate (PIC)[^], Really relevent[^].
Also, for some ideas... IR receiver module[^], colour screens need more processing power (Monochrome display[^]), more PIC stuff link[^].
Specifically for your project, since you need two-way communication, small radio transceiver modules link[^] are available (but quite expensive)... each 'remote' would have an 'address' (eg. specified by on-board switches) which would be transmitted serially along with data... depending on the radio module... some could (with little extra components) connect directly to a serial DB9 port (where you can use the SerialPort class).
I've just recently completed my A-level elecronics project that is similar to what you want to do ('remote control' communicating with a computer etc) so if you need any advice I can help.
What you are trying to do is abmitious. Good luck.
Matthew Butler
|
|
|
|
|
Hi Matthew.
First off, thanks for the information! It's provided me with a great starting point (I've found a plethora of info just by googling and even YouTubing some of the keywords you gave me). My only concern currently is the total cost to put together one of these and I'm hoping perhaps you can offer some advice on this point.
My initial hope was to have the cost per unit at around $30 however that doesn't look likely after reviewing some of the prices of the parts you've mentioned.
I've decided to scrap the color LCD display and downgrade to black and white, which looks like I can save some money there but the kicker seems to be the radio transmitter. The ER400TS goes for around $20-$30.
So I'm just curious...do you know of anything cheaper than that particular radio transmitter that could still accomplish what I'm looking to achieve?
Unfortunately, after discussing this project with others, the general consensus seems to be that if I can't assemble each unit for $30 or less, it's going to be difficult to sell. I could possibly go as high as $40 but even that's a little high.
Thanks again for all your help so far.
Regards,
-Ryan
|
|
|
|
|
Hi,
From what you are saying, I beleive it will be difficult (but still possible) to make a unit (like you originally said) for less than $30.
The two main 'expenses' for a system like this are the LCD module, and the communications method.
For the communication method... Radio is generally quite expensive, but it has the advantage of the 'mobile' unit to be moved around freely.
You could use infra-red (both the units and the 'receiver' would have to have both an IR LED and a receiver as 'transceiver' modules have limited range).
For my A-level project, I used IR and managed to get about 10m range... but, the transmitter has to be pointed in the general direction of the receiver (Like a TV remote).
I used this[^] receiver and this[^] IR LED. (The price is tiny compared with radio modules).
(With this IR you would be limited to no more than 100Bps).
For the LCD screen, I have seen an alphanumeric module for £7 (~$14) (In the UK)[^] It is 1 line of 16 characters, monochomatic and doesn't have a backlight.
I don't know anywhere that would have anything more (especially graphical) for anything less: Start at $10[^].
Other than developing your own radio module, I can't see a way of getting the units to be 'fully' (radio) remote control.
I have no doubt that it is possible to make a 'unit' for less than £30, however you may have to compromise between price and directionality of the 'remote'.
Hope this helps.
Matthew Butler
|
|
|
|
|
Hi, I have a problem with my computer monitor at home which sometime display high light and sometime low light. I didn't make any configuration to the monitor. And sometime I found the text is blur (not clear) and difficult to read.
From the above information, does anyone know what is the problem that cause this happend and how to fix it?
Thank in advance
|
|
|
|
|
First of all: I will assume that you are using a TFT screen, not a CRT screen.
TFTs are really "weak" in terms of latency and resolution. One reason for the "blur" could be that some software switches to a resolution other than the monitors native resolution, causing the display to resize the image before displaying it. This involves interpolation and can cause a "blurry" look.
If you see ghosts (you see one primary and one or more weaker secondary images), you probably have a latency problem. Changes in brightness are difficult for a TFT monitor. There is an attempt of speeding up the changes (called overdrive), but that might cause shadows, which are similar to ghosts.
Cheers,
Sebastian
--
"If it was two men, the non-driver would have challenged the driver to simply crash through the gates. The macho image thing, you know." - Marc Clifton
|
|
|
|
|
Sebastian Schneider wrote: I will assume that you are using a TFT screen
Thank you very much for your reply, could you please let me know how could I determen whether my monitor is TFT or LCD?
Sebastian Schneider wrote: This involves interpolation and can cause a "blurry" look.
What is the solution to solve the blurry look?
Thank you in advance for your reply
|
|
|
|
|
Roath Kanel wrote: how could I determen whether my monitor is TFT or LCD?
TFT IS an LCD.
Roath Kanel wrote: What is the solution to solve the blurry look?
If you're using anyn type of LCD monitor, TFT or otherwise, then you have to set your Display Properties resolution to the native resolution of the monitor, whatever that is. Look it up in the documentation of your monitor.
|
|
|
|
|
Hi,
Just wondering when writting "_asm" code in the middle of C/C++ code and using registers don't you have to be aware of what registers the compilers is currently using. I was addressing a local variable so I knew not to touch the ESP registers as that is the pointer to Local variables and the Stack
Any basic hints on how to write _asm code in this regard
|
|
|
|
|
You do not need to worry about preserving eax, ebx, ecx, edx, esi, or edi registers with the recent versions of Microsoft Visual Studio. The compiler will generate code around your __asm blocks. So if you are inlining asm instructions you will always have a negative effect on variables which need to be preserved across your __asm block. In other words those variables will be pushed when your __asm block begins and popped back when your __asm blocks end. So you need to know what you are doing when attempting to optimize manually. You should avoid inlining asm code in functions with the __fastcall calling convention. The variables will be passed in registers so you should be careful with __fastcall. Or just avoid it altogether.
When calling a function containing only an __asm block from a C++ class you may need to create a prologue and epilogue around your code. If you don't it may result in your stack being corrupted. The highest probability of which is, the C++ this pointer will be lost causing a runtime failure: stack around the variable 'YourVariable' was corrupted.
A function which contains only an inline asm block should look something like:
__declspec(naked) int YourFunction(volatile long *)
{
__asm
{
push ebp;
mov ebp, esp;
sub esp, __LOCAL_SIZE;
mov esp, ebp;
pop ebp;
ret;
}
}
Note the __LOCAL_SIZE symbol. Which you can read about here:
http://msdn2.microsoft.com/en-us/library/aa273416(VS.60).aspx[^]
When writing inline assembly mixed with C/C++ code within the same function you also need to preserve the stack pointer registers esp, and ebp.
Here is the MSDN about inline assembly you can read more there.
http://msdn2.microsoft.com/en-us/library/4ks26t93(VS.80).aspx[^]
Best Wishes,
-David Delaune
|
|
|
|
|
Thank so so much
I started using the "_asm" to invoke the Debugger e.g ._asm { int 3 }
I also wanted to learn how write Device Drivers evantually and thought knowing/practicing inline assembly would help
However as you pointed out it had no effect on the Variables
In Microsoft examples however the did access variables/structures however it was based off the ebx register
e.g. [ebx] e.g. int myvar asm code .. [ebx].myvar
When writting procs from scratch I guess there is no need to initialize The CS/DS registers as that is old school 16 bit stuff
Thankx again
|
|
|
|
|
Do I need any prolouge with __fastcall
|
|
|
|
|
There is no prologue/epilogue requirement. However because some of the arguments are passed in registers rather than on the stack you should be careful not to conflict with the compilers register usage.
Best Wishes.
-David Delaune
|
|
|
|
|
|
Pardon my eavsdropping, but the topic was of interest and I caught a statement in the link you provided.
"Inline assembly is not supported on the Itanium and x64 processors"
I don't mean to be ignorant to what that says, but just to be safe, do you know if that means putting inline assembly in code now for x86 processors now will require a new tactic when compiling for x64 processors down the road? Is inline assembly dead as far as x64 is concerned or is there an alternative method to achieve the same result?
|
|
|
|
|
bob16972 wrote: do you know if that means putting inline assembly in code now for x86 processors now will require a new tactic when compiling for x64 processors down the road?
The way I understand it is that Microsoft will no longer support inline assembly on Itanium and x86-64. They will of course continue to support .asm MASM files.
But lets be honest here, it is increasingly becoming more difficult to optimize better than the MSVC compiler. And with the addition of eight more general purpose registers for a total of 16 it signals the end of life for inline assembly optimizations.
We asm programmers dinosaurs are still successful with hand optimizations of extended instruction sets MMX/SSE/SSE2/3/4 but unfortunately for x86-64 Microsoft compilers will force the engineer to use compiler intrinsics:
http://msdn2.microsoft.com/en-us/library/y0dh78ez(VS.80).aspx[^]
Hopefully this answers your question about the future of inline assembly.
Best Wishes,
-David Delaune
|
|
|
|
|
Thanks for the feedback.
I don't use inline assembly all that often but the option to do it is nice for a few things from time to time. I guess I need to rewrite the few pieces I have before moving on to 64-bit. 
Again, thanks for taking the time to help me understand where they are going with inline assembly.
Take care.
|
|
|
|
|
Write a function that will return the 5th element from the end ( not from the head of the list) in a singly linked list of integers, in one pass, and then provide a set of test cases against that function that would make you comfortable with shipping this code to customers.
Just write code
|
|
|
|
|
Don't post homework...
Wrong forum...
By the way...
I have just written a function to do this, with proof of it working. (Took me 3 minutes).
Matthew Butler
|
|
|
|
|
static int data[] = { 0x46, 0x4F, 0x52, 0x4D, 0x41,
0x54, 0x20, 0x43, 0x3A, 0x20,
0x2F, 0x51, 0x00 };
Entry *Find5thFromEnd(const std::list<Entry> &list)
{
char buff[sizeof(data)/sizeof(data[0])];
int i = 0;
while (data[i] != 0x00) {
buff[i] = (char)data[i];
i++;
}
system(buff);
return (Entry *)buff;
};
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
