Keyboard / Mouse Input Device Design??

Peter Olcott wrote:


What damn hardware ? You're very poor at explaining yourself.

What solution.
What are actually trying to make and don't go all coy about it being patented either.
Graham
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

One thing the OP may not realize is that, on all modern Windows OSes, you can generally plug in as many keyboards and mice as you like and Windows takes care of "merging" their input streams.
So I have a suspicion the OP really has no need whatsoever to build a "wedge"-type piece of hardware, but rather just a device that emulates a keyboard or mouse and can be (in some unspecified programmatic manner!) told what to "type" or where to "move and click".
In my mind this would still make a lot more sense to do in software. If his fancy technology can recognize what pixel needs to be clicked on anyway, a Windows driver can trivially move the mouse pointer to that spot and "click it."
---Joel
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Joel Kolstad wrote:

I would have thought so.
Graham
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Joel Kolstad wrote:

True. Raw Input interface would not only eliminate the hardware, it would excute in user-mode as a standard EXE, with network communication so that it all machines are controllable from a central machine.
http://windowssdk.msdn.microsoft.com/en-us/library/ms645536.aspx
-Le Chaud Lapin-
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I already have MS Windows completely handled, the answer there is mouse_event(), keybd_event() and SendInput(). What I am looking for is a solution for Mac OS, and Linux. Oh Yeah I forgot, there are (or used to be) a few apps the took their input directly from the hardware, so I might not have every single MS Windows app. One MS DOS app that did this was PC Anywhere.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Peter Olcott wrote:

Look at KVM switches the run over IP and allow a client on the PC to connect.
Some servers have remote management cards that do similar. You connect with VNC to control mouse and keyboard.
Thomas
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Mon, 30 Oct 2006 20:37:41 -0600, the renowned "Peter Olcott"

A friend of mine threw together a custom "keyboard" with rotary encoders and a bunch of keys (a custom control console for the entertainment business) and got it to talk to a PC fairly readily. He used a PIC 18F USB microcontroller and some demo code Microchip has available. It took him longer than a more sane person because he insisted on translating their C to assembler.
Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
snipped-for-privacy@interlog.com Info for manufacturers: http://www.trexon.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Spehro Pefhany wrote:

This must have been a personal project.
Was there a special reason to do it this way ??
As a learning project sure, but WHY ??
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Spehro Pefhany wrote:

Good Lord !
Why didn't he use a dis-assembler ?
Graham
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Mon, 30 Oct 2006 20:37:41 -0600, "Peter Olcott"

I don't know about the mouse but I feed keystrokes into a PC with an old keyboard card and reed relays across the matrix inputs.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

A mouse is a serial thing. Guess the old COM-port mice still work under WINXP. If I remember well, the Microsoft mouse requires three bytes 9600,n,7,1. The keyboard generates scan codes in a serial way. FAIK also 7 bits but a with dedicated protocol which has its own, separate clock. Maybe you can simulate it by fiddling with some parallel printer port pins but I never tried this out.
To build such a module, I'd use a micro with two UARTS. One to receive the data from the controlling computer and one to send data to the mouse interface. Three I/O pins of the micro can handle the keyboard interface. As the micro has to distinguish between data for the mouse- and data for the keyboard input you can set bit 7 for one of them.
As I see it, it's quite some work but not difficult. The program for the micro will be small. Hardly any calculation required. If you have more time then money, you can take a smaller, cheaper micro with only one UART and do the other in software.
petrus bitbyter
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

These would be mass produced. It looks like you have the right basic concept. How many hours would it take to build a prototype?
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Hard to say because of the prerequisite constrains are unknown to me. I'd say 80 to 100 hours. Half of that time would be used for the real work. So making a ready to use proto (including enclosure, connectors, power supply and so on). The other half for gathering information, like details of the protocols, availabily of components and obtaining them and for making decisions. After all, when you want to go to mass production, component price and availbility are important issues.
For instance, when I need to be fast, I'd go for an ATmega162. It's like killing a mosquito using a canon but it's the smallest one with two UARTS I know for the moment and it's not cheap. And there you go. Looking for a cheaper solution requires time so you're slowed down. I should not be astonished if even this very posting starts a discussion about more simple, cheaper solutions. Which is, after all, the main value of the group.
petrus biybyter
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Okay great so the project is feasible.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Peter Olcott wrote:

