jiandingzhe
Posts: 39
Joined: Wed Jun 07, 2017 6:00 am

nothing can be drawed in KMS DRM mode using OpenGL

Sat Apr 22, 2023 2:47 am

I asked this question in stackoverflow. It seems the official forum is more specific and has more activation, so I ask it here again.

My environment is:
- Pi 3B running 32-bit Raspbian bullseye, with newest update.
- To make things clear, I uninstalled desktop environment.
- /boot/config.txt related lines:

Code: Select all

# camera related config
camera_auto_detect=1
dtoverlay=imx290,clock-frequency=37125000
# display related
display_auto_detect=1
dtoverlay=vc4-kms-v3d,composite
max_framebuffers=2
gpu_mem=256
The program is simple: create an SDL window using KMSDRM driver, repeatedly draw grey using glClear:

Code: Select all

#include <SDL.h>

#include <cstring>
#include <iostream>
#include <thread>

#include <SDL_opengles2.h>

using namespace std::chrono_literals;
using std::clog;
using std::endl;

int main()
{
    auto init_re = SDL_VideoInit("KMSDRM");
    if (init_re != 0)
        exit(EXIT_FAILURE);

    SDL_Window *window = SDL_CreateWindow("SDL2", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 640, 480,
                                          SDL_WINDOW_SHOWN | SDL_WINDOW_OPENGL);
    if (nullptr == window)
    {
        std::cerr << "SDL_CreateWindow(): " << SDL_GetError() << '\n';
        exit(EXIT_FAILURE);
    }

    auto gl = SDL_GL_CreateContext(window);
    clog << "create OpenGL context " << gl << endl;
    auto make_current_re = SDL_GL_MakeCurrent(window, gl);
    clog << "make current ctx returned " << make_current_re << endl;

    glClearColor(0.5, 0.5, 0.5, 1.0);
    size_t frame_count = 0;
    while (true)
    {
        frame_count += 1;
        glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT);
        clog << "frame " << frame_count << endl;
        std::this_thread::sleep_for(2ms);
    }

    SDL_GL_DeleteContext(gl);
    SDL_DestroyWindow(window);
    SDL_Quit();
}
The program creates window and context objects with no error, and the frame count logs are shown. However, it does not draw 640x480 piece of grey, only showing a mouse arrow-like stuff on top left corner (and the mouse pointer does not move with my connected mouse).

In addition, after this program is run and killed (either called with monitor, keyboard connected to pi in a local session , or called from a remote SSH session), the keyboard directly connected to the Pi does not respond to my input, and I have to take any further input actions from a remote SSH session.

Anonymous

Re: nothing can be drawed in KMS DRM mode using OpenGL

Sun Apr 23, 2023 8:58 am

To double check KMS is working, have you tried kmscube? Uninstalling the DE might take some critical components and kmscube is a good baseline.

jiandingzhe
Posts: 39
Joined: Wed Jun 07, 2017 6:00 am

Re: nothing can be drawed in KMS DRM mode using OpenGL

Sun Apr 23, 2023 12:39 pm

Daniel Gessel wrote:
Sun Apr 23, 2023 8:58 am
To double check KMS is working, have you tried kmscube? Uninstalling the DE might take some critical components and kmscube is a good baseline.
I tried kmscube and it works fine. So I guess it's something not good with SDL2 and I should try EGL instead?

If I use EGL, there would be no SDL input system. How could I got mouse/keyboard/touch inputs without X?

Anonymous

Re: nothing can be drawed in KMS DRM mode using OpenGL

Sun Apr 23, 2023 2:12 pm

jiandingzhe wrote:
Sun Apr 23, 2023 12:39 pm
Daniel Gessel wrote:
Sun Apr 23, 2023 8:58 am
To double check KMS is working, have you tried kmscube? Uninstalling the DE might take some critical components and kmscube is a good baseline.
I tried kmscube and it works fine. So I guess it's something not good with SDL2 and I should try EGL instead?

