If OpenGL is not supported, we should _not_ return 0. Otherwise, there is
not convenient way to detect this scenario.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
This adds a fully working fbdev backend to the uterm library. This allows
us to create our rendering pipeline on any linux machine.
The fbdev backend is not yet hooked up into kmscon. There are still some
remaining issues as we do not have OpenGL on fbdev if EGL is not compiled
with fbdev backend (which is usually not).
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Internally, we use a new kbd API to handle keyboard related stuff in
uterm. It is a reimplementation of the old kbd_dumb.c backend.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
This is a rewrite of the input layer but integrated into uterm. It has the
same functionality but is tightly bound to the concepts behind uterm and
will soon supercede the old implementation.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
To introduce the new uterm-monitor object we need to remove all the udev
handling from uterm_video. To not break "git bisect" we now remove all the
udev code from uterm_video and uterm_video_drm and make kmscon use the
static /dev/dri/card0 interface for now.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
When triggered by seat monitor we need to be able to create uterm_video
objects on a concrete device so enable passing it in.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
We may have to use multiple GL contexts if we mix DRM and fbdev devices.
Therefore, we need explicit GL-ctx management.
We now allow to explicitely activate a specific GL context. This means,
the user needs to use the right GL context before he creates textures or
similar.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
We use GLES2 for drawing. There is currently no reason to provide full GL
inside kmscon as we use the basic operations only.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
uterm_video can work with any backend so we need a DRM backend to get the
same functionality as our previous compositor/output API.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Our old backend was hacked together and hadn't have any structure. This is
a new approach to create the uterm-library inside kmscon. The
uterm-library will contain everything that is needed to run an application
on Linux DRM devices without X11 or Wayland support.
The idea is to move the input subsystem to uterm, too. No other stuff is
currently planned to be included in uterm.
Although uterm is supposed to be a separate library, we do not build it as
such library. We currently include the log-subsystem and the
eloop-handlers in the library so we cannot build it as stand-alone
library. However, we try to keep it separate so if we ever need to export
it, then it should be a one-hour job to do it so.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
