glib supports several file monitors. The used monitor can be detected by calling G_OBJECT_TYPE_NAME (monitor).
When using the gio program, there is no documented way to determine this. Or is it possible?
Related
I have 0 experience with writing drivers.
before I commit to more learning about this subject, I need to ask if my idea is possible to implement (feasible?), if it's worth it, or if there's a better way.
is there a way to get the Graphical tablet driver's input stream, decode it with standard documented Graphical tablet protocols from another driver (seen by OS as a Midi hardware device), transform it to midi output (optimally w/o losing data).
the only reason for doing all that is that Web Midi API is already supported in chrome since stable release 49, and Web USB API is still in spec drafting phase.
see Can I Use - Midi
I want to use Web Midi API to get input from my tablet coming from the Midi Driver, and transform it back to Graphical tablet input stream (coords, pressure depth, etc..), obviously to draw it on a Canvas with close experience to Native apps with access to Graphics tablet & functionality to take advantage it.
The only way to get the USB MIDI driver to attach to the device would be for the device to report itself as a MIDI device; this would require for you to modify the device's firmware. (Which is not something you can do from software on the PC, let alone a web app.)
It would be possible to write your own device driver for the tablet that converts all events into MIDI messages (and in Linux, this does not require a kernel driver but could be done with a user-space program), but this is nothing that you could do without experience.
I'm looking for a way to read the whole video memory that a video card outputs to a display. That includes also hardware accelerated output, video playback and output in fullscreen mode (that somehow I feel could be different from windowed mode).
In short: I want to be able to capture everything that is going to be represented on a display.
I suppose that IF that's possible it would be os-dependant. The targets I'm interested in are Windows OSX and Linux.
Do you have any hint?
For windows I guess you could take CamStudio, strip it down and use it to record the screen then do whatever you want with the output, other than that you could look into forensic kernel drivers for accessing RAM. It's not exactly as simple as a pointer pointing to the video memory anymore, haha.
Digital Rights Management, requested feature of Windows, attempts to block your access to blocks of graphics-card frame buffer memory. Using an open-source driver under Linux would seem to be the only way to access this memory, or as mentioned earlier, some 3rd party software that knows some back doors or hacks or ways to locate other program's frame buffer space.
Unless of course, you are trying to capture output from your own program (ie you are calling the video/graphics creation functions yourself), there are APIs to manipulate display frames in DirectX and OpenGL.
I think I found some resources that can help to capture the display memory in Windows
Fastest method of screen capturing
How to save backbuffer to file in DirectX 10?
http://betterlogic.com/roger/2010/07/fast-screen-capture/
Is it possible to detect if another process reading the memory of my application? If so, can you give me any examples on how to accomplish this? (examples in C++ would be great)
Thank You
To detect a process that opens a handle to your process and calls ReadProcessMemory you must either, hook OpenProcess & ReadProcessMemory in every process or have a kernel mode driver that intercepts these calls.
Detecting ReadProcessMemory solely from inside the target process is usermode is not possible to my knowledge. I have seen this question come up many times and have never seen an acceptable answer.
I am new to ARM and finding out ways to detect the memory map of platform based on ARM.Earlier I worked little in x86 and can find out memory map using some BIOS calls.
Same way can we do in ARM though BIOS is not there in ARM.
Is there any instruction do exist in ARM to find the Memory map ??
How do I find the memory map for an ARM CPU guide:
Read the documentation from arm.com for your coresponding core
Read the documentation of your CPU
Read the documentation of your platform, to see if it has external memory connected to SOC(CPU)
Or as a shortcut:
If your platform vendor provides a toolchain to compile code for it, make a dummy project and look for the memory layout in you linker file...
Gather this information:
Memory map for the corresponding core
Memory map of your CPU
If it has external accessible memory you have to perform some steps to initialize the controller.
Use gathered data and build the linker file for you project
Do whatever you want with it
There is no interface as ubiquitous as BIOS or EFI for ARM systems, though Microsoft does specify UEFI for systems that run Windows.
The Linux boot interface is the most common interface, see Documentation/arm/Booting in the kernel source and the header files.
If you want to write a program that to be portable across different Arm devices, you have to detect the memory by yourself. I am not very good especially in ARM, but there are common principles - you simply can scan the whole address space and probe the memory by writing a number and then reading it back. Usually, two such operations are provided with different numbers in order to exclude the occasional mistakes:
1. write 0aah
2. read and check for 0aah
3. write 055h
4. read and check for 055h
Note 1: for better speed not every byte have to be checked - some natural granularity have to be used and to check only at the start of the pages (whatever size are on this platform).
At the end you will have a map for the RAM memory. The ROM memory is not so easy to be detected, though and there is no common solution.
Note 2: Depending on the architecture (well, I said I am not ARM expert) your program must have access to the whole memory, according to the memory protection mechanisms of the CPU (if any).
Note 3: The only possible problem with this approach is the memory mapped IO. Touching it can affect the IO devices in unpredictable way. That is why, you must know what area of the addressing space is used for memory mapped IO and not to test it at all.
I'm using a rabbit microcontroller. It uses the Dyanimc C language.
How can I read from a file in my PC and manipulate it or print it to the screen?
C or C++ methods are not working here.
If you read the Rabbit manual then you can see that the file system function calls from within the Dynamic-C language refer to files that are stored on local flash devices that are connected to the processor chip.
FAT version 1.02 supports SPI-based serial flash devices. FAT versions 2.01 and 2.05 also support SPIbased
serial flash devices and require Dynamic C 9.01 or later. FAT version 2.05 introduces support for
NAND flash devices. FAT version 2.10 extends μC/OS-II compatibility to make the FAT API reentrant
from multiple tasks. FAT version 2.13 adds support for SD cards and requires Dynamic C 10.21 or later. In
all versions of the FAT, a battery-backed write-back cache reduces wear on the flash device and a roundrobin
cluster assignment helps spread the wear over its surface.
There is no way that the Rabbit can read or access a file on your pc directly. You must first provide a transfer mechanism to pass the file over from the pc to the flash storage device that you have designed into your hardware platform and use the file write function calls to store this data into the Rabbit file system. This would normally be by transferring the data over a serial link using some protocol of your choice or invention.
Next you seem to want to display some data on the screen. I assume that by this you mean the pc screen (although you could have a local screen connected to the Rabbit) Again the Rabbit has no direct method of accessing the screen. You will have to write a pc application that takes data messages from the Rabbit, possibly over the serial interface (other interfaces may be available), and interpret these as instructions to display some text or formatting on the pc screen.