If I use EGL, there would be no SDL input system. How could I got mouse/keyboard/touch inputs without X?
I’m planning to use libinput, the libraries designed for wayland compositors, but if there's something lower level, just as stable, and a reasonable abstraction, I'll use it (udev?). https://wayland.freedesktop.org/libinput/doc/latest/ for docs, or https://gitlab.freedesktop.org/libinput/libinput for source. Based on what I've read (I haven't dived in deep yet) it's not super easy to use, so I wouldn’t give up on SDL just yet, though. I'm bypassing it but that's because I want to poke around the lower levels - it's not the wisest path, I admit, just where my curiosity leads.

Hopefully somebody who uses SDL on the Pi will jump in (it might even be worth changing the subject line to include SDL, since it seems like KMS itself is working)..

Is 640x480 the resolution kmscube runs at? Is it the native resolution of your display? Sometimes, despite a mode being listed, it won’t work properly.

Since SDL goes fairly low level, killing while running that inner loop might leave the system in an unusable state. I use signal to catch events (that I can; kill -9 is unstoppable, but I get control-C and plain kill) and then exit cleanly. In fact, kmscube doesn’t restore the display for me: the first enhancement in my own kms code was to save and restore the display mode so it exits back to a functioning console.

jiandingzhe
Posts: 39
Joined: Wed Jun 07, 2017 6:00 am

Re: nothing can be drawed in KMS DRM mode using OpenGL

Tue Apr 25, 2023 12:15 pm

Daniel Gessel wrote:
Sun Apr 23, 2023 2:12 pm
I’m planning to use libinput, the libraries designed for wayland compositors, but if there's something lower level, just as stable, and a reasonable abstraction, I'll use it (udev?). https://wayland.freedesktop.org/libinput/doc/latest/ for docs, or https://gitlab.freedesktop.org/libinput/libinput for source. Based on what I've read (I haven't dived in deep yet) it's not super easy to use, so I wouldn’t give up on SDL just yet, though. I'm bypassing it but that's because I want to poke around the lower levels - it's not the wisest path, I admit, just where my curiosity leads.

Hopefully somebody who uses SDL on the Pi will jump in (it might even be worth changing the subject line to include SDL, since it seems like KMS itself is working)..

Is 640x480 the resolution kmscube runs at? Is it the native resolution of your display? Sometimes, despite a mode being listed, it won’t work properly.

Since SDL goes fairly low level, killing while running that inner loop might leave the system in an unusable state. I use signal to catch events (that I can; kill -9 is unstoppable, but I get control-C and plain kill) and then exit cleanly. In fact, kmscube doesn’t restore the display for me: the first enhancement in my own kms code was to save and restore the display mode so it exits back to a functioning console.
For the input issue, I added SDL poll event in render cycle and handle exit nicely, and the world now won't stuck. However the mouse cursor is still fixed on top left corner of screen.

The kmscube actually runs at 1920x1080. I tried to create SDL window in that size, won't render either.

In addition, after OpenGL context creation, I printed OpenGL versions by glGetString, it gives me OpenGL ES 2.0 Mesa 20.3.5 and GLSL OpenGL ES GLSL ES 1.0.16, so it seems I've really got a valid context, but incorrect window.

Vraz
Posts: 42
Joined: Wed Apr 20, 2022 8:34 pm

Re: nothing can be drawed in KMS DRM mode using OpenGL

Tue Apr 25, 2023 1:14 pm

Daniel Gessel wrote: I’m planning to use libinput, the libraries designed for wayland compositors, but if there's something lower level, just as stable, and a reasonable abstraction, I'll use it
You can open/read /dev/input/event* directly to sample the keyboard, mouse, etc. The user must be a member of group input (user pi is by default). I open event devices O_RDONLY|O_NONBLOCK and poll them after rendering each frame. The event records are fixed size and defined as struct input_event in linux/input.h:

Code: Select all

      struct input_event {
        struct timeval time;
        __u16 type;
        __u16 code;
        __s32 value;
      };
(Note that structure size differs on 32/64 bit kernels due to struct timeval.) The actual event codes are defined in linux/input-event-codes.h. Best of luck.

Anonymous

Re: nothing can be drawed in KMS DRM mode using OpenGL

Tue Apr 25, 2023 2:49 pm

