I'm trying to get the position of finger on laptop touchpad in Delphi. Not the position of cursor on screen. So I can use it for drawing purposes. Is this possible? How can I do this? Is there any Windows API or any component for this?
Thanks for your help.
Update
I found a software for Lenovo touchpad that does the exact thing. It only shows the position of fingers on touchpad and PEiD says it's been written with Visual C++. So I guess it's a possible thing but as David Heffernan said it depends on manufacturer of the touchpad and it's hardware specific.
Coincidentally, I've just spent the last 30 minutes researching this very thing.
Windows supports this through the touch and gestures APIs. These were introduced in Windows 7 but touchpad drivers didn't tend to offer the necessary support until Windows 8 arrived and made it a logo requirement.
Synaptics and Alps seem to be the principal touchpad manufacturers and they have both released updated drivers for Windows 8 which also work on Windows 7. "Multitouch" is the keyword to search for. This is touchpad-model dependent though; I can't find an update for older Alps devices.
In short, this should work on a "Designed for Windows 8" laptop. It may work on Windows 7 and if it doesn't you may be able to get an updated driver.
The short answer is generally no, this is not possible. Touchpad drivers present to the operating system such that they appear and behave like a mouse does. Absolute coordinates are not available. For this application you need a proper touchscreen device or tablet, at least if you are looking for a general solution that is supported by the operating system.
Some touchpads may provide this information through a hardware-specific driver, of course, but you would need to support, where this is even an option, each device independently. Synaptics, for example, provides an SDK and drivers that can expose the absolute coordinate information.
For tablets or other full-screen digitizers that are supported as "Pen and Touch" inputs, this information is usally obtained through the WM_TOUCH message. Some advanced touchpads may support this - you can always query to discover what features are supported. For those that are, you have to register your application's window to recieve touch messages as detailed here :
Getting Started with Windows Touch Messages
Upon receiving a WM_TOUCH message you can obtain detailed information by immediately passing the touch handle to GetTouchInputInfo. Which returns an array of TOUCHINPUT structures, each carrying information about each active touch point on the digitizer surface.
Related
I need to know how to get which kind of video card is using in directX, because some features in my program are not supported in amd video card and cause crash.
So, I need to get which card the computer is using(some computer may have more than one video card).
So before you throw ATI/AMD under the bus here, make sure that the problem is not actually due to your application. For Direct3D 10/11, be sure to enable the debug device and ensure you do not have any CORRUPTION or ERRORS, and look at all WARNINGS.
Next, see if there is a newer driver available for the repro case. If there is, then just tell your users to update their drivers. If not, and it seems to be a legitimate crash inside the driver then report that as a bug to ATI/AMD (or NVidia or Intel as the case may be).
Test your app on more than one video card/driver combination from each vendor. For indies this can be challenging, but it's an important part of making sure your application works on a broad set of hardware. For Direct3D 11, you need to try various Direct3D hardware feature level devices to ensure good coverage.
Real games do have some extra warnings tied to detecting specific hardware IDs when dealing with wide-spread driver bugs and unofficial vendor-specific extensions). There is an example of doing this detection here based on the vendorid/deviceid combination in DXGI_ADAPTER_DESC or D3DADAPTER_IDENTIFIER9. Locking out all cards from a specific vendor is overkill and likely to just annoy your customers.
I am looking for the SDK for the Perceptive pixel touch drivers. It looks like Microsoft took over the company, but there seems to be very little documentation on where I can find the sdk for the drivers.
After finishing the project. What we found out is the following, Microsoft purchased PPI. After purchasing PPI the SDK became very locked down. We were unable to gain a copy, however, that is not to say somebody in the future may be more fortunate.
Some of what we lost because of this was using two monitors with touch enabled, didn't allow for us to be able to touch two screens simultaneously unless we added careful placement of e.handled on touch events.
I want to use a second pointing device (the trackball) as a control for a specific function on a program. This means I would NOT want any mouse functionality from the trackball, I just want to get the movement data and somehow use the NPAPI to get that into our web app. Is there a way to bind a mouse/trackball to a specific program that it doesn't act as a mouse/trackball for the computer?
Thanks in advance!
UPDATED: actually ask a question
To the best of my knowledge and my understanding of how HID devices work, there is no way to do what you want to do. If you could do it at all, you could probably do it from an NPAPI plugin, but there is no way to tell the operating system not to take control of one specific pointing device as opposed to any others.
Now, if you had a special HID trackball that didn't show up as being a regular pointing device then you could possibly do it with that, but I have never heard of any way to take control of just one of potentially many HID pointing devices on windows, linux, or mac.
There may be a way to hack something together in Linux by changing the way the drivers work, etc, but I don't know of any.
Is it possible to get location data out of Google Gears, Google Gelocation API or any other web location API (such as Fire Eagle) in such a format that it appears to other software as a GPS device?
It occured to me reading these answers to my question regarding WiFi location finding, on Super User, that if I could emulate a GPS unit, many of these web services could act as a 'poor-mans' GPS to otherwise less useful software that requires it.
Is GPSD an option?
Preferably OSX & Python, but I would be interested in any implementation.
There is a very similar thread on a Python mailinglist that mentions Windows virtual COM ports and discusses Unix's pseudo-tty capabilities. If the app(s) you want to use let you type in a specific tty device file, this may be the easiest route. (Short of asking the authors to provide a plugin API for what you're trying to do, or buying yourself a $20 bluetooth GPS mouse.)
Are you using OS X?
There is a project macosxvirtualserialport on Google code that provides a graphical wrapper around some of the features of a utility called socat. I'd recommend taking a look at socat if you see potential in the pseudo-tty route. I believe you could use socat to link a pipe from a Python program to a pseudo-tty.
Most native Mac apps will be querying IOServiceMatching for a device with kIOSerialBSDRS232Type, and I doubt that a pseudo-tty will show up as an IOKit service.
In this case, unless you can find a project that has already implemented such a thing, you will need to implement a driver as described in this How to create virtual COM port thread. If you're going to the trouble of create a device driver, you would want to base it on IOKit because of that likely IOServiceMatching query. You can find the Apple16X50Serial project mentioned in that post at the top of Apple's open source code list (go to the main page and pick an older OS release if you want to target something pre-10.6).
If your app is most useful with realtime data (e.g. the RouteBuddy app mentioned in the Python mailinglist thread can log current positions) then you will want to fetch updates from your web sources (hopefully they support long-polling) and convert them to basic NMEA RMC sentences. You do not want to do this from inside your driver code. Instead, divide your work up into kernel-land and user-land pieces that can communicate, and put as little of the code as possible into the kernel part.
If you want to let apps both read and write to these web services, your best bet would probably be to simulate a Garmin device. Garmin has more-or-less documented their protocol in the IntfSpec.pdf file included with their Device Interface SDK. Again, you'd want to split as much as you could into user-space code.
I was unable to find a project or utility that implements the kernel side of an IOKit-based virtual serial interface, but I'd be surprised if there wasn't one hiding somewhere out there. Unfortunately, most of the answers I found to that question were like this, with the developer being told to get busy writing a kext.
I'm not exactly sure how to accomplish what you're asking, but I may be able to lend some insight as to how you might begin to get it done. So here goes:
A GPS device shows up to most systems as nothing more than a serial device -- a.k.a. a COM port if you're dealing with Windows, /dev/ttySx if you're in *nix. By definition, a serial port's specific duty is to stream data across a bus, one block at a time. So, it would then follow logically that if you want to emulate the presence of a GPS device, you should gather the data you're consuming and put it into a stream that somehow acts like an active serial port.
There are, however, some complications you might want to consider:
Most GPS devices don't just send out location data; there's also information on satellite locations, fix quality, bearing, and so on. Then again, nobody's made any rules saying you have to make all that data available. There's probably more to this, but I'll admit that I need to do more research in this area myself.
I'm not sure how fast you can receive data when dealing with Google Latitude, etc., but any delays in receiving would definitely result in visible pauses in your "serial port"'s data stream. Again, this may not be as big a complication as it seems, because GPS devices are known to "burst" data across the bus anyway, but I'd definitely keep an eye on that. You want to make sure there's always a surplus of data coming across, not a shortage.
Along the way you'll also have to transform the coordinates you receive into valid GPS sentences, as well. You can find specifications for those, but I would definitely make friends with the NMEA standard -- even though it is a flawed standard, it's the one everyone seems to agree on anyway.
Hope this helped you, at least a little bit. Are there anymore details specific to your problem that you think could be useful in answering this question?
Take a look to Franson GPS Gate which allows you to connect to Google Earth among other things (like simulating GPS and so on). Is windows only though but I think you could get some useful ideas from it.
I haven't looked into it very much, but have you considered using Skyhook's SDK? It might provide you with some of what you are looking for. It's available for every major desktop and mobile OS.
We have a range of PC demonstration programs for our microcontroller products. The programs typically connect to a USB HID chip on the microcontroller board. The USB chip acts as a communications bridge, allowing the programs to communicate with the micros over SPI/I2C/UART. The programs can configure the micros, and get back status information to display to the user.
We are now looking to build some standalone demonstrations using single board PCs. We would like to reuse as much as possible of our existing demo app source code. Ideally, we could just run them as-is.
Does anybody have any advice on the best way forward? The basic options seem to be WinCE or XP Embedded boards. WinCE boards seem to pull less power, which would be an advantage from a battery life point of view.
Our existing demos are built either in C++ under Borland Builder, or in Delphi.
Thanks in advance.
EDIT: see my answer below with info from a board vendor.
Free Pascal/Lazarus can compile some forms of Delphi apps to WiNCE/arm. Even visual ones.
There isn't a Delphi version for WinCE, so you would need to rewrite the applications. The same applies for the Borland Builder's control libraries. Only if you have used plain Win32 API, you would be able to port your application to WinCE easily. You may also encounter problems with the hardware access part. The Serial Port driver may not work as is. Also, you need to find a WinCE board that can act as USB host and provides HID drivers (this isn't very common).
In conclusion, I believe that you would be better of with Windows XP Embedded boards. These should run your applications as they are.
As an update, and for future reference, I thought I'd post the results of our discussions with a WinCE board vendor here. Caveat: I haven't actually tried any of this.
The bottom line is that there isn't a straightforward way to do what we were hoping for (i.e., re-compile our existing demo applications to run under WinCE). The reason is that the generic HID drivers and standard APIs that exist in desktop flavours of Windows just aren't there in WinCE.
To talk to HID devices in WinCE you need to implement a custom HID driver. This needs to support an interface allowing user mode applications to communicate with the driver, and to construct HID reports to be sent to the physical device. As this interface would itself be custom, application code needs to be updated accordingly.
WinCE application development is generally done using Visual Studio and the Microsoft compilers. The approach recommended to us was:
Create a custom HID class driver. This could be based on, for instance, the Microsoft keyboard HID driver.
Create an API for talking to the driver.
Use .net to create our GUI applications, and use PInvoke to actually talk to the API.
The end result of all this head-scratching is that to avoid the time and learning curve associated with this approach, we're going to go for a board running XP. We can then use our existing demo applications straight out of box. The trade-off is that we'll have to live with substantially reduced battery life.