| Age | Commit message (Collapse) | Author |
|---|
|
Instead of limiting fb-aging to 64bit integers, allow any arbitrary
context together with a release function to free it once the FB is
destroyed.
|
|
We really want more sophisticated aging than just 64bit integers. So
always provide front *and* back buffers to renderers so they can compare
arbitrary aging information and decide whether to re-render.
|
|
Instead of looking for available back-buffers on each operation, set it to
NULL and wait for the next frame request. It will call back into the pipe
to request the back-buffer via ->target(), where we can do the same and
look for an available backbuffer.
This simplifies the code and avoids double lookups if we run short of
buffers.
|
|
Allow users to query the display dimensions of a grdev_display. This is
required to properly resize the objects to be rendered.
|
|
We used to set "pipe->tile = tile" inside of the leaf allocation. We no
longer do that. Verify that "out" is non-NULL, otherwise we'd leak memory.
This is currently always given, but make sure to add an assert(), so
coverity does not complain.
|
|
Binary operators with two pointers as arguments always operate on
object-size, not bytes. That is, "int *a, *b", (a - b) calculates the
number of integers between b and a, not the number of bytes.
Fix our cache-offset calculation to not use sizeof() with full-ptr
arithmetic.
|
|
|
|
Add "userdata" storage to a bunch of external objects, namely displays and
sessions. Furthermore, add some property retrieval helpers.
This is required if we want external API users to not duplicate our own
object hashtables, but retrieve context from the objects themselves.
|
|
Whenever we cannot use hardware frame events, we now schedule a virtual
frame event to make sure applications don't have to do this. Usually,
applications render only on data changes, but we can further reduce
render-time by also limiting rendering to vsyncs.
|
|
Whenever a display is added or changed, we suppressed any frame events.
Make sure to raise them manually so we can avoid rendering when handling
anything but FRAME events.
|
|
Whenever we get udev hotplug events, re-read the device state so we
properly detect any changed in the display setups.
|
|
If we get udev-device events via sysview, but they lack devnum
annotations, we know it cannot be a DRM card. Look through it's parents
and treat it as hotplug event in case we find such a card.
This will treat any new/removed connectors as sub-devices of the real
card, instead of as devices on its own.
|
|
The grdev-drm backend manages DRM cards for grdev. Any DRM card with
DUMB_BUFFER support can be used. So far, our policy is to configure all
available connectors, but keep pipes inactive as long as users don't
enable the displays on top.
We hard-code double-buffering so far, but can easily support
single-buffering or n-buffering. We also require XRGB8888 as format as
this is required to be supported by all DRM drivers and it is what VTs
use. This allows us to switch from VTs to grdev via page-flips instead of
deep modesets.
There is still a lot room for improvements in this backend, but it works
smoothly so far so more enhanced features can be added later.
|
|
The grdev layer provides graphics-device access via the
libsystemd-terminal library. It will be used by all terminal helpers to
actually access display hardware.
Like idev, the grdev layer is built around session objects. On each
session object you add/remove graphics devices as they appear and vanish.
Any device type can be supported via specific card-backends. The exported
grdev API hides any device details.
Graphics devices are represented by "cards". Those are hidden in the
session and any pipe-configuration is automatically applied. Out of those,
we configure displays which are then exported to the API user. Displays
are meant as lowest hardware entity available outside of grdev. The
underlying pipe configuration is fully hidden and not accessible from the
outside. The grdev tiling layer allows almost arbitrary setups out of
multiple pipes, but so far we only use a small subset of this. More will
follow.
A grdev-display is meant to represent real connected displays/monitors.
The upper level screen arrangements are user policy and not controlled by
grdev. Applications are free to apply any policy they want.
Real card-backends will follow in later patches.
|