Vraz wrote:
Tue Apr 25, 2023 1:14 pm
You can open/read /dev/input/event* directly to sample the keyboard, mouse, etc.
Hey, thanks! That should be pretty straightforward.

Unfortunately, this sounds like an SDL issue, either some missing setup in your code, or a bug in SDL or lower level systems. Unfortunate, because I’m clueless. :(

The usual suspects, such as trying other SDL clients, trying on another computer or a different version of SDL.

If there’s no other help, I can try to repro - it wouldn’t be a terrible thing for me to learn a bit about SDL… even if I have my own KMS/Wayland code, it’s good to have options.

jiandingzhe
Posts: 39
Joined: Wed Jun 07, 2017 6:00 am

Re: nothing can be drawed in KMS DRM mode using OpenGL

Wed Apr 26, 2023 1:50 am

Daniel Gessel wrote:
Tue Apr 25, 2023 2:49 pm
Vraz wrote:
Tue Apr 25, 2023 1:14 pm
You can open/read /dev/input/event* directly to sample the keyboard, mouse, etc.
Hey, thanks! That should be pretty straightforward.

Unfortunately, this sounds like an SDL issue, either some missing setup in your code, or a bug in SDL or lower level systems. Unfortunate, because I’m clueless. :(

The usual suspects, such as trying other SDL clients, trying on another computer or a different version of SDL.

If there’s no other help, I can try to repro - it wouldn’t be a terrible thing for me to learn a bit about SDL… even if I have my own KMS/Wayland code, it’s good to have options.
I'll try to use EGL with KMS for graphics. There are several example projects in github that use EGL and KMS to draw OpenGL things, the startup code is much more complex than you start a SDL, with many KMS calls.

Anonymous

Re: nothing can be drawed in KMS DRM mode using OpenGL

Wed Apr 26, 2023 2:06 am

jiandingzhe wrote:
Wed Apr 26, 2023 1:50 am
I'll try to use EGL with KMS for graphics. There are several example projects in github that use EGL and KMS to draw OpenGL things, the startup code is much more complex than you start a SDL, with many KMS calls.
Yeah, kms is complex. I started with kmscube and it took alot of work to get something modular.

If I try SDL I’ll post what I find.

User avatar
Gavinmc42
Posts: 8024
Joined: Wed Aug 28, 2013 3:31 am

Re: nothing can be drawed in KMS DRM mode using OpenGL

Wed Apr 26, 2023 4:21 am

I found the Mesa demos are a good place to try, test various modes.
Libraries can be distracting if the basic stuff does not work.

KMScube and VKcube are basic, must have working starting points.
When those work then the OS and drivers are known as working.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

Anonymous

Re: nothing can be drawed in KMS DRM mode using OpenGL

Wed Apr 26, 2023 9:36 am

Gavinmc42 wrote:
Wed Apr 26, 2023 4:21 am
I found the Mesa demos are a good place to try, test various modes.
Libraries can be distracting if the basic stuff does not work.

KMScube and VKcube are basic, must have working starting points.
When those work then the OS and drivers are known as working.
TL/DR:

I just realized the OP may be using SDL 1? (DOH!) SDL 1 is no longer supported, so breakage should probably be expected. Google turned up this sample code on GitHub: https://github.com/xyproto/sdl2-examples which may be useful. I’m going to give it a try.

SDL can be used as a wrapper around kms/drm (SDL also does much more, of course), to make windowing-system-free GL easy. In fact, having learned a bit more about SDL, I think I’ll shelve my already back burnered baby steps into Waylandia and switch to SDL.

TL:

The Mesa demos are GLUT based (I don’t know if the latest freeglut implementation has a drm/kms mode that might be an alternative to SDL) so the Mesa demos are great for learning/testing OpenGL, but maybe not so useful for leaning drm/kms? I think kmscube is the “official” Mesa drm/kms sample, based on what I can find on the freedesktop.org GitLab instance.

While kmscube is a great resource, I’m used to a more abstraction based style (defining abstract data types or, if you prefer, a hint of an object oriented approach) so I find it a tad confusing. Other examples might be preferable (the OP is using C++, so kmscube’s C-code might not be ideal) but, as you say, it is the baseline for testing functionality, so I’m sticking to it for reference. I appreciate having an example of atomic mode setting.

On the other hand, I find libdrm to be abstraction for abstraction’s sake: when I first worked through kmscube I found bypassing libdrm was simpler and cleaner than using it. That code suffered from bit rot (and my brain rot) so I’ve been redoing it, but decided to use libdrm to isolate kernel interface changes. I still think libdrm is more complicated than using the kernel interfaces directly (though is a useful reference for understanding them), but my code is starting to work so I’m sticking with it for now. If I have an SDL “backend”, I can afford to let my own drm/kms code be more fragile, so I may go the tidier route.

YMMV, of course.

User avatar
Gavinmc42
Posts: 8024
Joined: Wed Aug 28, 2013 3:31 am

Re: nothing can be drawed in KMS DRM mode using OpenGL

Wed Apr 26, 2023 1:13 pm

I still think libdrm is more complicated than using the kernel interfaces directly
My interest is baremetal acceleration on Pi4 using Ultibo.
VC4 Pi's already work via the old ways ;)

Just noticed Mesa Demo 9.0 is out
Great now I have to learn meson building :o
"meson setup builddir" that gives me a bunch of missing stuff.

"sudo apt-get install glslang-tools" seems to have fixed it?

Er, read the readme for the correct meson commands :oops:
Compiling now.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

jiandingzhe
Posts: 39
Joined: Wed Jun 07, 2017 6:00 am

Re: nothing can be drawed in KMS DRM mode using OpenGL

Wed Apr 26, 2023 1:35 pm

Daniel Gessel wrote:
Wed Apr 26, 2023 9:36 am
TL/DR:

I just realized the OP may be using SDL 1? (DOH!) SDL 1 is no longer supported, so breakage should probably be expected. Google turned up this sample code on GitHub: https://github.com/xyproto/sdl2-examples which may be useful. I’m going to give it a try.

......
Nope, the demo code I pasted is using SDL2, installed from Raspbian's repo.

jiandingzhe
Posts: 39
Joined: Wed Jun 07, 2017 6:00 am

Re: nothing can be drawed in KMS DRM mode using OpenGL

Thu Apr 27, 2023 12:06 pm

Hi everyone!

I've just find the reason, I forget to call SDL_GL_SwapWindow(window) at the end of each frame. I'm so stupid.

Anonymous

Re: nothing can be drawed in KMS DRM mode using OpenGL

Thu Apr 27, 2023 7:10 pm

jiandingzhe wrote:
Thu Apr 27, 2023 12:06 pm
Hi everyone!

I've just find the reason, I forget to call SDL_GL_SwapWindow(window) at the end of each frame. I'm so stupid.
It happens to all of us: I messed up my OS on my main machine (laptop that use to ssh into my Pis) so I’ve been mucking with that stupidity on my part.

Thanks for posting with the solution!

ehopperdietzel
Posts: 1
Joined: Sat Sep 02, 2023 6:33 am

Re: nothing can be drawed in KMS DRM mode using OpenGL

Sat Sep 02, 2023 6:40 am

I'm a bit late to the party, but you might want to give SRM (Simple Rendering Manager) a shot. It's a C library that abstracts away all the DRM/KMS complexities, so you can focus on the OpenGL ES 2.0 part of your application. Here's a basic example:

Code: Select all

#include <SRMCore.h>
#include <SRMDevice.h>
#include <SRMListener.h>
#include <SRMCrtc.h>
#include <SRMEncoder.h>
#include <SRMPlane.h>
#include <SRMConnector.h>
#include <SRMConnectorMode.h>
#include <SRMBuffer.h>

#include <SRMList.h>
#include <SRMLog.h>

#include <GLES2/gl2.h>
#include <GLES2/gl2ext.h>

#include <math.h>
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>

float color = 0.f;

/* Opens a DRM device */
static int openRestricted(const char *path, int flags, void *userData)
{
    SRM_UNUSED(userData);

    // Here something like libseat could be used instead
    return open(path, flags);
}

/* Closes a DRM device */
static void closeRestricted(int fd, void *userData)
{
    SRM_UNUSED(userData);
    close(fd);
}

static SRMInterface srmInterface =
{
    .openRestricted = &openRestricted,
    .closeRestricted = &closeRestricted
};

static void initializeGL(SRMConnector *connector, void *userData)
{
    SRM_UNUSED(userData);

    /* You must not do any drawing here as it won't make it to
     * the screen. */

    SRMConnectorMode *mode = srmConnectorGetCurrentMode(connector);

    glViewport(0, 
               0, 
               srmConnectorModeGetWidth(mode), 
               srmConnectorModeGetHeight(mode));

    // Schedule a repaint (this eventually calls paintGL() later, not directly)
    srmConnectorRepaint(connector);
}

static void paintGL(SRMConnector *connector, void *userData)
{
    SRM_UNUSED(userData);

    glClearColor((sinf(color) + 1.f) / 2.f,
                 (sinf(color * 0.5f) + 1.f) / 2.f,
                 (sinf(color * 0.25f) + 1.f) / 2.f,
                 1.f);

    color += 0.01f;

    if (color > M_PI*4.f)
        color = 0.f;

    glClear(GL_COLOR_BUFFER_BIT);
    srmConnectorRepaint(connector);
}

static void resizeGL(SRMConnector *connector, void *userData)
{
    /* You must not do any drawing here as it won't make it to
     * the screen.
     * This is called when the connector changes its current mode,
     * set with srmConnectorSetMode() */

    // Reuse initializeGL() as it only sets the viewport
    initializeGL(connector, userData);
}

static void pageFlipped(SRMConnector *connector, void *userData)
{
    SRM_UNUSED(connector);
    SRM_UNUSED(userData);

    /* You must not do any drawing here as it won't make it to
     * the screen.
     * This is called when the last rendered frame is now being
     * displayed on screen.
     * Google v-sync for more info. */
}

static void uninitializeGL(SRMConnector *connector, void *userData)
{
    SRM_UNUSED(connector);
    SRM_UNUSED(userData);

    /* You must not do any drawing here as it won't make it to
     * the screen.
     * Here you should free any resource created on initializeGL()
     * like shaders, programs, textures, etc. */
}

static SRMConnectorInterface connectorInterface =
{
    .initializeGL = &initializeGL,
    .paintGL = &paintGL,
    .resizeGL = &resizeGL,
    .pageFlipped = &pageFlipped,
    .uninitializeGL = &uninitializeGL
};

static void connectorPluggedEventHandler(SRMListener *listener, SRMConnector *connector)
{
    SRM_UNUSED(listener);

    /* This is called when a new connector is avaliable (E.g. Plugging an HDMI display). */

    /* Got a new connector, let's render on it */
    if (!srmConnectorInitialize(connector, &connectorInterface, NULL))
        SRMError("[srm-basic] Failed to initialize connector %s.",
                 srmConnectorGetModel(connector));
}

static void connectorUnpluggedEventHandler(SRMListener *listener, SRMConnector *connector)
{
    SRM_UNUSED(listener);
    SRM_UNUSED(connector);

    /* This is called when a connector is no longer avaliable (E.g. Unplugging an HDMI display). */

    /* The connnector is automatically uninitialized after this event (if initialized)
     * so calling srmConnectorUninitialize() is a no-op. */
}

int main(void)
{
    setenv("SRM_DEBUG", "4", 1);
    setenv("SRM_EGL_DEBUG", "4", 1);

    SRMCore *core = srmCoreCreate(&srmInterface, NULL);

    if (!core)
    {
        SRMFatal("[srm-basic] Failed to initialize SRM core.");
        return 1;
    }

    // Subscribe to Udev events
    SRMListener *connectorPluggedEventListener = srmCoreAddConnectorPluggedEventListener(core, &connectorPluggedEventHandler, NULL);
    SRMListener *connectorUnpluggedEventListener = srmCoreAddConnectorUnpluggedEventListener(core, &connectorUnpluggedEventHandler, NULL);

    // Find and initialize avaliable connectors

    // Loop each GPU (device)
    SRMListForeach (deviceIt, srmCoreGetDevices(core))
    {
        SRMDevice *device = srmListItemGetData(deviceIt);

        // Loop each GPU connector (screen)
        SRMListForeach (connectorIt, srmDeviceGetConnectors(device))
        {
            SRMConnector *connector = srmListItemGetData(connectorIt);

            if (srmConnectorIsConnected(connector))
            {
                if (!srmConnectorInitialize(connector, &connectorInterface, NULL))
                    SRMError("[srm-basic] Failed to initialize connector %s.",
                             srmConnectorGetModel(connector));
            }
        }
    }

    while (1)
    {
        /* Udev monitor poll DRM devices/connectors hotplugging events (-1 disables timeout).
         * To get a pollable FD use srmCoreGetMonitorFD() */

        if (srmCoreProccessMonitor(core, -1) < 0)
            break;
    }

    /* Unsubscribe to DRM events
     *
     * These listeners are automatically destroyed when calling srmCoreDestroy()
     * so there is no need to free them manually.
     * This is here just to show how to unsubscribe to events on the fly. */

    srmListenerDestroy(connectorPluggedEventListener);
    srmListenerDestroy(connectorUnpluggedEventListener);

    // Finish SRM
    srmCoreDestroy(core);

    return 0;
}
Additionally, it offers several other features, including the handy ability for automatic texture sharing across GPUs from a single allocation.

User avatar
radiolistener
Posts: 622
Joined: Thu Aug 03, 2023 6:49 am

Re: nothing can be drawed in KMS DRM mode using OpenGL

Mon Sep 04, 2023 7:56 am

just tried to compile and run app which is posted by topic starter, when I start it from X11 desktop it just shows frame numbers in the console, nothing else. But when I tried to run it from virtual console (Ctrl+Alt+F1) it shows the same frame numbers in a loop, but it blocks keyboard completely. No way to stop app with Ctrl+C or Ctrl+C, and even no way to switch on another virtual console or to return back to X11 desktop with Ctrl+Alt+F7. It just don't responds on keyboard.

I tried to connect with SSH and kill process, then it shows prompt on the display, but keyboard still not works and don't allows to switch back to the desktop...

Is this is a kernel or driver bug?

cleverca22
Posts: 8231
Joined: Sat Aug 18, 2012 2:33 pm

Re: nothing can be drawed in KMS DRM mode using OpenGL

Mon Sep 04, 2023 3:52 pm

radiolistener wrote:
Mon Sep 04, 2023 7:56 am
I tried to connect with SSH and kill process, then it shows prompt on the display, but keyboard still not works and don't allows to switch back to the desktop...
you can run "chvt 7" to switch back to graphics, and "chvt 1" to switch to tty1

that doesnt answer what is happening, but at least lets you get back to X

User avatar
radiolistener
Posts: 622
Joined: Thu Aug 03, 2023 6:49 am

Re: nothing can be drawed in KMS DRM mode using OpenGL

Tue Sep 05, 2023 12:56 am

From SSH chvt doesn't works, from virtual terminal you will not be able to execute it, because it doesn't respond on keyboard pressing at all. You can see OS prompt, but cannot enter something, because keyboard stops to work...

The funny thing it that when you kill app from SSH, on virtual terminal you can see graphics cursor over text mode... :)

Just tested it again - the same issue. Keyboard and mouse stops to work and you cannot do something, only SSH works.

Here is steps to reproduce:
1) Install libsdl2:

