I need to know how difficult it would be to design and build a device that is able to force hardware keystrokes and mouse operations into an Intel based motherboard. I was thinking that it could have one end plugged in to a serial port or USB, and the other end would be a Y connection to the keyboard and mouse ports. How difficult and costly would building such a device be?
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"
speff@interlog.com Info for manufacturers: http://www.trexon.com
I suppose if you started with a ball mouse card and tricked up the pulses that normally come from the wheel photo cells you could make the cursor move around but I doubt you could actually hit the right spot in any repeatable manner. The buttons are just switches so they are easy. I found it was a lot easier to just use an application that could be operated by keystrokes.
"Peter Olcott" schreef in bericht news:_Fy1h.69468$ snipped-for-privacy@newsfe19.lga...
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.
On a sunny day (Mon, 30 Oct 2006 20:37:41 -0600) it happened "Peter Olcott" wrote in :
mouse
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...
I need to do the MOUSE and the KEYBOARD. I have patented technology that can intelligently recognize anything on any GUI screen. There are some applications that get their keyboard input directly from the hardware. There might be some applications that do the same thing for the mouse. I want a single solution that always works on the Intel platform that can be used for automated testing on any OS.
On a sunny day (Tue, 31 Oct 2006 06:17:58 -0600) it happened "Peter Olcott" wrote in :
graphical
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.