Click events in linux using opencv - linux

I am doing a project to control mouse events by hand gestures using opencv in linux. I am able to control the mouse pointer with my hand movements.
I have achieved counting the number of fingers in the hands. I want to trigger mouse events depending upon the number of fingers shown. In windows there is a function mouse_event. But i am working in linux.
If there is any function for click events in opencv(linux) please let me know. Also help me with the header files to be included for those functions.
Thanks in advance!!

You can use Xlib library for handling mouse events in Linux environment. Xlib is an XWindow System protocol library. It contains functions for interacting with an X server. Main advantage of using Xlib in you project is that, you can handle mouse events globally( throughout the desktop, or in other window, not locally in your application window ).
Check out Xlib-MouseClick.
Just call the function mouseClick() in your program with argument -
0 - for left click,
1 - for middle click, and
2 - for right click, at current position of mouse pointer.

Related

Win 10: Any way to determine which monitor's taskbar the user clicked to launch an application?

I have a multi-monitor config that duplicates the task bar on each monitor. I also have an application with an icon in the taskbar (thus it shows on all monitors), and I'd like this application to behave differently depending on which monitor the click came from.
Is it possible to determine which monitor's taskbar was used to launch that app? I would just need the API function names (rather than actual code).
Thanks!
Whether or not what I asked in my OP is possible, I found a way to do what I want: Immediately upon launch, I obtain the current mouse position in absolute coordinates. This allows me to determine which monitor the mouse is on, which is almost certainly the monitor holding the taskbar icon used to launch the application.

Window manager for linux, supporting focusless windows

On my arm embedded device with a touchscreen, I have a 3rd party program (program A), that creates a window which handle keyboard presses. Because of that, this window always has to have focus. This is a closed source, and I do not have options to modify it.
I need to create a window in linux, that never grabs focus. It just shows an image, some times full screen. However, I have options not to make it full screen (1 pixel less, so window below is visible.).
Right now, I am using only X server, but I can install (almost) any window manager.
Is there a way to create a window in X, that never gets focus? If I understand X correctly, a window bellow mouse will get focus.
Is there a window manager, which supports such feature?
Is this possible to do with with xcb or wayland?
On Wayland, it's up to the compositor to tell the client whether it has focus or not, and which surface(s) to send key events to. So it would depend on the compositor or compositor toolkit you're using if it's possible.
KWin has an option that sounds like it does what you want. Right click the window title bar and choose more actions -> special window settings -> accept focus
Of the compositor toolkits, I only know the Qt Wayland Compositor API, and with that it should be possible (assuming your application can run as a Wayland client). The easiest thing would be to just show the image in the compositor using the QML APIs, or you could set enabled: false on the WaylandQuickItem or ShellSurfaceItem that you don't want to grab input focus.

How to make an overlay which capture no events