Code: Select all

sudo apt install libsdl2-dev
2) Put this code into text.cpp

Code: Select all

#include <SDL.h>

#include <cstring>
#include <iostream>
#include <thread>

#include <SDL_opengles2.h>

using namespace std::chrono_literals;
using std::clog;
using std::endl;

int main()
{
    auto init_re = SDL_VideoInit("KMSDRM");
    if (init_re != 0)
        exit(EXIT_FAILURE);

    SDL_Window *window = SDL_CreateWindow("SDL2", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 640, 480,
                                          SDL_WINDOW_SHOWN | SDL_WINDOW_OPENGL);
    if (nullptr == window)
    {
        std::cerr << "SDL_CreateWindow(): " << SDL_GetError() << '\n';
        exit(EXIT_FAILURE);
    }

    auto gl = SDL_GL_CreateContext(window);
    clog << "create OpenGL context " << gl << endl;
    auto make_current_re = SDL_GL_MakeCurrent(window, gl);
    clog << "make current ctx returned " << make_current_re << endl;

    glClearColor(0.5, 0.5, 0.5, 1.0);
    size_t frame_count = 0;
    while (true)
    {
        frame_count += 1;
        glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT);
        clog << "frame " << frame_count << endl;
        std::this_thread::sleep_for(2ms);
    }

    SDL_GL_DeleteContext(gl);
    SDL_DestroyWindow(window);
    SDL_Quit();
}
3) compile it:

