I have an SDL2 windowed window accessed via Derelict 3.
It is supposed to strobe black and white (not because I hate epileptics), and it does this successfully. However, after a certain period of time, Ubuntu 13.10 marks the window as 'unresponsive', grays it out, and dulls the strobe effect.
This is highly irritating and totally kills the effect required by the application for visual stimulation to retrieve SSVEP readings from my EEG headset.
How do I get my OS to realize that the window is doing exactly what it should be doing?
Code
As I have wrapped the SDL calls in my actual code, I'm going to provide pseudo-code and the SDL methods called in those sections (I've checked that I'm not calling any other SDL functions):
make a window using SDL_CreateWindow (no set flags)
make a renderer using SDL_CreateRenderer (with presentvsync flag set)
for( ... )
{
fill screen black using SDL_RenderFillRect and SDL_SetRenderDrawColor
update screen using SDL_RenderPresent
fill screen white (same as above filling)
update screen (same as above update)
}
exit
I pedantically check error codes and return values for all SDL calls in the wrapper lib. They're all fine. What I need to know is what I must add to provide the heartbeat to my OS so it stops graying out my window.
Another thing...
Could someone please add an SDL2 tag? SDL2 has a very different API from SDL1.2...
Added event processing into the loop via SDL_PollEvent(null). This satisfied the OS.
For anyone using Ubuntu 16.04 and SDL2.0x -
The solution that worked for me was:
SDL_SetHint(SDL_HINT_VIDEO_X11_NET_WM_PING,"0");
set immediately after your SDL_Init(); call.
see : SDL2 wiki here.
Related
I've got a bit of an interesting problem here. There are plenty of threads I've found where people are working to hide or get rid of a cursor on an embedded Qt GUI...but I'm trying to get a cursor to show up on an embedded Qt GUI.
I inherited a project that was 'finished' some time ago, and the person who did the most work on the project has moved on. Fast forward to today and there is a need to add a cursor to this functional touchscreen GUI. The system OS is Yocto Linux, and it is running a Qt 5.4 application on a framebuffer.
I've scoured the Qt code and there is nothing there that would hide a cursor. I've added in the appropriate QT_QPA_FB_HIDECURSOR=0 environment variable to my Qt startup script. I've experimented with adding a QCursor obejct to the GUI. Unfortunately none of these things are working. Using the QCusor I am sometimes able to get a cursor up on the screen, but isn't tied to the touch input (the cursor shows up at the position I programatically move it to, but it stays there when I interact with the GUI).
My touch input events are tied into Qt (via QT_QPA_GENERIC_PLUGINS=evdevtouch and QT_QPA_EVDEV_TOUCHSCREEN_PARAMETERS=/dev/input/event9:rotate=180), but for some reason that touch input cannot be tied to a cursor.
At this point I've spent a few days messing around with environment variables and startup script modifications, but nothing I've done has got the result I'm looking for.
Does anybody out there have some ideas on where to look for solutions to this problem?
Thanks!
Ian
So, now 3 months later I think my team and I just came up with a passable solution to this problem.
The path towards the solution started with the Qt Documentation on "Using libinput". The documentation boils down to a few important statements:
Parameters like the device node name can be set in the environment variables QT_QPA_EVDEV_MOUSE_PARAMETERS, QT_QPA_EVDEV_KEYBOARD_PARAMETERS and QT_QPA_EVDEV_TOUCHSCREEN_PARAMETERS
The mouse cursor shows up whenever QT_QPA_EGLFS_HIDECURSOR (for eglfs) or QT_QPA_FB_HIDECURSOR (for linuxfb) is not set and Qt's libudev-based device discovery reports that at least one mouse is available. When libudev support is not present, the mouse cursor always show up unless explicitly disabled via the environment variable.
The evdevtablet plugin provides basic support for Wacom and similar, pen-based tablets. It generates QTabletEvent events only. To enable it, pass QT_QPA_GENERIC_PLUGINS=evdevtablet in the environment or, alternatively, pass -plugin evdevtablet argument on the command-line. The plugin can take a device node parameter, for example QT_QPA_GENERIC_PLUGINS=evdevtablet:/dev/event1, in case the Qt's automatic device discovery (based either on libudev or a walkthrough of /dev/input/event*) is not functional or misbehaving.
So, in my system I have the device nodes: event0, event1, event2, event3, event4, event5, mice, and mouse0. Because I'm trying to get the mouse working, I made the assumption that I'd have to use the mouse0 node. This lead to me setting these environment variables:
QT_QPA_GENERIC_PLUGINS=evdevmouse
QT_QPA_EVDEV_MOUSE_PARAMETERS=/dev/input/mouse0
Much to my frustration these environment variables led to nothing. After some time my team and I figured out how to get debug output from Qt source on our system:
Modifying source code in the qtbase directory under our yocto build (roughly /yocto/poky/build/tmp/work/temp build directory/qtbase
Copying qtbase/plugins/generic/libqevdevmouseplugin.so to my hardware (roughly /usr/lib/qt5/plugins/generic)
Running Qt from the command line
We quickly discovered that the input events coming from mouse0 and mice were basically garbage data. On our system we did set up EVDEV in the kernel, so the mouse input was also tied to the device node event0. When we tried setting the Qt mouse parameter to event0 we started to see debug output that looked like real data.
QT_QPA_GENERIC_PLUGINS=evdevmouse
QT_QPA_EVDEV_MOUSE_PARAMETERS=/dev/input/event0
However, the problem of no-mouse-pointer still remained. After a while we looked back at the Qt Documentation, specifically at the 2nd paragraph listed above. As a last ditch attempt we tried adding in the QT_QPA_FB_HIDECURSOR environment variable...
QT_QPA_GENERIC_PLUGINS=evdevmouse
QT_QPA_EVDEV_MOUSE_PARAMETERS=/dev/input/event0
QT_QPA_FB_HIDECURSOR=0
And...voila! After countless hours of debugging and reading documentation, we finally got a mouse pointer.
I think the main crux of our issue was misinterpreting the Qt Documentation.
The mouse cursor shows up whenever ... QT_QPA_FB_HIDECURSOR (for linuxfb) is not set
By "not set", Qt means explicitly defined as FALSE...not simply "not set" at all.
This solution will work for us, but it does leave at least one thing to be desired. Along the way I stumbled across this thread answer on the Unix StackEx which points to the Kernel documentation of input/input.txt. In section "3.2.2 mousedev" you can see the line:
Each 'mouse' device is assigned to a single mouse or digitizer, except
the last one - 'mice'. This single character device is shared by all
mice and digitizers, and even if none are connected, the device is
present. This is useful for hotplugging USB mice, so that programs
can open the device even when no mice are present.
What this means for us is that while we can use event0 (which goes away when we unplug the mouse) for our mouse input event handling, we won't be able to support hot plugging without making some kernel/Qt-source modifications or figuring out how to get mice working as a Qt mouse input parameter.
So, the question of "why does event0 work and not mouse0/mice" still stands...but for now we've got a solution we can live with.
UPDATE: Now a little bit later we've figured out that udev was not working properly on our system. We added udev to the RDEPENDS in our package group for the Yocto build, and now we can set
QT_QPA_GENERIC_PLUGINS=evdevmouse
and we get a working mouse pointer with hotplug support.
I dont know if this applies to your problem (i dont use QT), but there is a
HAVE_TOUCHSCREEN=1 variable in the machconfig file. It is located normally in your BSP-layer in a recipes-bsp/formfactor/formfactor directory.
Setting this to 1 makes the cursor invisible.
Try setting it to 0
I am trying to program touch events in linux using Qt. My touch screen works, however when I touch the screen I get mouse events rather than touch events. The mouse cursor moves to where I touch the screen. I don't know if it is a Qt problem or something that happens at the OS level.
I am using Qt 5.4.0 on Debian Jessie.
Since you did not share any source code, its hard to know what happens wrong on your side. Take a look at this documentation:
Detailed Description of QTouchEvent Class
Touch Input Examples
All that examples works well, and you need to test it on your side. If it will not work for you, it means that there are some problems on your side, otherwise, it mean that you forgot something in your application (like Qt::WA_AcceptTouchEvents attribute set, or not set to true the acceptTouchEvents attribute at graphics items...).
I have situation that I'm calling mplayer every x minutes from xulrunner application and it always gets focus and comes on top, in front of other windows. But I need it to be behind xulrunner which has transparent box in which video should be visible.
Is there some way to force new process (mplayer) to be behind oldier process (xulrunner) and not to get autofocus on it?
Is it a Linux window manager level or there's some property in xulrunner or mplayer? (I'm using Fedora 18 with Openbox)
A solution can be achieved using devilspie. This tool allows you to customize many properties of application's windows including their focus, decoration, placement, and geometry. There is a handy frontend for it called gdevilspie, though there are no rpms available so it must be installed from source.
You can set devilsiie to match on all mplayer windows and set their action to "below" which will place them below all normal windows. Unfortunately this will apply to all invocations of mplayer, so this solution may be annoying if you use mplayer under other circumstances.
I'm working on a I/O verification tool based on Linux in a game project. It is written in C++, and,since using the same I/O module as our game, it's based on OIS 1.2. Thus, though all I need is to print users' inputs on the console, I still need to create a window for OIS.
So here comes my question: How can I create a mapped window while it is still invisible and processes keyboard events?
I can't unmapped the window in that it won't process any keyboard event anymore. I also can't find function for show/hide a window.(maybe I search through a wrong diretion...)
My little tool works fine now except there is a stupid top-level empty window which needs to be focused for processing keyboard events...
Any advise is welcomed.
Thanks!!!
After reading this post: Linux/X11 input library without creating a window,
I realized my problem was that I misunderstood the philosophy of X11. All I need to do is simply pass the root window handle to OIS, and set the x11_grabkeyboard flag as true. The only drawback is maybe I can hardly debug my program with gdb since the keyboard is grabbed...
Though my situation is solved, there is one thing left.
Every article I read said an InputOnly window won't be visible and is capable for handling input events, while my InputOnly window is absolutely visible after mapped...
Maybe it's my Linux, or again, a misunderstanding...
We've got some in-house applications built in MFC, with OpenGL drawing routines. They all use the same code to draw on the screen and either print the screen or save it to a JPEG file. Everything's been working fine in Windows XP, and I need to find a way to make them work on Vista.
In three of our applications, everything works. In the remaining one, I can get the window border, title bar, menus, and task bar, but the interior never shows up. As I said, these applications use the exact same code to write to the screen and capture the window image, and the only difference I see that looks like it might be relevant is that the problem application uses the MFC multiple document interface, while the ones that work use the single document interface.
Either the answer isn't on the net, or I'm worse at Googling than I thought. I asked on the MSDN forums, and the only practical suggestion I got was to use GDI+ rather than GDI, and that did nothing different. I have tried different things with every part of the code that captures and prints or save, given a pointer to the window, so apparently it's a matter of the window itself. I haven't rebuilt the offending application using SDI yet, and I really don't have any other ideas.
Has anybody seen anything like this?
What I've got is four applications. They use a lot of common code, and share the actual .h and .cpp files, so I know the drawing and screen capture code is identical.
There is a WindowtoDIB() routine that takes a *pWnd, and a source rectangle and destination size. It looks like very slightly adapted Microsoft code, and I've found other functions in this file on the Microsoft website. Of my four applications, three handle this just fine, but one doesn't. The most obvious difference is that the problem one is MDI.
It looks to me like the *pWnd is the problem. I'm not a MFC guru by a long shot, and it seems to me that the problem may be that we've got one window setup in the SDIs, and more than one in the MDI. I may be passing the wrong *pWnd to the function.
In the meantime, it has started working properly on the 64-bit Vista test machine, although it still doesn't work on the 32-bit Vista machine. I have no idea why. I haven't changed anything since the last tests, and I didn't think anybody else had. (On the 32-bit version, the Print Screen key works as expected, but it does not save the screen as a JPEG.)
Your question title mentions screen capture but your actual question doesn't. Please elaborate more clearly. Is the problem that you can do screen capture of three of your applications, but not the fourth one? You can use different screen capture software that can capture OpenGL/DirectX windows. Those surfaces are handled directly by the Window Manager and won't show up with a simple 'PrtScn'.
Switching to GDI+ won't solve it, nor will switching to SDI.
If it's the content of the CView that you want, then yes, that should be right one. If it's the content of the whole screen (at least the content, without the toolbar(s) and status bar), then you should pass it the CMainFrame (that's the default name which may have been changed, the one that is derived from CMDIFrameWnd).
Can you post the code of WindowToDIB()? I've just tried it and It Works For Me (TM), but without OpenGL code in the view. Try passing the following windows to your WindowToDIB() function:
CMainFrame* mainfrm = static_cast<CMainFrame*>(::AfxGetMainWnd());
- mainfrm
- mainfrm->MDIGetActive()
- mainfrm->MDIGetActive()->GetActiveView()
and see what you get.
The contents of each window are directX surfaces and are only assembled by the window manager in the graphics card. You'd not be able to capture this unless you switch off the new interface (DWM) or code specifically for screen capture from the DWM.
Wikipedia has a good description of the Desktop Window Manager (DWM)
Sorry, I still don't understand. You're trying to get the Print Screen key to work on all four applications? Or you're trying to get the WindowtoDIB() function to work, which takes a 'screenshot' (from within your own application) of the application itself, so that it can be saved as an image file?
Also, what do you mean with 'he Print Screen key works as expected, but it does not save the screen as a JPEG.'? Print Screen only copies to the clipboard, what happens when you paste in Paint?
If your WindowtoDIB() function only 'captures' the window you pass to it, then yes, your MDI child windows are not going to show up.
We eventually solved this by creating a different OpenGL context, and drawing everything to that. We gave up on the screen capture.