Just as with MetaOutput, instead of the home baked "inheritance" system,
using a gpointer and a GDestroyNotify function to keep the what
effectively is sub type details, make MetaCrtc an abstract derivable
type, and make the implementations inherit it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
Instead of the home baked "inheritance" system, using a gpointer and a
GDestroyNotify function to keep the what effectively is sub type
details, make MetaOutput an abstract derivable type, and make the
implementations inherit it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
In order to eventually support multilpe GPUs with their own connectors,
split out related meta data management (i.e. outputs, CRTCs and CRTC
modes) into a new MetaGpu GObject.
The Xrandr backend always assumes there is always only a single "GPU" as
the GPU is abstracted by the X server; only the native backend (aside
from the test backend) will eventually see more than one GPU.
The Xrandr backend still moves some management to MetaGpuXrandr, in
order to behave more similarly to the KMS counterparts.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
This just exposes the type and the singleton getter necessary to make
it available to introspection. We'll expose more functionality as it
becomes needed.
https://bugzilla.gnome.org/show_bug.cgi?id=743745
Right now this just has all of the files in one directory. We'll
be introducing more structure to this in the future, and build
a proper backend system.
2014-03-31 22:11:00 -04:00
Renamed from src/core/meta-monitor-manager-dummy.h (Browse further)