Code: Select all

g++ -std=c++17 -Wall -o test test.cpp -I/usr/include/SDL2 -lSDL2 -lGL
4) switch to VT1 with Ctrl+Alt+F1
5) execute ./test
6) try to stop process with keyboard
7) try to kill process with SSH and then try to enter something on VT1 or try to switch to another VT or to X.

cleverca22
Posts: 8231
Joined: Sat Aug 18, 2012 2:33 pm

Re: nothing can be drawed in KMS DRM mode using OpenGL

Tue Sep 05, 2023 1:11 am

radiolistener wrote:
Tue Sep 05, 2023 12:56 am
From SSH chvt doesn't works
why doesnt it work? what error did it give?

User avatar
radiolistener
Posts: 622
Joined: Thu Aug 03, 2023 6:49 am

Re: nothing can be drawed in KMS DRM mode using OpenGL

Wed Sep 06, 2023 2:34 pm

cleverca22 wrote:
Tue Sep 05, 2023 1:11 am
why doesnt it work? what error did it give?
it doesn't works because keyboard and mouse doesn't respond at all. No way to enter something. Only reboot can help to exit from that state.
But you can still connect to it from another machine with ssh when it remains in this state.

Tried to kill bash process for virtual terminal and it helps. The new bash instance is started and keyboard works again.