I would like to draw some sort of window on top of all the other windows. For example, to display some debugging infos (like conky) or things like a timer.
The main thing is that I would like to able to continue using the other windows while using it (the events go through transparently).
I've tried doing it with pygtk, pyqt and others but can't find a way to make it a real overlay with no event capture.
Is there some low-level x11 solution?
I think the Composite-extension-approach will not work when a compositing manager is running (and thus Composite's overlay window is already used).
Since you explicitly mention "no event capture":
The SHAPE extension allows to set some different shapes for a window. Version 1.1 of this extension added the "input" shape. Just setting this to an empty region should pretty much do what you want.
Some concrete example of exactly what I think you ask for can be found in Conky's source code: http://sources.debian.net/src/conky/1.10.3-1/src/x11.cc/?hl=769#L764-L781
Edit: Since you said that you didn't find anything in Gtk (well, PyGtk), here is the function that you need in Gtk: https://developer.gnome.org/gdk3/stable/gdk3-Windows.html#gdk-window-input-shape-combine-region
You might need Composite extension + GetOverlayWindow request:
Version 0.3 of the protocol adds the Composite Overlay Window, which
provides compositing managers with a surface on which to draw without
interference. This window is always above normal windows and is always
below the screen saver window. It is an InputOutput window whose width
and height are the screen dimensions. Its visual is the root visual
and its border width is zero. Attempts to redirect it using the
composite extension are ignored. This window does not appear in the
reply of the QueryTree request. It is also an override redirect
window. These last two features make it invisible to window managers
and other X11 clients. The only way to access the XID of this window
is via the CompositeGetOverlayWindow request. Initially, the Composite
Overlay Window is unmapped.
CompositeGetOverlayWindow returns the XID of the Composite Overlay
Window. If the window has not yet been mapped, it is mapped by this
request. When all clients who have called this request have terminated
their X11 connections the window is unmapped.
Composite managers may render directly to the Composite Overlay
Window, or they may reparent other windows to be children of this
window and render to these. Multiple clients may render to the
Composite Overlay Window, create child windows of it, reshape it, and
redefine its input region, but the specific arbitration rules followed
by these clients is not defined by this specification; these policies
should be defined by the clients themselves.
C api : XCompositeGetOverlayWindow
PyGTK Solution:
I think the composite and shapes X extensions are sufficiently ubiquitous and shall assume here that they are active on your system. Here's PyGtk code for this:
# avoid title bar and standard window minimize, maximize, close buttons
win.set_decorated(False)
# make the window stick above all others (super button will still override it in the z-order, which is fine)
win.set_keep_above(True)
# make events pass through
region = cairo.Region(cairo.RectangleInt(0, 0, 0, 0))
my_window.input_shape_combine_region(region)
win.show_all()
# set the entire window to be semi-transparent, if we like
win.set_opacity(0.2)
Basically what this does is tell Gtk that other than pixel (0,0) the entire window my_window should not be considered part of itself in terms of event propagation. That in turn, according to my current understanding means that when the pointer moves and clicks, the events go to the underlying window under the pointer position, as if my_window was not there.
Caveat:
This does allow your overlay window being the focus window (due to user-solicited window switching or just because it pops up and gets the focus when your application starts). Which means that for example, keyboard events will still undesirably go to it up until the user has clicked through it to make it lose focus in favor of whatever window is under the cursor. I would likely use the approach described here to iron out this aspect.
If there's a different and proper approach for making a portion of the screen "display stuff but not receive events", without building an oddball window like above over it, I'm happy to learn about it.
I assume that one's particular desktop environment (gnome, unity, etc. on linux) may interfere with this solution depending on version and configuration, on some occasions.

Propagating all events from a X window

I'a currently working on a small utility, it's my first ever X project. The utility is used to draw a small circle around your mouse pointer. I use an app called Pinpoint to do the same on my Mac, it helps me find my mouse as I'm visually impaired.
The utility creates an transparent X window and draw a circle inside, it then moves that window with the mouse pointer so that the circle follows the mouse.
It currently works, except for one detail. Mouse events are not propagated up to the underlying windows. Basically, the utility makes the mouse useless.
As far as I can tell from the Xlib docs, if not otherwise specified, new windows should propagate all events. How can I fix this?
The code can be found on GitHub: https://github.com/blubber/circle-cursor it's a bit messy currently, becaue it is just a proof of concept.
I would suggest doing via cursor image as well, there are many ways when you won't be able to receive mouse events and only possible source would be polling with XQueryPointer.
With xfixes extension you can subscribe to all cursor image changed events and get most recent shape of the cursor, and whit XRender you can set your own ( possibly animated cursor )

How can I create an X window/client that is on top of all other windows, not under WM control and has no input? (overlay, OSD)

I want to write applications (or use existing ones, that would be even more convenient) that behave like a hardware screens OSD (on screen display), only without input.
That is: A graphical output (e.g. from a GUI toolkit like Qt or Gtk) is placed on a layer where it is above even fullscreen-windows like Firefox F11 mode or a video player in fullscreen mode. That includes "above" the mouse cursor as well, so technically and graphically the mouse cursor would move below this widget.
I don't know about real fullscreen applications with SDL or OpenGL though, but this is not the requirement. If you know this as well please include it in your answer.
Real world applications are read-only overlays like a little webcam window, a TV-station like logo or premade annotations. So all in all this is meant for live presentations, streaming and recording of screencasts and tutorials with minimal post processing.
My own hacked, unsuccesful, experiments showed at least that removing this window from the WM control ( I did this by choosing a GTK popup dialog instead of a real main window) lets you position in absolute coordinates and it will ignore things like virtual desktops and workspaces, which is good, so you can switch between those and the overlay/HUD will stay in place.
Of course this cannot be done in software with the same Z-value (top/bottom windows) as the hardware screen. So technically I am talking above all other windows but below the screensaver or lock-screen layer.
+1 internet for linking to docs and giving the right keywords.
+2 internet for a working code example, language, gui-toolkit etc. doesn't matter.
You probably need composite overlay window from Composite extension - see section 3.2 "Composite Overlay Window" extension docs. (cursor is above this window)
Version 0.3 of the protocol adds the Composite Overlay Window, which
provides compositing managers with a surface on which to draw without
interference. This window is always above normal windows and is always
below the screen saver window. It is an InputOutput window whose width
and height are the screen dimensions. Its visual is the root visual
and its border width is zero. Attempts to redirect it using the
composite extension are ignored. This window does not appear in the
reply of the QueryTree request. It is also an override redirect
window. These last two features make it invisible to window managers
and other X11 clients. The only way to access the XID of this window
is via the CompositeGetOverlayWindow request. Initially, the Composite
Overlay Window is unmapped.
Example using node-x11:
var x11 = require('x11');
x11.createClient(function(err, display) {
var X = display.client;
var root = display.screen[0].root;
X.require('composite', function(err, Composite) {
Composite.GetOverlayWindow(root, function(err, overlay) {
// already automatically mapped here:
//
// CompositeGetOverlayWindow returns the XID of the Composite Overlay
// Window. If the window has not yet been mapped, it is mapped by this
// request. When all clients who have called this request have terminated
// their X11 connections the window is unmapped.
});
});
});

Resources