3

I have an OpenGL application that renders directly to the framebuffer.

If I start the application from the terminal, at times I will see a glimpse of the cursor flashing behind my application. Likewise, if I start it from inside a terminal emulator in X, I get glimpses of the mouse moving behind if I move the mouse around.

My application currently renders at 45fps so low frame rate shouldn't be the issue.

I notice when X starts it seems to clear the shell before starting to render but then when you close X server later on, the diagnostic stuff that was being sent to stdout comes back so I doubt it's issuing a clear command.

How is what I want to do accomplished? Can you simply render to fb1 and tell the video output to display from fb1 and not fight over fb0? Then when your application dies you can return the display to fb0?

EDIT:

For clarification, the app is being developed for an embedded system on an ARM SoC (Freescale i.MX6) with the Vivante GPU and running on ArchLinux ARM.

ReX357
  • 1,199
  • 3
  • 19
  • 43

1 Answers1

5

I have an OpenGL application that renders directly to the framebuffer.

Just for clarification: You're doing this using KMS + DRI/DRM + GBM right?

If I start the application from the shell, at times I will see a glimpse of the cursor flashing behind my application.

You're mixing up a few terms here. A shell is the program that provides you with a command like, job control, stdio redirection, scripting support and so on. What you probably are referring to is the Linux kernel virtual terminal console (Linux VT).

When starting a program that directly uses a framebuffer device, you have to put the virtual terminal your process uses into graphics mode (KDSETMODE).

Likewise, if I start it from inside a terminal emulator in X, I get glimpses of the mouse moving behind if I move the mouse around.

When in a started from a X11 environment the X11 server is the exclusive owner of the VT and graphics mode. All graphics operations must go through the X11 server. As far as systems design is concerned, any program trying to touch a fbdev it doesn't own should be shot in the face (immediately be sent a SIGSEGV). Don't do it. Period, no discussion. The X11 server owns the VT and while the VT is active the fbdev.

What you can do instead is allocate a own VT for your program, and let it use that. However you will then get graphical output only if the X11 server is not running and the console switched to the VT of your program.

datenwolf
  • 159,371
  • 13
  • 185
  • 298
  • I edited my original question to add context. This is being developed for an embedded system on a Freescale i.MX6 SoC (CompuLab Utilite Pro) with the Vivante GPU running ArchLinux ARM in the back. As far as I can tell KMS support is not available for the current kernel in the tree (3.0.35). The only reason X is mentioned here is because I'm developing on the system itself and I'm using a window tiler and vim :). X will not be a factor in production. – ReX357 Sep 17 '15 at 18:34
  • I think my question amounts to "How does X accomplish it?" – ReX357 Sep 17 '15 at 21:03
  • @ReX357: X.org is allocating a VT (or reusing an existing one if specified so on the command line), switches to it and uses the KDSETMODE ioctl to switch to graphics mode. I don't know that particular SoC and GPU at all (shame on me), so I'm curious about its driver model. Anyway, switching to graphics mode will give you an arena to play in without being disturbed. – datenwolf Sep 17 '15 at 21:11
  • Perfect. Thank you very much. – ReX357 Sep 17 '15 at 21:12
  • 1
    @ReX357: Just be aware, that you've to actively watch the VT state, so that if the console is switched to a different VT your program pauses graphics operations. That's what X.org does, as well. – datenwolf Sep 17 '15 at 21:41
  • Is this a concern in an embedded application where the system will boot to the application and will have no keyboard input? (Touch device) – ReX357 Sep 17 '15 at 21:42
  • @ReX357: Well, it depends. The active VT can be switched using an ioctl or the `chvt` tool (which calls that ioctl). Doing so (say, using SSH) could come in handy for debugging purposes. As for using the VT graphics mode, I suggest you also look at the source code of the Plymouth graphical boot message deamon. – datenwolf Sep 17 '15 at 23:34
  • @datenwolf for a program in C I am working on atm I am using: system("fgconsole > ...") ... in a test of the current vt each cycle before potentially writing to fb0 in case it doesn't equal the vt I want to be using (else, as you implied, I would possibly be writing all over other vt, although X seems to have solid control over its vt). As seen on different questions/answers throughout this site, fgconsole gives numeral of current vt being looked at by the user or something like that. – Jose_X May 15 '21 at 09:40