I am running Arch Linux on a Raspberry and need to get the positioning data for 4 USB mice from a C++ application, as in for each individual mouse I need to know how many pixels it has moved whenever it moved. I do not have x server on my system and would prefer to leave it that way unless necessary because this is for an embedded project that does not require a GUI and I would prefer not waste space or overhead on x server.
The most useful thing I have found is this link https://www.kernel.org/doc/Documentation/input/input.txt but I cannot really figure out how to make it work for my purpose. As can obviously be determined I am NOT experienced in Linux development do don't be to hard on me please.
You open e.g. /dev/input/mouse0 for reading (using open), then read the structure defined in the document you linked (at the bottom of the document), it also says which header file to include.
I'm guessing you will get an event of type EV_REL for mouse-movement, with a code of REL_X or REL_Y for the direction of the movement, and the value is the number of units the mouse moved. Compare the timestamp to the timestamp of the previous event to see how fast it moves.
Related
I want a graphical application for Linux that displays the contents of CD/DVD/blu-ray drives and allows play or eject, and I'd like the solution to be general, so that I can donate it to Linux Mint, that is any drive type and any number of drives. In my system I have three dvd drives and a blu-ray drive.
I'd like to write it in bash using the dialog functions inside a terminal window but I need to have the dialog displayed in perpitude therefore, I need an interrupt to signal when the drive is opened or closed - what signal could I trap? Also, how can I include logic to select a program to play the media depending on the media type.
Also, should I consider writing it in java, python, C++, or other language and if so how to get hardware information (such as the number and capability of drives, and the type and title of optical media in drive)?
Ignoring the side of "I want to donate this to Linux Mint", which I believe is a bit pretentious, there is a eject utility in Linux.
The source code of that can be found here:
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/sys-utils/eject.c
In that code, there is also code to sense if the drive is open, closed, has no disk, etc.
To do CD or DVD playback is a whole other kettle of fish. To write a audio-player is not entirely trivial (even in the simple case of a straightforward PCM encoding, obviously MP3 is a fair bit more complex again), and a video-player is a lot more than that.
To "select a program", you'd have to know what the available players may be called, and, if you want to be fancy, check which ones are actually installed. I'm not aware of any really clever way of achieving that, beyond having a list of players in your code (which needs to be updated). In fact, I know that is how the photo viewer geeqie works when you want to edit a shot: it has a list of "known editors", and it scans the PATH to find which ones are available.
There is osgGA::GUIEventAdapter in OpenSceneGraph that could detect mouse events. However, I want the program to detect two mice on the same computer and the program can only treat two mice as one. I know there is a Windows MultiPoint Mouse SDK, but I think it is used in WPF with C#, not sure if it could be used in C++
Also, there is a GlovePie, but it is not open source and not sure how to use that in vs2010.
VRPN may be a good choice, but do not know exactly how to implement two mice. Get the dll files of two mice and extract functions by vrpn?
Take a look at "Raw Input" (http://msdn.microsoft.com/en-us/library/windows/desktop/ms645543(v=vs.85).aspx)
From that page:
An application can distinguish the source of the input even if it is from the same type of device. For example, two mouse devices.
This is the context: I am running Debian GNU/Linux and I switch reguarly with desktop environments ("DE" for the next).
My question is simple : I want to know which operation, syscalls or even functions used when I press the keyboard key "Print Screen".
Does the way changes with DE? I.e. do Mate, Gnome, KDE, LXDE or Xfce (etc) used a particular call of their own code or is there a generic syscall?
I think the answer (if any) is not Debian relative but more X or Wayland, is not it?
Thank you in advance for you advices and answers :)
PS: I precise that I read a good part of X lib source code, but did not find something useful.
Print screen itself is definitely not a syscall, but the kernel daemon which gets key presses definitely causes a routine to execute that uses what you would call a "syscall." I put that in quotes, because printscreen probably causes a program to run which is already in kernel space, which means there won't be any system calls to the kernel since you're already there (unless the window manager actually runs at user space, which isn't true for Mac OSX or windows, and I'm assuming for linux as well).
How does it work? It probably works by copying the current display from the screen buffer (region of ram which is DMA'd to your graphics card), and then transforming the pixel representation into a bit map.
The basic principle can be found in the xwd tool.
The code isn't that bad to read. In the simple scenario, it used XGetImage, but if the screen has multiple visual regions, it gets more complex, but the fundamental principle is to use XGetPixel to get screen pixels and XPutPixel to store in the temporary image.
What happens when you press PrtScrn is the same thing, except it may be some other application that starts. Exactly what application depends on what the graphics package is in the distribution (Gnome, KDE, Unity, etc). But internally, they will do something very similar.
Edit:
As Peter points out, if the windowing system is "compositing" (that is, each window draws its own content off-screen, and the graphics hardware combines the output via composition), then the screen capture is required to ask the composition system to render the output off-screen, and then copy that.
i'd like to make a function that can move a window in Linux in C++ by its PID. So I've tryed in under Windows. But I have trouble to compile it for Linux.
Is there any mean to do it with Qt ? Since I haven't found one, I've tryed to compile for Linux.
I'm using the MoveWindow function, which is part of the Windows API. Is there any Linux equivalent ?
You don't have to do that by hand if you don't really want to as there already are lots of tools out there, that can perform such tasks as moving, resizing, maximizing and whatever windows.
One tool you might want to take a closer look upon goes by the name of wmctrl even if you don't intend to use maybe you'll find some interesting tricks by taking a look into the sources.
The task of moving a window only known by the pid of the client that created the window might not be the easiest tasks of all for a couple of reasons.
First of all you really shouldn't try to do this as in the X Windows philosophy it is the job of the window manager to arrange the windows on the screen.
As well ICCCM (see: http://de.wikipedia.org/wiki/Inter-Client_Communication_Conventions_Manual) as the EWM spec (see: http://standards.freedesktop.org/wm-spec/wm-spec-latest.html) strongly discourage any client from trying to move resize or whatever on its own. Most probably moving windows "owned" by another client might be considered even bigger evil.
The second problem you might face is, that the X 11 protocol doesn't have any notion of pid.
As it was designed to be used over a network you never can't be really sure the program runs on the same machine as the one you are currently sitting in front of. As such there isn't much sense in something like a pid as by chance there might be any number of clients with identical pids displaying windows on the same X Server if they ran on different machines.
Fortunately enough it is not all that bad, as the EWMH spec encourages any client to set the _NET_WM_PID property on its top level window the the pid of the client that created the window.
Again adhering to the EWMH spec isn't enforced by the X Server in any way so that while practically propably almost all clients will set it there's still no guarantee you'll find the window belonging to a specific pid.
Possibilities
While the whole points mentioned until here might seem rather limiting in fact most probably rather the opposite is true. Even because practically it is relatively easy to totally mess up any other client running in an X session the whole set of rules about how to be a good citizen in the X word were introduced.
As the X11 protocol itself is a network protocol (well not 100% true as locally running clients most probably will be communicating with the X Server via a UNIX domain socket) there isn't any specific library required to talk to the X Server.
Talking about C as mentioned in your question the Xlib has long been the one and only one implementation in wide use but there's also another binding called xcb. With a slightly changed API in comparison to the Xlib.
Xlib
Speaking Xlib I've never ever used any xcb until now, so I can't tell you too much about it might be the following methods that might be of use.
XOpenDisplay - open connection to the X server
XQueryTree - aquire the tree of windows currently alive on the server
XInternAtom - no fear it isn't dangerous. Just read about it in the manuals as you'll need it the get the "atom" mapping to _NET_WM_PID mentioned above
XListProperties - search for the _NET_WM_PID property with the value you are looking for
XConfigureWindow, XMoveWindow, XResizeWindow, ... - to finally perform whatever you wish to do.
All functions mentioned above should be documented in the manual pages. Just use man XOpenDisplay for example.
Oh, and be sure to learn about all the other tools at your disposal to further investigate about the X Window world. Run xlsatoms, check what xwininfo reports an take a list at the output of xprop for one single (!) window alone. Try to set some yourself to see what happens xprop will even do that for you if you ask politely.
I am trying to fix an Audacity bug that revolves around portmixer. The output/input level is settable using the mac version of portmixer, but not always in windows. I am debugging portmixer's window code to try to make it work there.
Using IAudioEndpointVolume::SetMasterVolumeLevelScalar to set the master volume works fine for onboard sound, but using pro external USB or firewire interfaces like the RME Fireface 400, the output volume won't change, although it is reflected in Window's sound control panel for that device, and also in the system mixer.
Also, outside of our program, changing the master slider for the system mixer (in the taskbar) there is no effect - the soundcard outputs the same (full) level regardless of the level the system says it is at. The only way to change the output level is using the custom app that the hardware developers give with the card.
The IAudioEndpointVolume::QueryHardwareSupport function gives back ENDPOINT_HARDWARE_SUPPORT_VOLUME so it should be able to do this.
This behavior exists for both input and output on many devices.
Is this possibly a Window's bug?
It is possible to workaround this by emulating (scaling) the output, but this is not preferred as it is not functionally identical - better to let the audio interface do the scaling (esp. for input if it involves a preamp).
The cards you talk about -like the RME- ones simply do not support setting the master or any other level through software, and there is not much you can do about it. This is not a Windows bug. One could argue that giving back ENDPOINT_HARDWARE_SUPPORT_VOLUME is a bug though, but that likely originates from the driver level, not Windows itself.
The only solution I found so far is hooking up a debugger (or adding a dll hook) to the vendor supplied software and looking at the DeviceIOControl calls it makes (those are the ones used to talk to the hardware) while setting the volume in the vendor software. Pretty hard to do this for every single card, but probably worth doing for a couple of pro cards. Especially for Audacity, for open source audio software it's actually not that bad so I can imagine some people being really happy if the volume on their card could be set by it. (at the time we were exclusively using an RME Multiface I spent quite some time in figuring out the DeviceIOControl calls, but in the end it was definitely worth it as I could set the volume in dB for any point in the matrix)