Equivalent to /dev/fb0 working from inside X session

[Piglou]

Hi,

I'm looking for a way to paint in a instantaneous way what is displayed on the screen.
I was initially using Qt and repaint() functions in order to perform direct changes of pictures on the screen/projector (into a loop) and snapping these pictures without stopping the working function (if not, you should stop what you are doing in order to let Qt actualize the screen).

Calling repaint() is working, but not instantly (it returns way before the change is actually done), with an "huge" late of 100 or 200ms of an acquisition speed of 66 ms with my camera (GPIO are instantly changed for the capture but the picture on the screen/projector have 2 or 3 pictures late. If I wait with sleep it's good but capture speed is several time slower ! ).

I'm running from an X session, inside a Qt GUI.

After having a look at fb0, I added my user into the video group... and then, tried to write it (successfully). But with no results on the screen (because it doesn't lasts long enough, etc, because another one succeeded by adding ioctl commands behind it...)

I spent the entire afternoon writing my framebuffer without any change on the screen, doing thousands of ioctl(...) for forcing things like FB_ACTIVATE_FORCE that freezes the entire computer or display and freeze after, copying and correcting codes that simply have no chances to do anything... since i'm running it from an X session. that explains all my problem (ctrl + alt + f1) and then I can see everything !


So, do you have a modern way to direct overwrite pixels of the screens even into an X session ? (LightDM)

Thank you in advance !

[Piglou]

I finally successfully had my Qt function working in tty1 (ctrl + alt + f1) and using the linux Frame Buffer to display what I want.
Problem : it isn't more faster ! So I'm back to the Qt "repaint" function in full screen.

But I finally found a solution for my problem !

In case somebody is looking for a solution, I launched /usb/bin/xrefresh from my Qt GUI right after "repaint();".

As soon as the process is finished, what is visible by the camera is what I wanted on the screen. It's taking everytime the same time to process so it's really good (as soon as my camera gives me a picture, I change the projection. Framerate is set just as fast/slow as necessary for the new picture to start exactly when the projection is ready ! With only 1 or 2 ms of difference at each time (checked with 1 ms exposure), and 50 ms exposure in normal conditions, the result is entirely good)

I also had to pre-load every picture in order to have it ready to display, before launching the cameras and projections : loading the PNG pictures from the disk to QPixmap, and making sure the widgets are displayed take a long time : I successfully placed outside of the critical times all that was acting as long and imprevisible (now I have setPixmap, repaint and xrefresh at each frame, nothing else ! It's fast and stable)

[Hralgmir]

cogl can write things to the screen and do so using hardware acceleration. It's intended to be a simplified interface for open GL and is written by Intel.
There are functions related to bitmaps and pixmaps, I don't know how relevant it is to your project. libcogl20 is installed as part of the Gnome desktop, but it's supposed to be a multi platform library for X11, Wayland and Windows, so I'd guess it would work with KDE and QT although it might not. There is a bit of similarity between using cogl and using GTK.
The html documentation can be found within the libcogl20 source package, there is a standard manual and an experimental manual which contains the most up to date info. The example programs in the source package are compiled when the package is compiled. 2 draw a multi coloured triangle, 2 don't work on my system due to lack of hardware support, the 3D box example segfaults gdm3 and returns my OS to the login page. Not sure what causes that. Probably different hardware could give different results. Also cairo draws things but I've not read much about using that. It sounds impressive what you are doing here, I hadn't realised framebuffers could be found in /dev although I had just been reading about them and the related cogl functions, and I was looking about for any information related to solving graphics issues on here.