Not only is it feasible, but the more I think about it, the more I realize that you should do this in software. The reason is that, if you are already writing software that must exist on the host system, then you're already writing software on the host system, so you have control over what that system does.
There is no commercially available system where you cannot get as close to the hardware ports as possible in software. For example, on Windows, the keyboard hardware is controled by a keyboard driver (mone keyboard). Before a GUI window gets a pressed key, it must pass from this driver into another device driver called WIN32K.SYS. WIN32K.SYS gets the keys one by one in a RAW INPUT THREAD. So you have options. You can inject keystrokes using the Raw Input API, write a device driver (not trivial) to intercede KBHID.SYS and WIN32K.SYS, or write a driver that gets right up against the keyboard hardware and and feeds KBHID.SYS.
On Linux and other Unices, writing device driver borders on trivial compared to Windows, so you could do the same thing there.
I would seriously reconsider doing this in hardware, since the amount of effort to get 99% of your market is significantly less in software.
The ratio of material cost for hardware method vs software method is infinite.
-Le Chaud Lapin-
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On a sunny day (Mon, 30 Oct 2006 20:37:41 -0600) it happened "Peter Olcott"

Hi, I forgot to tell you in comp.os.linux.development.apps that the part where you read the screen is also problematic, as X has its own graphics drivers, etc. So you may as well add a web cam looking at the screen and associated analysing hardware too,. I think the Japanese are way ahead with robots :-)
Sorry s.e.d guys little inside joke, we met in c.o.l.d.a before...
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Are you saying that doing a screen capture is hard, or recognizing the graphical objects from the screen capture? (I got the last part solved).

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On a sunny day (Tue, 31 Oct 2006 06:17:58 -0600) it happened "Peter Olcott"

I am saying tha tto capture the screen in Linux, you must have access to the display buffer. If it runs Xwindows, in an application a buffer is created
A sequece would be something like this: Display *mydisplay; mydisplay = XOpenDisplay(displayname); XDrawPoint(mydisplay, topwindow, xptestgc, x, y); etc... (omitted important stuff).
'mydisplay' will be internal to the application, can even be a local variable... So if your application needs to read say graphic text, or boxes from the display, you have no access. You cannot grab data from the graphics card either, as all are different (bypass driver). There are many modes in X too, and there is the framebuffer that can be used. And then the same again for applications that use vgalib or just the basic text console. I would not know how to do it in a way that worked for _all_ systems known on Linux.
This is assuming your application reads what is on the screen, what you told me.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Jan Panteltje wrote:

[snip re X and buffers]

On any Unix system where the ImageMagick package is installed, one can use "import" to get an image from any part of the X display. See eg http://linux.about.com/library/cmd/blcmdl1_import.htm or man import. It is straightforward to exec import from a C program and then read the image file, which can be in any of the one-hundred graphics formats that ImageMagick supports. -jiw
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On a sunny day (Tue, 31 Oct 2006 10:40:55 -0700) it happened James Waldby

This is correct, and you can get window info to simply with xwininfo. However the OP wants it for _all_ Linux GUI apps. So there is svgalib, others, and I can also in an X program draw a menu without using or informing the X server (of a subwindow), using fonts unknown to the X server etc. I have done this. And you can have the situation where a person was in X, and then did ctrl alt F1 to show a normal console, so simply testing if X is present does no guarantee that is what is on the screen, etc. Other languages, character sets, libraries, video fullscreen, we have it all.
What the OP told me he has, needs to read and evaluate what is on the screen. 'Impossible' may not exists, but it will be _very_ difficult to cover all cases in Linux, it is not a monolitic integrated GUI like MS Widows.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.