I am currently building a device and its driver in an embedded Android.
The device is basically an embedded Linux behaving like a touchscreen.
The device and the embedded Android are connected with UART. (I am using Lemaker Guitar eval boards). The communication is working : I receive data sent on /dev/ttyS0 (using minicom or cat /dev/ttyS0).
Now, I need to create the driver that will receive this input (it will be touches, so coordinates, the protocol is already written).
I found this resource and its lab.
We can read that :
"The driver name must be “atmel_usart” to match the device definitions in arch/arm/machat91/"
So I looked for it and found that the device (ie. the Linux embedded) has to be declared in the device tree OR in the file under a platform_device with a name matching the name of the platform_driver.
That made me question a lot about my approach to this problem.
I can read from /dev/ttyS0. But this is a just a device node, but not a device. Is it true ?
When implementing platform_device structure, we must allocate resources. Is there any way to let the system handle the resources ?
I've seen also another library that can be used but could not find any real documentation : serio. It might be a better path to resolve my issues ?
Thanks for reading. I am open to suggestions in order to solve this issue : what shape should have my driver.
Thanks again, you might be saving my internship :) :)
EDIT :
These words were not clear enough.
So I have two parts : one embedded Linux (ie. Ubuntu Mate) that will behave like a touchscreen. This will send the coordinates of the touches to an embedded Android.
The linux embedded is connected to the UART via serial link ; this communication works. Now, I want to make a driver in order to perform the touches in the Android.
Here is the block diagram :
Thanks again :)
Related
This is my first question on stackoverflow even though I'm a continuous reader of this problem-solving source.
Anyway, this is the issue I'm facing :
I'm trying to connect with a bus SPI two evalboards :
The first one (source of data) simulates a touchscreen and is a Linux distro (for now : Raspbian).
The second one is an Android embedded.
I would like to connect those two by SPI and send from the Linux one to Android the touch sequence (according to the multi-touch protocol (https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt)).
spidev is enabled, but I have no idea about how to "perform" the touches I will receive.
From what I see : I can't use Android input Devices (https://source.android.com/devices/input/input-device-configuration-files.html) because it can't rely on SPI communication.
Must I create a driver in the linux kernel then ? What is the "best practice" in this particular situation ?
Thanks in advance, you might be saving my internship :)
If your Android Linux kernel is set up to expose /dev/spidev (or you can set that up in the kernel), you do not have to create a Linux kernel module. You can access /dev/spidev from Android by writing an NDK wrapper in c/c++.
I have done that and it works. I would suggest that you start with writing a small c-program that configures and opens a /dev/spidev spi channel, and sends/receives some test data. When that works, rewrite the c-program into an NDK wrapper library you can access from an Android program.
This assumes that the Android app is one you write yourself. If you want to make the touch-events available to Android in general, I think you need to write a touch-driver as a kernel module.
Is it possible to simulate a USB or Bluetooth device connected to Android?
I would like to make an app which is able to simulate an HID device locally. What I mean by this is: the app should make Android believe that an USB/Bluetooth HID device is connected. This would allow my app to inject touch events globally, I hope. Is there anyway to simulate a (virtual) device? Note that I don't really care about the device, I just want to use the built-in support for HID input.
I know a lot of people already asked about touch event injections but this approach seems to be a little bit different. I do not want to use this for testing purpose, so InstrumentationTestCase and the like won't help.
Rooting the device might be an option, although I can also imagine to ask my endusers to install a specifically signed app manually (according to https://stackoverflow.com/a/16737083/2923406 and https://stackoverflow.com/a/22902808/2923406 this works, but it would be device specific).
I am aware of:
Simulate a mouse input on android - This guy seems to do it in his own app, although his questions wasn't answered ;)
http://www.pocketmagic.net/2013/01/programmatically-injecting-events-on-android-part-2/#.U58SqfldVHV - Needs Root. Did anyone succeeded in using this? Also, the solution seems very device-specific again.
Bluetooth + simulating mouse - That's not what I want. The phone itself should not be an HID device, but use the (virtually created) one itself. Same for this:
https://stackoverflow.com/a/8174973/2923406
Note that I do not want to turn my phone into an HID device of any kind.
Simulating is a broad term. When I created my Bluetooth app I "simulated" a Bluetooth connection in two ways.
Way 1: Use a serial port UART converter and hook it up to a Bluetooth module transmitter.
Then you can use a terminal program like CoolTerm, to send your data.
Like so. In this case I coded in a string to send on successful connection with the device however you can make a infinite loop for testing purposes effectively not requiring your phone to be turned into a HID device.
Way 2 (not easy): Use your computers bluetooth in a server/client relashionship model.
This is harder to do. What you can do is convert your pc/mac into a server and the Android phone into a client or vice-versa. For this you will need to write external code which will need to be compiled separately on a jvm(java virtual machine). The procedure to do this can be found here. If you are using a Linux machine you have to separately download the Bluez module. I have not tried this on any other operating sytem other than Ubuntu, and it was a pain to get functional.
Hopefully that helped.
Yes, it's quite easy using the AOA2 protocol check this & this links for details ( you'll need to switch your device to the Accessory mode )
This may be possible (or at least be easier) using the Robolectric library, which simulates a full Android device locally. Although it is intended primarily for testing, the fact that it simulates a whole device locally - including Bluetooth and USB - means adding to it may be an easier approach.
In other words, you may be able to modify the classes it uses to simulate these abilities locally (i.e. in the IDE itself without an emulator or device) in order to simulate them on the device itself. After all, it does provide full simulations of these functions. You could simply change these Bluetooth and USB simulating classes to load onto the device itself rather than onto the local Robolectric test "device."
This is just an idea though - I can't confirm this will work - it just might be a good place for you to start.
I'm trying to read buttons pressed on a twin USB gamepad in android.
I tried all the methods available in USB package of android including bulkTransfer, controlTransfer, requestWait. but all of them always returns the same thing while pressing the buttons. I even can't get the real name of the device.
I installed USB\BT JoyCenter and it detects the key pressed and also show the name of the gamepad connected. I really can't figure out how to read the gamepad and android documentation doesn't fully cover how to do this.
I found out where the problem is. Actually I print out the byte array directly. I think java print byte memory location instead of it's content. I used a bytes to hex converter and it works fine now.
The first thing you might want to do is plug the device into a linux box and type lsusb. You need to find out what USB Classes are supported by the USB device. Post your answer here for others to see.
Then you need to determine if Android actually supports this class directly. If it does then things should be relatively easy (so read the manual). If not, you may need to use libusb or similar to do the actual low-level interactions. This would not be an easy path, but if the USB class is supported by libusb you can get there.
Once you know the class you are working with, you may find from the standard docos that you need to turn something "on" before it will start sending the data that you are interested in.
I know that the latest versions of Android (Honeycomb and ICS) have support for joysticks and gamepads.
Guitar Hero (and Garage Band) controllers are essentially USB HID devices, right?
So my question:
Is that possible to receive data (button clicks) from the Guitar Hero (or Rock Band) controllers on Android device?
Would the Android understand it as a gamepad input?
P.S. all I need is to detect in my game the input from those five buttons on the plastic guitar fret.
A good starting point would be to review the linux source code for Frets On Fire, which supports some of the Guitar Hero controllers.
Frets on Fire: SourceForge
SVN: https://fretsonfire.svn.sourceforge.net/svnroot/fretsonfire
It looks like it would be difficult to universally support all controllers, from different platforms. Each console has it's own protocol, but it does look like JoyStick to keyboard emulation is possible on the PC with the PS3 controller. There is a config file for the PS3 controller on the second link that may be helpful, it's for JoyToKey (which isn't open source), but some of the values in the config may help you.
Hey this is a really cool idea. start here:
http://developer.android.com/guide/topics/usb/host.html
Then, check out this sample:
http://developer.android.com/resources/samples/USB/MissileLauncher/index.html
in that sample, there is a method named setDevice(UsbDevice device)
If I were implementing this, I would start with a duplicate of the MissileLauncher project, and modify this setDevice method. I would log everything I could possible find about the UsbDevice device and try experimenting with these conditionals in the setDevice method:
if (ep.getType() != UsbConstants.USB_ENDPOINT_XFER_INT) {
...
if (intf.getEndpointCount() != 1) {
While the MissileLauncher uses this type and this endpointCount, it is very likely the garageband controller will have different values
ALSO
check out the run method to see an example of back and forth communication
DISCLAIMER: I have no idea if this will work. I've also seen blogs stating this cannot be done.
My guess is it should detect data. This is even possible on existing Android devices - but it is not Android Market friendly.
To accomplish this on non-4.0 devices you must provide an alternative power source to the usb port. Usually this can be done with a cheap usb hub that leaks power. The device also must be rooted. Once this is complete you need to create an interface to the device shell to launch a native language like C outside of your Dalvik VM. Use your C to bind to the appropriate socket and you should be able to bus data back and forth. You may also need to compile a kernel module to give driver support.
Like I said this is a complete hack for device below 4.0. But it is possible.
I created an Android app that serves the touch screen sensor data to a java client that is listening on Debian Lenny machine.
The client maps this data to locations on the screen just like a wacom pad does. I would like to out put the x_loc and y_loc to a file and have the file recognized as a device.(I foggily believe this is how it is supposed to work)
I have experience with Linux but have not had to create a device before. How do I tell Linux that this file is a mouse. Do I have to create a driver?
There's many ways to do this, ranging from writing an actual device driver, over writing X clients to generate X events (using the XTest extension for example), to using kernel interfaces to inject input subsystem events.
I'd go with the last one and use the uinput subsystem. That's part of pretty much all recent kernels and provides /dev/uinput, which you can open regularly and do various ioctls on to create input devices from regular userspace.
Please also note that some mechanisms for this already exist. Bluetooth Human Interface Devices, which work just fine on Linux, are one example. rinputd, a daemon to listen to rinput clients and generating uinput events based on the data they send. is another. You might want to consider just making your Android app akt as an rinput client.
You can either write a linux device driver to interpret your data as a genuine mouse, or you can convince the X server (or whatever else) to accept input from something else, such as a named pipe.
Actual device files are not files with any content - they are merely references to a major and minor number used to talk to a driver in the kernel which can perform vaguely file-like options on some device. You create device files with mknod, but they won't work until backed by a kernel driver with matching numbers. Believe there are now some stub mechanisms so the bulk of the actual driver can run in userspace.