User avatar
jojopi
Posts: 3864
Joined: Tue Oct 11, 2011 8:38 pm

Re: nothing can be drawed in KMS DRM mode using OpenGL

Wed Sep 06, 2023 4:03 pm

radiolistener wrote:
Mon Sep 04, 2023 7:56 am
No way to stop app with Ctrl+C or Ctrl+C, and even no way to switch on another virtual console or to return back to X11 desktop with Ctrl+Alt+F7. It just don't responds on keyboard.
SDL is using ioctl KDSKBMODE on the console to tell the kernel to disable normal input processing. But the short test program does not handle any input events itself, so there is no way to tell it to exit.

The solution is Alt+SysRq-R (unRaw keyboard). Then you still cannot Ctrl+C, because SDL ignores SIGINT, but you can Ctrl+\ to SIGQUIT.

chvt should work over SSH, but it will need sudo.

User avatar
radiolistener
Posts: 622
Joined: Thu Aug 03, 2023 6:49 am

Re: nothing can be drawed in KMS DRM mode using OpenGL

Wed Sep 06, 2023 6:08 pm

jojopi wrote:
Wed Sep 06, 2023 4:03 pm
The solution is Alt+SysRq-R (unRaw keyboard). Then you still cannot Ctrl+C, because SDL ignores SIGINT, but you can Ctrl+\ to SIGQUIT.
Yes, it works Alt+SysRq-R and then Ctrl+\ stops the program and keyboard works :)
jojopi wrote:
Wed Sep 06, 2023 4:03 pm
chvt should work over SSH, but it will need sudo.
also works sudo chvt 7 from ssh leads to switch into desktop.

Thanks for useful info

User avatar
radiolistener
Posts: 622
Joined: Thu Aug 03, 2023 6:49 am

Re: nothing can be drawed in KMS DRM mode using OpenGL

Sun Sep 17, 2023 2:09 am

Just want to share it here. I found interesting demo project. It renders cube with DRM OpenGL, so it don't needs any compositor such as X11 or Wayland. You can run it from console. :)

Here is the link: https://gitlab.freedesktop.org/mesa/kmscube/

Return to “Graphics programming”