I'm trying to make some kind of video generator in order to test monitors. For this I'm trying to avoid any X and window manager so I'm stuck with a non GUI Linux.
I was able to write directly into the framebuffer device under Linux but I wasn't able to change the resolution at all. Fbset didn't have any effect.
With the help of a tutorial, I was able to change the resolution with DRM but only modes that my screen is telling that it is supporting.
Is there any way to disable the EDID readout at all or inject custom timings?
you can stuff whatever values you want into the drmModeModeInfo structure before initializing drm. so any custom video mode is possible.
Related
I am designing a USB keyboard with special capabilities. What information can such a HID device receive from the host?
Can I via USB:
Read data from a form on the screen?
Find out what OS the user is on?
Find out if there's been an error message?
Even 'know' what's going on visually on the screen, i.e. what program is selected or whether the program is windowed or fullscreen?
Thank you!
The device can't get any of this information from a standard driver that the operating system supplies because that would be a security issue. It can receive any information that your own driver or application sends it. There are many ways to communicate with it - your device could present multiple interfaces (which will appear as separate devices), multiple endpoints, or use the control channel. You will definitely need to study the spec, and I also found this tutorial helpful.
I have done something similar and used the control channel to exchange feature data with a Windows application (over the standard Windows driver). On Windows, the API calls are HidD_SetFeature() and HidD_GetFeature().
On the device side, my hardware ran embedded Linux and I used the GadgetFS library to create a user-mode driver - much easier to debug than a kernel driver.
As others have said, you'll run into issues if you try this with a normal HID. However, there is a project called the USB Rubber Ducky. From their description:
The USB Rubber Ducky isn't your ordinary HID (Human Interface Device).
Coupled with a powerful 60 MHz 32-bit processor and a simple scripting language
The USB Rubber Ducky looks like a usb-device and is recognized as a HID, but is programmable. You can make a small script that will be typed onto the screen which will allow you to performs the queries you seek.
With the USB Rubber Ducky you can:
Read data from a form on the screen? Yes
Find out what OS the user is on? Yes
Find out if there's been an error message? Yes
Even 'know' what's going on visually on the screen, i.e. what program is selected or whether the program is windowed or fullscreen? Yes
If you aren't hoping to buy this device, at least their firmware is on github so it can provide you a starting point
I have an embedded application which is using x11 with opengl for windowing and rendering of graphics. The device has a touch screen, which is used for application interaction. Currently, the touch screen driver is implemented in our application space and we handle the events accordingly.
However, I want that the touch events should go to the application via X11 interface.
Can anyone help me understand how this can be achieved ?
Probably the easiest way is the uinput module. This allows you to create a "virtual device" in userspace that can generate events. Those can be caught with the evdev driver by the xserver and sent to your application (o any other window).
See linux uinput: simple example?
I was wondering whether it is possible to capture audio data from other sources like the system out, FM radio, bluetooth headset, etc. I'm particularly interested in capturing audio from the FM radio and already investigated all possibilities including trying to sniff the raw bluetooth communication between the phone and the radio device with no luck. It's too bad Android only allows recording audio from the MIC.
I've looked at the Android source code and couldn't find a backdoor to allow me to do that without rooting the device. Do you, at least, have any idea how to use other devices (maybe access somehow /dev/audio) say via NDK or even better - Java (maybe Reflection?) to trick the system to capture the audio stream from say, the FM radio. (in my case I'm trying to develop the app for the HTC Desire)
PS. And for those of you who are against using undocumented APIs, please don't post here - I'm writing an app that will be for my personal use or even if I ever publish it I will warn the user of possible incompatibilities.
I've spent quite some time deciphering the audio stack, and I think you may try to hijack libaudio. You'll have trouble speaking directly to the hardware (/dev/*) because many devices use proprietary audio drivers. There's no rule in this regard.
However, the audio hardware abstraction layer (HAL) provided by /system/lib/libaudio.so should expose the API described at http://source.android.com/porting/audio.html
The Android system, and especially audioflinger, uses this libaudio HAL to find available devices, deal with routing, and of course to read/write PCM data.
So, you could hijack the interaction between audioflinger and libaudio, by renaming the later, and providing your own libaudio which decorates the real one. Doing so, you should be able to log what happens and very possibly intercept FM radio output, provided that this is not directly handled by the hardware.
Of course, all this requires rooting. Please comment if you manage to do this, that interests me.
I recently downloaded a barcode reading application for my phone, an LG KU990i (AKA the Viewty) However, there's a problem that renders the application nearly useless: the Viewty has 2 cameras -- the main one, and a secondary camera located on the face of the unit -- and it is the secondary camera that is unfortunately set as the phone's default video capture device. As you can't point the secondary at anything and see what it's pointing at at the same time, it makes it a bit difficult to snap a barcode!
According to the JSR-135 spec, it is possible to specify a video capture device other than the default... if you know the device name. This does not appear to be documented anywhere on LG's Web site, nor does the JSR-135 spec describe any way of enumerating the devices on a phone... or is there? Failing that, are there any naming conventions for video devices commonly in use that LG might be using?
I've logged a ticket with LG, but as it's an old device, I don't imagine them breaking their backs in getting back to me... I should also point out that this is purely for my own curiosity so no-one here should feel obliged to break their backs either!
As far as I know there is no way to get list of all available catpure:// urls.
All urls I know:
capture://image,
capture://video
capture://devcam0
capture://devcam1
Source:
http://www.forum.nokia.com/info/sw.nokia.com/id/bc00e4ce-7df3-4527-962c-d39843a808d0/MIDP_Mobile_Media_API_Support_In_Nokia_Devices_v1_0_en.pdf.html
LG responded to my support ticket. Apparently, it's not possible to access the primary camera on the Viewty from Java, making it pretty much useless for barcode scanning. Answer reproduced here for search engines.
You support ticket has been answered. Please visit the LG Mobile Developer Network and login to check the answer at [My Page > My Tickets].
KU990i default video capture device is the secondary camera
Answer :
Hi,
KU990i have to Two camera module
differently.
Main camera using Joran chipset and
sub(front camera) using Qualcomm
chipset.
Joran chip doesn’t supported JSR135.
Therefore, we couldn’t supported to
the JSR135 using for main camera.
(it is H/W limitation)
It was inform to operator already and
we remember operator was confirm it.
So that, we only supported sub camera
for JSR135.
BR,
I am working on project where I need to catch the image capture event.
It's for nokia N73 having platform S60 3rd edition.
Is there any possible way using J2ME only (without using symbian).
Description:
J2ME application running in background, on click of capturing image from camera J2ME application initiates and comes in front. Takes the captured image and transfers it to J2ME app and displays on screen.
if not possible using J2ME , Is there any possible way using symbian? can anyone provide tutorial or code snippet?
Thank you.
Regards,
Rajiv
Not possible to access the native camera from J2ME. You'd need to get the user to start your app first, then access the camera from your app (using JSR 135, spec here, introduction and examples here). Then you can use the captured image however you wish.
HTH
The N73 in particular has a fairly large hardware limitation when you want to use the camera.
You need to have the user manually open the camera cover before you can use the camera.
This launches the native camera application included in S60.
The user then needs to close that application.
From that point on, J2ME can use the camera, via the mobile media API defined in JSR-135.
If the user reboots the phone, the camera cover needs to be re-opened before J2ME can use the camera again.
You may have better luck using J2ME and JSR-135 to capture images using the front camera on the N73.
I seriously doubt that J2ME would see the user pressing the camera key in javax.microedition.lcdui.Canvas.keyPressed();
JSR-135 doesn't really provide a system-wide camera capture event for J2ME.