Hi Harry,
It renders fine. I have attached generated doc for reference.
Regards
Pratik
-----Original Message-----
From: amd-gfx [mailto:amd-gfx-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Harry Wentland
Sent: Tuesday, March 6, 2018 3:58 AM
To: S, Shirish <Shirish.S@xxxxxxx>; Maling list - DRI developers <dri-devel@xxxxxxxxxxxxxxxxxxxxx>
Cc: Deucher, Alexander <Alexander.Deucher@xxxxxxx>; amd-gfx@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [PATCH] drm/atomic: Add new reverse iterator over all plane state (V2)
On 2018-03-01 02:56 AM, S, Shirish wrote:
> From: Shirish S <shirish.s@xxxxxxx>
>
> Add reverse iterator for_each_oldnew_plane_in_state_reverse to compliment the for_each_oldnew_plane_in_state way or reading plane states.
>
> The plane states are required to be read in reverse order for amd drivers, cause the z order convention followed in linux is opposite to how the planes are supposed to be presented to DC engine, which is in common to both windows and linux.
>
> V2: fix compile time errors due to -Werror flag.
>
> Signed-off-by: Shirish S <shirish.s@xxxxxxx>
> Signed-off-by: Pratik Vishwakarma <Pratik.Vishwakarma@xxxxxxx>
> ---
> include/drm/drm_atomic.h | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h index
> cf13842..3fe8dde 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -754,6 +754,28 @@ void drm_state_dump(struct drm_device *dev, struct drm_printer *p);
> (new_plane_state) = (__state)->planes[__i].new_state, 1))
>
> /**
> + * for_each_oldnew_plane_in_state_reverse - iterate over all planes
> +in an atomic
> + * update in reverse order
Looks good but can you check if docs build and render well with the newline in here? To build the docs run
make DOCBOOKS="" htmldocs
and then check that it renders correctly in Documentation/output/gpu/drm_kms.html
Harry
> + * @__state: &struct drm_atomic_state pointer
> + * @plane: &struct drm_plane iteration cursor
> + * @old_plane_state: &struct drm_plane_state iteration cursor for the
> +old state
> + * @new_plane_state: &struct drm_plane_state iteration cursor for the
> +new state
> + * @__i: int iteration cursor, for macro-internal use
> + *
> + * This iterates over all planes in an atomic update in reverse
> +order,
> + * tracking both old and new state. This is useful in places where
> +the
> + * state delta needs to be considered, for example in atomic check functions.
> + */
> +#define for_each_oldnew_plane_in_state_reverse(__state, plane, old_plane_state, new_plane_state, __i) \
> + for ((__i) = ((__state)->dev->mode_config.num_total_plane - 1); \
> + (__i) >= 0; \
> + (__i)--) \
> + for_each_if ((__state)->planes[__i].ptr && \
> + ((plane) = (__state)->planes[__i].ptr, \
> + (old_plane_state) = (__state)->planes[__i].old_state,\
> + (new_plane_state) = (__state)->planes[__i].new_state, 1))
> +
> +/**
> * for_each_old_plane_in_state - iterate over all planes in an atomic update
> * @__state: &struct drm_atomic_state pointer
> * @plane: &struct drm_plane iteration cursor
> --
> 2.7.4
>
_______________________________________________
amd-gfx mailing list
amd-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Title: Kernel Mode Setting (KMS) — The Linux Kernel documentation
Drivers must initialize the mode setting core by calling
drm_mode_config_init() on the DRM device. The function
initializes the structdrm_device
mode_config field and never fails. Once done, mode configuration must
be setup by initializing the following fields.
int min_width, min_height; int max_width, max_height;
Minimum and maximum width and height of the frame buffers in pixel
units.
The basic object structure KMS presents to userspace is fairly simple.
Framebuffers (represented by structdrm_framebuffer,
see Frame Buffer Abstraction) feed into planes. One or more (or even no)
planes feed their pixel data into a CRTC (represented by structdrm_crtc, see CRTC Abstraction) for blending. The precise
blending step is explained in more detail in Plane Composition Properties and
related chapters.
For the output routing the first step is encoders (represented by
structdrm_encoder, see Encoder Abstraction). Those
are really just internal artifacts of the helper libraries used to implement KMS
drivers. Besides that they make it unecessarily more complicated for userspace
to figure out which connections between a CRTC and a connector are possible, and
what kind of cloning is supported, they serve no purpose in the userspace API.
Unfortunately encoders have been exposed to userspace, hence can’t remove them
at this point. Futhermore the exposed restrictions are often wrongly set by
drivers, and in many cases not powerful enough to express the real restrictions.
A CRTC can be connected to multiple encoders, and for an active CRTC there must
be at least one encoder.
The final, and real, endpoint in the display chain is the connector (represented
by structdrm_connector, see Connector
Abstraction). Connectors can have different possible encoders, but the kernel
driver selects which encoder to use for each connector. The use case is DVI,
which could switch between an analog and a digital encoder. Encoders can also
drive multiple different connectors. There is exactly one active connector for
every active encoder.
Internally the output pipeline is a bit more complex and matches today’s
hardware more closely:
KMS Output Pipeline
Internally two additional helper objects come into play. First, to be able to
share code for encoders (sometimes on the same SoC, sometimes off-chip) one or
more Bridges (represented by structdrm_bridge) can be linked to an encoder. This link is static and cannot be
changed, which means the cross-bar (if there is any) needs to be mapped between
the CRTC and any encoders. Often for drivers with bridges there’s no code left
at the encoder level. Atomic drivers can leave out all the encoder callbacks to
essentially only leave a dummy routing object behind, which is needed for
backwards compatibility since encoders are exposed to userspace.
The second object is for panels, represented by structdrm_panel, see Panel Helper Reference. Panels do not have a fixed binding
point, but are generally linked to the driver private structure that embeds
structdrm_connector.
Note that currently the bridge chaining and interactions with connectors and
panels are still in-flux and not really fully sorted out yet.
Create a new framebuffer object. The core does basic checks on the
requested metadata, but most of that is left to the driver. See
structdrm_mode_fb_cmd2 for details.
If the parameters are deemed valid and the backing storage objects in
the underlying memory manager all exist, then the driver allocates
a new drm_framebuffer structure, subclassed to contain
driver-specific information (like the internal native buffer object
references). It also needs to fill out all relevant metadata, which
should be done by calling drm_helper_mode_fill_fb_struct().
The initialization is finalized by calling drm_framebuffer_init(),
which registers the framebuffer and makes it accessible to other
threads.
RETURNS:
A new framebuffer with an initial reference count of 1 or a negative
error code encoded with ERR_PTR().
get_format_info
Allows a driver to return custom format information for special
fb layouts (eg. ones with auxiliary compression control planes).
RETURNS:
The format information specific to the given fb metadata, or
NULL if none is found.
output_poll_changed
Callback used by helpers to inform the driver of output configuration
changes.
Drivers implementing fbdev emulation with the helpers can call
drm_fb_helper_hotplug_changed from this hook to inform the fbdev
helper of output changes.
FIXME:
Except that there’s no vtable for device-level helper callbacks
there’s no reason this is a core function.
atomic_check
This is the only hook to validate an atomic modeset update. This
function must reject any modeset and state changes which the hardware
or driver doesn’t support. This includes but is of course not limited
to:
Checking that the modes, framebuffers, scaling and placement
requirements and so on are within the limits of the hardware.
Checking that any hidden shared resources are not oversubscribed.
This can be shared PLLs, shared lanes, overall memory bandwidth,
display fifo space (where shared between planes or maybe even
CRTCs).
Checking that virtualized resources exported to userspace are not
oversubscribed. For various reasons it can make sense to expose
more planes, crtcs or encoders than which are physically there. One
example is dual-pipe operations (which generally should be hidden
from userspace if when lockstepped in hardware, exposed otherwise),
where a plane might need 1 hardware plane (if it’s just on one
pipe), 2 hardware planes (when it spans both pipes) or maybe even
shared a hardware plane with a 2nd plane (if there’s a compatible
plane requested on the area handled by the other pipe).
Check that any transitional state is possible and that if
requested, the update can indeed be done in the vblank period
without temporarily disabling some functions.
Check any other constraints the driver or hardware might have.
This callback also needs to correctly fill out the drm_crtc_state
in this update to make sure that drm_atomic_crtc_needs_modeset()
reflects the nature of the possible update and returns true if and
only if the update cannot be applied without tearing within one
vblank on that CRTC. The core uses that information to reject
updates which require a full modeset (i.e. blanking the screen, or
at least pausing updates for a substantial amount of time) if
userspace has disallowed that in its request.
The driver also does not need to repeat basic input validation
like done for the corresponding legacy entry points. The core does
that before calling this hook.
See the documentation of atomic_commit for an exhaustive list of
error conditions which don’t have to be checked at the in this
callback.
See the documentation for structdrm_atomic_state for how exactly
an atomic modeset update is described.
Drivers using the atomic helpers can implement this hook using
drm_atomic_helper_check(), or one of the exported sub-functions of
it.
RETURNS:
0 on success or one of the below negative error codes:
-EINVAL, if any of the above constraints are violated.
-ENOMEM, if allocating additional state sub-structures failed due
to lack of memory.
-EINTR, -EAGAIN or -ERESTARTSYS, if the IOCTL should be restarted.
This can either be due to a pending signal, or because the driver
needs to completely bail out to recover from an exceptional
situation like a GPU hang. From a userspace point all errors are
treated equally.
atomic_commit
This is the only hook to commit an atomic modeset update. The core
guarantees that atomic_check has been called successfully before
calling this function, and that nothing has been changed in the
interim.
See the documentation for structdrm_atomic_state for how exactly
an atomic modeset update is described.
Drivers using the atomic helpers can implement this hook using
drm_atomic_helper_commit(), or one of the exported sub-functions of
it.
Nonblocking commits (as indicated with the nonblock parameter) must
do any preparatory work which might result in an unsuccessful commit
in the context of this callback. The only exceptions are hardware
errors resulting in -EIO. But even in that case the driver must
ensure that the display pipe is at least running, to avoid
compositors crashing when pageflips don’t work. Anything else,
specifically committing the update to the hardware, should be done
without blocking the caller. For updates which do not require a
modeset this must be guaranteed.
The driver must wait for any pending rendering to the new
framebuffers to complete before executing the flip. It should also
wait for any pending rendering from other drivers if the underlying
buffer is a shared dma-buf. Nonblocking commits must not wait for
rendering in the context of this callback.
An application can request to be notified when the atomic commit has
completed. These events are per-CRTC and can be distinguished by the
CRTC index supplied in drm_event to userspace.
The drm core will supply a structdrm_event in each CRTC’s
drm_crtc_state.event. See the documentation for
drm_crtc_state.event for more details about the precise semantics of
this event.
NOTE:
Drivers are not allowed to shut down any display pipe successfully
enabled through an atomic commit on their own. Doing so can result in
compositors crashing if a page flip is suddenly rejected because the
pipe is off.
RETURNS:
0 on success or one of the below negative error codes:
-EBUSY, if a nonblocking updated is requested and there is
an earlier updated pending. Drivers are allowed to support a queue
of outstanding updates, but currently no driver supports that.
Note that drivers must wait for preceding updates to complete if a
synchronous update is requested, they are not allowed to fail the
commit in that case.
-ENOMEM, if the driver failed to allocate memory. Specifically
this can happen when trying to pin framebuffers, which must only
be done when committing the state.
-ENOSPC, as a refinement of the more generic -ENOMEM to indicate
that the driver has run out of vram, iommu space or similar GPU
address space needed for framebuffer.
-EIO, if the hardware completely died.
-EINTR, -EAGAIN or -ERESTARTSYS, if the IOCTL should be restarted.
This can either be due to a pending signal, or because the driver
needs to completely bail out to recover from an exceptional
situation like a GPU hang. From a userspace point of view all errors are
treated equally.
This list is exhaustive. Specifically this hook is not allowed to
return -EINVAL (any invalid requests should be caught in
atomic_check) or -EDEADLK (this function must not acquire
additional modeset locks).
atomic_state_alloc
This optional hook can be used by drivers that want to subclass struct
drm_atomic_state to be able to track their own driver-private global
state easily. If this hook is implemented, drivers must also
implement atomic_state_clear and atomic_state_free.
This hook must clear any driver private state duplicated into the
passed-in drm_atomic_state. This hook is called when the caller
encountered a drm_modeset_lock deadlock and needs to drop all
already acquired locks as part of the deadlock avoidance dance
implemented in drm_modeset_backoff().
Any duplicated state must be invalidated since a concurrent atomic
update might change it, and the drm atomic interfaces always apply
updates as relative changes to the current state.
This hook needs driver private resources and the drm_atomic_state
itself. Note that the core first calls drm_atomic_state_clear() to
avoid code duplicate between the clear and free hooks.
This is the big scary modeset BKL which protects everything that
isn’t protect otherwise. Scope is unclear and fuzzy, try to remove
anything from under it’s protection and move it into more well-scoped
locks.
The one important thing this protects is the use of acquire_ctx.
connection_mutex
This protects connector state and the connector to encoder to CRTC
routing chain.
Global implicit acquire context used by atomic drivers for legacy
IOCTLs. Deprecated, since implicit locking contexts make it
impossible to use driver-private structdrm_modeset_lock. Users of
this must hold mutex.
idr_mutex
Mutex for KMS ID allocation and management. Protects both crtc_idr
and tile_idr.
crtc_idr
Main KMS ID tracking object. Use this idr for all IDs, fb, crtc,
connector, modes - just makes life easier to have only one.
tile_idr
Use this idr for allocating new IDs for tiled sinks like use in some
high-res DP MST screens.
fb_lock
Mutex to protect fb the global fb_list and num_fb.
Number of encoders on this device. This is invariant over the
lifetime of a device and hence doesn’t need any locks.
encoder_list
List of encoder objects linked with drm_encoder.head. This is
invariant over the lifetime of a device and hence doesn’t need any
locks.
num_total_plane
Number of universal (i.e. with primary/curso) planes on this device.
This is invariant over the lifetime of a device and hence doesn’t
need any locks.
plane_list
List of plane objects linked with drm_plane.head. This is invariant
over the lifetime of a device and hence doesn’t need any locks.
num_crtc
Number of CRTCs on this device linked with drm_crtc.head. This is invariant over the lifetime
of a device and hence doesn’t need any locks.
crtc_list
List of CRTC objects linked with drm_crtc.head. This is invariant
over the lifetime of a device and hence doesn’t need any locks.
property_list
List of property type objects linked with drm_property.head. This is
invariant over the lifetime of a device and hence doesn’t need any
locks.
min_width
minimum pixel width on this device
min_height
minimum pixel height on this device
max_width
maximum pixel width on this device
max_height
maximum pixel height on this device
funcs
core driver provided mode setting functions
fb_base
base address of the framebuffer
poll_enabled
track polling support for this device
poll_running
track polling status for this device
delayed_event
track delayed poll uevent deliver for this device
output_poll_work
delayed work for polling in process context
blob_lock
Mutex for blob property allocation and management, protects
property_blob_list and drm_file.blobs.
property_blob_list
List of all the blob property objects linked with
drm_property_blob.head. Protected by blob_lock.
edid_property
Default connector property to hold the EDID of the
currently connected sink, if any.
dpms_property
Default connector property to control the
connector’s DPMS state.
path_property
Default connector property to hold the DP MST path
for the port.
tile_property
Default connector property to store the tile
position of a tiled screen, for sinks which need to be driven with
multiple CRTCs.
link_status_property
Default connector property for link status
of a connector
plane_type_property
Default plane property to differentiate
CURSOR, PRIMARY and OVERLAY legacy uses of planes.
prop_src_x
Default atomic plane property for the plane source
position in the connected drm_framebuffer.
prop_src_y
Default atomic plane property for the plane source
position in the connected drm_framebuffer.
prop_src_w
Default atomic plane property for the plane source
position in the connected drm_framebuffer.
prop_src_h
Default atomic plane property for the plane source
position in the connected drm_framebuffer.
prop_crtc_x
Default atomic plane property for the plane destination
position in the drm_crtc is is being shown on.
prop_crtc_y
Default atomic plane property for the plane destination
position in the drm_crtc is is being shown on.
prop_crtc_w
Default atomic plane property for the plane destination
position in the drm_crtc is is being shown on.
prop_crtc_h
Default atomic plane property for the plane destination
position in the drm_crtc is is being shown on.
prop_fb_id
Default atomic plane property to specify the
drm_framebuffer.
prop_in_fence_fd
Sync File fd representing the incoming fences
for a Plane.
prop_out_fence_ptr
Sync File fd pointer representing the
outgoing fences for a CRTC. Userspace should provide a pointer to a
value of type s32, and then cast that pointer to u64.
prop_crtc_id
Default atomic plane property to specify the
drm_crtc.
prop_active
Default atomic CRTC property to control the active
state, which is the simplified implementation for DPMS in atomic
drivers.
prop_mode_id
Default atomic CRTC property to set the mode for a
CRTC. A 0 mode implies that the CRTC is entirely disabled - all
connectors must be of and active must be set to disabled, too.
dvi_i_subconnector_property
Optional DVI-I property to
differentiate between analog or digital mode.
dvi_i_select_subconnector_property
Optional DVI-I property to
select between analog or digital mode.
tv_subconnector_property
Optional TV property to differentiate
between different TV connector types.
tv_select_subconnector_property
Optional TV property to select
between different TV connector types.
tv_mode_property
Optional TV property to select
the output TV mode.
tv_left_margin_property
Optional TV property to set the left
margin.
tv_right_margin_property
Optional TV property to set the right
margin.
tv_top_margin_property
Optional TV property to set the right
margin.
tv_bottom_margin_property
Optional TV property to set the right
margin.
tv_brightness_property
Optional TV property to set the
brightness.
tv_contrast_property
Optional TV property to set the
contrast.
tv_flicker_reduction_property
Optional TV property to control the
flicker reduction mode.
tv_overscan_property
Optional TV property to control the overscan
setting.
tv_saturation_property
Optional TV property to set the
saturation.
tv_hue_property
Optional TV property to set the hue.
scaling_mode_property
Optional connector property to control the
upscaling, mostly used for built-in panels.
aspect_ratio_property
Optional connector property to control the
HDMI infoframe aspect ratio setting.
degamma_lut_property
Optional CRTC property to set the LUT used to
convert the framebuffer’s colors to linear gamma.
degamma_lut_size_property
Optional CRTC property for the size of
the degamma LUT as supported by the driver (read-only).
ctm_property
Optional CRTC property to set the
matrix used to convert colors after the lookup in the
degamma LUT.
gamma_lut_property
Optional CRTC property to set the LUT used to
convert the colors, after the CTM matrix, to the gamma space of the
connected screen.
gamma_lut_size_property
Optional CRTC property for the size of the
gamma LUT as supported by the driver (read-only).
suggested_x_property
Optional connector property with a hint for
the position of the output on the host’s screen.
suggested_y_property
Optional connector property with a hint for
the position of the output on the host’s screen.
non_desktop_property
Optional connector property with a hint
that device isn’t a standard display, and the console/desktop,
should not be displayed on it.
panel_orientation_property
Optional connector property indicating
how the lcd-panel is mounted inside the casing (e.g. normal or
upside-down).
preferred_depth
preferred RBG pixel depth, used by fb helpers
prefer_shadow
hint to userspace to prefer shadow-fb rendering
async_page_flip
Does this device support async flips on the primary
plane?
allow_fb_modifiers
Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
modifiers_property
Plane property to list support modifier/format
combination.
Core mode resource tracking structure. All CRTC, encoders, and connectors
enumerated by the driver are added here, as are global properties. Some
global restrictions are also here, e.g. dimension restrictions.
This functions calls all the crtc’s, encoder’s and connector’s ->reset
callback. Drivers can use this in e.g. their driver load or resume code to
reset hardware and software state.
Initialize dev‘s mode_config structure, used for tracking the graphics
configuration of dev.
Since this initializes the modeset locks, no locking is possible. Which is no
problem, since this should happen single threaded at init time. It is the
driver’s problem to ensure this guarantee.
Free up all the connectors and CRTCs associated with this DRM device, then
free up the framebuffers and associated buffer objects.
Note that since this /should/ happen single-threaded at driver/device
teardown time, no locking is required. It’s the driver’s job to ensure that
this guarantee actually holds true.
FIXME: cleanup any dangling user buffer objects too
The base structure for all KMS objects is structdrm_mode_object. One of the base services it provides is tracking properties,
which are especially important for the atomic IOCTL (see Atomic Mode
Setting). The somewhat surprising part here is that properties are not
directly instantiated on each object, but free-standing mode objects themselves,
represented by structdrm_property, which only specify
the type and value range of a property. Any given property can be attached
multiple times to different objects using drm_object_attach_property().
properties attached to this object, including values
refcount
reference count for objects which with dynamic lifetime
free_cb
free function callback, only set for objects with dynamic lifetime
Description
Base structure for modeset objects visible to userspace. Objects can be
looked up using drm_mode_object_find(). Besides basic uapi interface
properties like id and type it provides two services:
NOTE: if we ever start dynamically destroying properties (ie.
not at drm_mode_config_cleanup() time), then we’d have to do
a better job of detaching property from mode objects to avoid
dangling property pointers:
This function is used to look up a modeset object. It will acquire a
reference for reference counted objects. This reference must be dropped again
by callind drm_mode_object_put().
This function decrements the object’s refcount if it is a refcounted modeset
object. It is a no-op on any other object. This is used to drop references
acquired with drm_mode_object_get().
This function increments the object’s refcount if it is a refcounted modeset
object. It is a no-op on any other object. References should be dropped again
by calling drm_mode_object_put().
This attaches the given property to the modeset object with the given initial
value. Currently this function cannot fail since the properties are stored in
a statically sized array.
This function sets a given property on a given object. This function only
changes the software state of the property, it does not call into the
driver’s ->set_property callback.
Note that atomic drivers should not have any need to call this, the core will
ensure consistency of values reported back to userspace through the
appropriate ->atomic_get_property callback. Only legacy drivers should call
this function to update the tracked value (after clamping and other
restrictions have been applied).
This function retrieves the softare state of the given property for the given
property. Since there is no driver callback to retrieve the current property
value this might be out of sync with the hardware, depending upon the driver
and property.
Atomic drivers should never call this function directly, the core will read
out property values through the various ->atomic_get_property callbacks.
Atomic provides transactional modeset (including planes) updates, but a
bit differently from the usual transactional approach of try-commit and
rollback:
Firstly, no hardware changes are allowed when the commit would fail. This
allows us to implement the DRM_MODE_ATOMIC_TEST_ONLY mode, which allows
userspace to explore whether certain configurations would work or not.
This would still allow setting and rollback of just the software state,
simplifying conversion of existing drivers. But auditing drivers for
correctness of the atomic_check code becomes really hard with that: Rolling
back changes in data structures all over the place is hard to get right.
Lastly, for backwards compatibility and to support all use-cases, atomic
updates need to be incremental and be able to execute in parallel. Hardware
doesn’t always allow it, but where possible plane updates on different CRTCs
should not interfere, and not get stalled due to output routing changing on
different CRTCs.
Taken all together there’s two consequences for the atomic design:
The overall state is split up into per-object state structures:
structdrm_plane_state for planes, structdrm_crtc_state for CRTCs and structdrm_connector_state for connectors. These are the only
objects with userspace-visible and settable state. For internal state drivers
can subclass these structures through embeddeding, or add entirely new state
structures for their globally shared hardware functions.
An atomic update is assembled and validated as an entirely free-standing pile
of structures within the drm_atomic_state
container. Driver private state structures are also tracked in the same
structure; see the next chapter. Only when a state is committed is it applied
to the driver and modeset objects. This way rolling back an update boils down
to releasing memory and unreferencing objects like framebuffers.
Very often the DRM objects exposed to userspace in the atomic modeset api
(drm_connector, drm_crtc and drm_plane) do not map neatly to the
underlying hardware. Especially for any kind of shared resources (e.g. shared
clocks, scaler units, bandwidth and fifo limits shared among a group of
planes or CRTCs, and so on) it makes sense to model these as independent
objects. Drivers then need to do similar state tracking and commit ordering for
such private (since not exposed to userpace) objects as the atomic core and
helpers already provide for connectors, planes and CRTCs.
To make this easier on drivers the atomic core provides some support to track
driver private state objects using struct drm_private_obj, with the
associated state struct drm_private_state.
Similar to userspace-exposed objects, private state structures can be
acquired by calling drm_atomic_get_private_obj_state(). Since this function
does not take care of locking, drivers should wrap it for each type of
private state object they have with the required call to drm_modeset_lock()
for the corresponding drm_modeset_lock.
An earlier way to handle driver private state was by subclassing struct
drm_atomic_state. But since that encourages non-standard ways to implement
the check/commit split atomic requires (by using e.g. “check and rollback or
commit instead” of “duplicate state, check, then either commit or release
duplicated state) it is deprecated in favour of using drm_private_state.
Reference count for this structure. Needed to allow blocking on
completions without the risk of the completion disappearing
meanwhile.
flip_done
Will be signaled when the hardware has flipped to the new set of
buffers. Signals at the same time as when the drm event for this
commit is sent to userspace, or when an out-fence is singalled. Note
that for most hardware, in most cases this happens after hw_done is
signalled.
hw_done
Will be signalled when all hw register changes for this commit have
been written out. Especially when disabling a pipe this can be much
later than than flip_done, since that can signal already when the
screen goes black, whereas to fully shut down a pipe more register
I/O is required.
Note that this does not need to include separately reference-counted
resources like backing storage buffer pinning, or runtime pm
management.
cleanup_done
Will be signalled after old buffers have been cleaned up by calling
drm_atomic_helper_cleanup_planes(). Since this can only happen after
a vblank wait completed it might be a bit later. This completion is
useful to throttle updates and avoid hardware updates getting ahead
of the buffer cleanup too much.
A flag that’s set after drm_atomic_helper_setup_commit takes a second
reference for the completion of $drm_crtc_state.event. It’s used by
the free code to remove the second reference if commit fails.
Description
This structure is used to track pending modeset changes and atomic commit on
a per-CRTC basis. Since updating the list should never block this structure
is reference counted to allow waiters to safely wait on an event to complete,
without holding any locks.
It has 3 different events in total to allow a fine-grained synchronization
between outstanding updates:
atomic commit thread hardware
write new state into hardware ----> ...
signal hw_done
switch to new state on next
... v/hblank
wait for buffers to show up ...
... send completion irq
irq handler signals flip_done
cleanup old buffers
signal cleanup_done
wait for flip_done <----
clean up atomic state
The important bit to know is that cleanup_done is the terminal event, but the
ordering between flip_done and hw_done is entirely up to the specific driver
and modeset state change.
Duplicate the current state of the private object and return it. It
is an error to call this before obj->state has been initialized.
RETURNS:
Duplicated atomic state or NULL when obj->state is not
initialized or allocation failed.
atomic_destroy_state
Frees the private object state created with atomic_duplicate_state.
Description
These hooks are used by atomic helpers to create, swap and destroy states of
private objects. The structure itself is used as a vtable to identify the
associated private object type. Each private object type that needs to be
added to the atomic states is expected to have an implementation of these
hooks and pass a pointer to it’s drm_private_state_funcs struct to
drm_atomic_get_private_obj_state().
Currently only tracks the state update functions and the opaque driver
private state itself, but in the future might also track which
drm_modeset_lock is required to duplicate and update this object’s state.
Currently only contains a backpointer to the overall atomic update, but in
the future also might hold synchronization information similar to e.g.
drm_crtc.commit.
count of all references to this state (will not be freed until zero)
dev
parent DRM device
allow_modeset
allow full modeset
legacy_cursor_update
hint to enforce legacy cursor IOCTL semantics
async_update
hint for asynchronous plane update
planes
pointer to array of structures with per-plane data
crtcs
pointer to array of CRTC pointers
num_connector
size of the connectors and connector_states arrays
connectors
pointer to array of structures with per-connector data
num_private_objs
size of the private_objs array
private_objs
pointer to array of private object pointers
acquire_ctx
acquire context for this atomic modeset state update
fake_commit
Used for signaling unbound planes/connectors.
When a connector or plane is not bound to any CRTC, it’s still important
to preserve linearity to prevent the atomic states from being freed to early.
This function returns the plane state for the given plane, either from
state, or if the plane isn’t part of the atomic state update, from plane.
This is useful in atomic check callbacks, when drivers need to peek at, but
not change, state of other planes, since it avoids threading an error code
back up the call chain.
WARNING:
Note that this function is in general unsafe since it doesn’t check for the
required locking for access state structures. Drivers must ensure that it is
safe to access the returned state structure through other means. One common
example is when planes are fixed to a single CRTC, and the driver knows that
the CRTC lock is held already. In that case holding the CRTC lock gives a
read-lock on all planes connected to that CRTC. But if planes can be
reassigned things get more tricky. In that case it’s better to use
drm_atomic_get_plane_state and wire up full error handling.
This iterates over all connectors in an atomic update, tracking both old and
new state. This is useful in places where the state delta needs to be
considered, for example in atomic check functions.
This iterates over all connectors in an atomic update, tracking only the old
state. This is useful in disable functions, where we need the old state the
hardware is still in.
This iterates over all connectors in an atomic update, tracking only the new
state. This is useful in enable functions, where we need the new state the
hardware should be in when the atomic commit operation has completed.
This iterates over all CRTCs in an atomic update, tracking both old and
new state. This is useful in places where the state delta needs to be
considered, for example in atomic check functions.
This iterates over all CRTCs in an atomic update, tracking only the old
state. This is useful in disable functions, where we need the old state the
hardware is still in.
This iterates over all CRTCs in an atomic update, tracking only the new
state. This is useful in enable functions, where we need the new state the
hardware should be in when the atomic commit operation has completed.
This iterates over all planes in an atomic update, tracking both old and
new state. This is useful in places where the state delta needs to be
considered, for example in atomic check functions.
This iterates over all planes in an atomic update in reverse order,
tracking both old and new state. This is useful in places where the
state delta needs to be considered, for example in atomic check functions.
This iterates over all planes in an atomic update, tracking only the old
state. This is useful in disable functions, where we need the old state the
hardware is still in.
This iterates over all planes in an atomic update, tracking only the new
state. This is useful in enable functions, where we need the new state the
hardware should be in when the atomic commit operation has completed.
This iterates over all private objects in an atomic update, tracking both
old and new state. This is useful in places where the state delta needs
to be considered, for example in atomic check functions.
This iterates over all private objects in an atomic update, tracking only
the old state. This is useful in disable functions, where we need the old
state the hardware is still in.
This iterates over all private objects in an atomic update, tracking only
the new state. This is useful in enable functions, where we need the new state the
hardware should be in when the atomic commit operation has completed.
To give drivers flexibility structdrm_crtc_state has 3 booleans to track
whether the state CRTC changed enough to need a full modeset cycle:
mode_changed, active_changed and connectors_changed. This helper simply
combines these three to compute the overall need for a modeset for state.
The atomic helper code sets these booleans, but drivers can and should
change them appropriately to accurately represent whether a modeset is
really needed. In general, drivers should avoid full modesets whenever
possible.
For example if the CRTC mode has changed, and the hardware is able to enact
the requested mode change without going through a full modeset, the driver
should clear mode_changed in its drm_mode_config_funcs.atomic_check
implementation.
release memory initialized by drm_atomic_state_init
Parameters
structdrm_atomic_state*state
atomic state
Description
Free all the memory allocated by drm_atomic_state_init.
This should only be used by drivers which are still subclassing
drm_atomic_state and haven’t switched to drm_private_state yet.
int drm_atomic_state_init(struct drm_device * dev, struct drm_atomic_state * state)¶
init new atomic state
Parameters
structdrm_device*dev
DRM device
structdrm_atomic_state*state
atomic state
Description
Default implementation for filling in a new atomic state.
This should only be used by drivers which are still subclassing
drm_atomic_state and haven’t switched to drm_private_state yet.
Default implementation for clearing atomic state.
This should only be used by drivers which are still subclassing
drm_atomic_state and haven’t switched to drm_private_state yet.
When the w/w mutex algorithm detects a deadlock we need to back off and drop
all locks. So someone else could sneak in and change the current modeset
configuration. Which means that all the state assembled in state is no
longer an atomic update to the current state, but to some arbitrary earlier
state. Which could break assumptions the driver’s
drm_mode_config_funcs.atomic_check likely relies on.
Hence we must clear all cached state and completely start over, using this
function.
This function returns the crtc state for the given crtc, allocating it if
needed. It will also grab the relevant crtc lock to make sure that the state
is consistent.
Return
Either the allocated state or the error code encoded into the pointer. When
the error is EDEADLK then the w/w mutex code has detected a deadlock and the
entire atomic sequence must be restarted. All other errors are fatal.
Set a mode (originating from a blob property) on the desired CRTC state.
This function will take a reference on the blob property for the CRTC state,
and release the reference held on the state’s existing mode property, if any
was set.
Return
Zero on success, error code on failure. Cannot return -EDEADLK.
the state object to update with the new property value
structdrm_property*property
the property to set
uint64_tval
the new property value
Description
This function handles generic/core properties and calls out to driver’s
drm_crtc_funcs.atomic_set_property for driver properties. To ensure
consistent behavior you must call this function rather than the driver hook
directly.
This function returns the plane state for the given plane, allocating it if
needed. It will also grab the relevant plane lock to make sure that the state
is consistent.
Return
Either the allocated state or the error code encoded into the pointer. When
the error is EDEADLK then the w/w mutex code has detected a deadlock and the
entire atomic sequence must be restarted. All other errors are fatal.
This function returns the private object state for the given private object,
allocating the state if needed. It does not grab any locks as the caller is
expected to care of any required locking.
Return
Either the allocated state or the error code encoded into a pointer.
This function returns the connector state for the given connector,
allocating it if needed. It will also grab the relevant connector lock to
make sure that the state is consistent.
Return
Either the allocated state or the error code encoded into the pointer. When
the error is EDEADLK then the w/w mutex code has detected a deadlock and the
entire atomic sequence must be restarted. All other errors are fatal.
Changing the assigned crtc for a plane requires us to grab the lock and state
for the new crtc, as needed. This function takes care of all these details
besides updating the pointer in the state object itself.
Return
0 on success or can fail with -EDEADLK or -ENOMEM. When the error is EDEADLK
then the w/w mutex code has detected a deadlock and the entire atomic
sequence must be restarted. All other errors are fatal.
Changing the assigned framebuffer for a plane requires us to grab a reference
to the new fb and drop the reference to the old fb, if there is one. This
function takes care of all these details besides updating the pointer in the
state object itself.
Helper to setup the plane_state fence in case it is not set yet.
By using this drivers doesn’t need to worry if the user choose
implicit or explicit fencing.
This function will not set the fence to the state if it was set
via explicit fencing interfaces on the atomic ioctl. In that case it will
drop the reference to the fence as we are not storing it anywhere.
Otherwise, if drm_plane_state.fence is not set this function we just set it
with the received implicit fence. In both cases this function consumes a
reference for fence.
Changing the assigned crtc for a connector requires us to grab the lock and
state for the new crtc, as needed. This function takes care of all these
details besides updating the pointer in the state object itself.
Return
0 on success or can fail with -EDEADLK or -ENOMEM. When the error is EDEADLK
then the w/w mutex code has detected a deadlock and the entire atomic
sequence must be restarted. All other errors are fatal.
This function walks the current configuration and adds all connectors
currently using crtc to the atomic configuration state. Note that this
function must acquire the connection mutex. This can potentially cause
unneeded seralization if the update is just for the planes on one crtc. Hence
drivers and helpers should only call this when really needed (e.g. when a
full modeset needs to happen due to some change).
Return
0 on success or can fail with -EDEADLK or -ENOMEM. When the error is EDEADLK
then the w/w mutex code has detected a deadlock and the entire atomic
sequence must be restarted. All other errors are fatal.
This function walks the current configuration and adds all planes
currently used by crtc to the atomic configuration state. This is useful
when an atomic commit also needs to check all currently enabled plane on
crtc, e.g. when changing the mode. It’s also useful when re-enabling a CRTC
to avoid special code to force-enable all planes.
Since acquiring a plane state will always also acquire the w/w mutex of the
current CRTC for that plane (if there is any) adding all the plane states for
a CRTC will not reduce parallism of atomic updates.
Return
0 on success or can fail with -EDEADLK or -ENOMEM. When the error is EDEADLK
then the w/w mutex code has detected a deadlock and the entire atomic
sequence must be restarted. All other errors are fatal.
Note that this function can return -EDEADLK if the driver needed to acquire
more locks but encountered a deadlock. The caller must then do the usual w/w
backoff dance and restart. All other errors are fatal.
Note that this function can return -EDEADLK if the driver needed to acquire
more locks but encountered a deadlock. The caller must then do the usual w/w
backoff dance and restart. All other errors are fatal.
This function will take its own reference on state.
Callers should always release their reference with drm_atomic_state_put().
Note that this function can return -EDEADLK if the driver needed to acquire
more locks but encountered a deadlock. The caller must then do the usual w/w
backoff dance and restart. All other errors are fatal.
This function will take its own reference on state.
Callers should always release their reference with drm_atomic_state_put().
Just for debugging. Drivers might want an option to dump state
to dmesg in case of error irq’s. (Hint, you probably want to
ratelimit this!)
The caller must drm_modeset_lock_all(), or if this is called
from error irq handler, it should not be enabled by default.
(Ie. if you are debugging errors you might not care that this
is racey. But calling this without all modeset locks held is
not inherently safe.)
void drm_atomic_clean_old_fb(struct drm_device * dev, unsigned plane_mask, int ret)¶
Unset old_fb pointers and set plane->fb pointers.
Parameters
structdrm_device*dev
drm device to check.
unsignedplane_mask
plane mask for planes that were updated.
intret
return value, can be -EDEADLK for a retry.
Description
Before doing an update drm_plane.old_fb is set to drm_plane.fb, but before
dropping the locks old_fb needs to be set to NULL and plane->fb updated. This
is a common operation for each atomic update, so this call is split off as a
helper.
A CRTC represents the overall display pipeline. It receives pixel data from
drm_plane and blends them together. The drm_display_mode is also attached
to the CRTC, specifying display timings. On the output side the data is fed
to one or more drm_encoder, which are then each connected to one
drm_connector.
To create a CRTC, a KMS drivers allocates and zeroes an instances of
structdrm_crtc (possibly as part of a larger structure) and registers it
with a call to drm_crtc_init_with_planes().
whether the CRTC should be enabled, gates all other state
active
whether the CRTC is actively displaying (used for DPMS)
planes_changed
planes on this crtc are updated
mode_changed
mode or enable has been changed
active_changed
active has been toggled.
connectors_changed
connectors to this crtc have been updated
zpos_changed
zpos values of planes on this crtc have been updated
color_mgmt_changed
color management properties have changed (degamma or
gamma LUT or CSC matrix)
plane_mask
bitmask of (1 << drm_plane_index(plane)) of attached planes
connector_mask
bitmask of (1 << drm_connector_index(connector)) of attached connectors
encoder_mask
bitmask of (1 << drm_encoder_index(encoder)) of attached encoders
adjusted_mode
Internal display timings which can be used by the driver to handle
differences between the mode requested by userspace in mode and what
is actually programmed into the hardware. It is purely driver
implementation defined what exactly this adjusted mode means. Usually
it is used to store the hardware display timings used between the
CRTC and encoder blocks.
mode
Display timings requested by userspace. The driver should try to
match the refresh rate as close as possible (but note that it’s
undefined what exactly is close enough, e.g. some of the HDMI modes
only differ in less than 1% of the refresh rate). The active width
and height as observed by userspace for positioning planes must match
exactly.
For external connectors where the sink isn’t fixed (like with a
built-in panel), this mode here should match the physical mode on the
wire to the last details (i.e. including sync polarities and
everything).
Lookup table for converting framebuffer pixel data before apply the
color conversion matrix ctm. See drm_crtc_enable_color_mgmt(). The
blob (if not NULL) is an array of structdrm_color_lut.
Lookup table for converting pixel data after the color conversion
matrix ctm. See drm_crtc_enable_color_mgmt(). The blob (if not
NULL) is an array of structdrm_color_lut.
target_vblank
Target vertical blank period when a page flip
should take effect.
pageflip_flags
DRM_MODE_PAGE_FLIP_* flags, as passed to the page flip ioctl.
Zero in any other case.
event
Optional pointer to a DRM event to signal upon completion of the
state update. The driver must send out the event when the atomic
commit operation completes. There are two cases:
The event is for a CRTC which is being disabled through this
atomic commit. In that case the event can be send out any time
after the hardware has stopped scanning out the current
framebuffers. It should contain the timestamp and counter for the
last vblank before the display pipeline was shut off. The simplest
way to achieve that is calling drm_crtc_send_vblank_event()
somewhen after drm_crtc_vblank_off() has been called.
For a CRTC which is enabled at the end of the commit (even when it
undergoes an full modeset) the vblank timestamp and counter must
be for the vblank right before the first frame that scans out the
new set of buffers. Again the event can only be sent out after the
hardware has stopped scanning out the old buffers.
Events for disabled CRTCs are not allowed, and drivers can ignore
that case.
This can be handled by the drm_crtc_send_vblank_event() function,
which the driver should call on the provided event upon completion of
the atomic commit. Note that if the driver supports vblank signalling
and timestamping the vblank counters and timestamps must agree with
the ones returned from page flip events. With the current vblank
helper infrastructure this can be achieved by holding a vblank
reference while the page flip is pending, acquired through
drm_crtc_vblank_get() and released with drm_crtc_vblank_put().
Drivers are free to implement their own vblank counter and timestamp
tracking though, e.g. if they have accurate timestamp registers in
hardware.
For hardware which supports some means to synchronize vblank
interrupt delivery with committing display state there’s also
drm_crtc_arm_vblank_event(). See the documentation of that function
for a detailed discussion of the constraints it needs to be used
safely.
If the device can’t notify of flip completion in a race-free way
at all, then the event should be armed just after the page flip is
committed. In the worst case the driver will send the event to
userspace one frame too late. This doesn’t allow for a real atomic
update, but it should avoid tearing.
commit
This tracks how the commit for this update proceeds through the
various phases. This is never cleared, except when we destroy the
state, so that subsequent commits can synchronize with previous ones.
state
backpointer to global drm_atomic_state
Description
Note that the distinction between enable and active is rather subtile:
Flipping active while enable is set without changing anything else may
never return in a failure from the drm_mode_config_funcs.atomic_check
callback. Userspace assumes that a DPMS On will always succeed. In other
words: enable controls resource assignment, active controls the actual
hardware state.
The three booleans active_changed, connectors_changed and mode_changed are
intended to indicate whether a full modeset is needed, rather than strictly
describing what has changed in a commit.
See also: drm_atomic_crtc_needs_modeset()
Reset CRTC hardware and software state to off. This function isn’t
called by the core directly, only through drm_mode_config_reset().
It’s not a helper hook only for historical reasons.
Update the cursor image. The cursor position is relative to the CRTC
and can be partially or fully outside of the visible area.
Note that contrary to all other KMS functions the legacy cursor entry
points don’t take a framebuffer object, but instead take directly a
raw buffer object id from the driver’s buffer manager (which is
either GEM or TTM for current drivers).
This entry point is deprecated, drivers should instead implement
universal plane support and register a proper cursor plane using
drm_crtc_init_with_planes().
This callback is optional
RETURNS:
0 on success or a negative error code on failure.
cursor_set2
Update the cursor image, including hotspot information. The hotspot
must not affect the cursor position in CRTC coordinates, but is only
meant as a hint for virtualized display hardware to coordinate the
guests and hosts cursor position. The cursor hotspot is relative to
the cursor image. Otherwise this works exactly like cursor_set.
This entry point is deprecated, drivers should instead implement
universal plane support and register a proper cursor plane using
drm_crtc_init_with_planes().
This callback is optional.
RETURNS:
0 on success or a negative error code on failure.
cursor_move
Update the cursor position. The cursor does not need to be visible
when this hook is called.
This entry point is deprecated, drivers should instead implement
universal plane support and register a proper cursor plane using
drm_crtc_init_with_planes().
This callback is optional.
RETURNS:
0 on success or a negative error code on failure.
gamma_set
Set gamma on the CRTC.
This callback is optional.
Atomic drivers who want to support gamma tables should implement the
atomic color management support, enabled by calling
drm_crtc_enable_color_mgmt(), which then supports the legacy gamma
interface through the drm_atomic_helper_legacy_gamma_set()
compatibility implementation.
destroy
Clean up plane resources. This is only called at driver unload time
through drm_mode_config_cleanup() since a CRTC cannot be hotplugged
in DRM.
set_config
This is the main legacy entry point to change the modeset state on a
CRTC. All the details of the desired configuration are passed in a
structdrm_mode_set - see there for details.
Legacy entry point to schedule a flip to the given framebuffer.
Page flipping is a synchronization mechanism that replaces the frame
buffer being scanned out by the CRTC with a new frame buffer during
vertical blanking, avoiding tearing (except when requested otherwise
through the DRM_MODE_PAGE_FLIP_ASYNC flag). When an application
requests a page flip the DRM core verifies that the new frame buffer
is large enough to be scanned out by the CRTC in the currently
configured mode and then calls this hook with a pointer to the new
frame buffer.
The driver must wait for any pending rendering to the new framebuffer
to complete before executing the flip. It should also wait for any
pending rendering from other drivers if the underlying buffer is a
shared dma-buf.
An application can request to be notified when the page flip has
completed. The drm core will supply a structdrm_event in the event
parameter in this case. This can be handled by the
drm_crtc_send_vblank_event() function, which the driver should call on
the provided event upon completion of the flip. Note that if
the driver supports vblank signalling and timestamping the vblank
counters and timestamps must agree with the ones returned from page
flip events. With the current vblank helper infrastructure this can
be achieved by holding a vblank reference while the page flip is
pending, acquired through drm_crtc_vblank_get() and released with
drm_crtc_vblank_put(). Drivers are free to implement their own vblank
counter and timestamp tracking though, e.g. if they have accurate
timestamp registers in hardware.
This callback is optional.
NOTE:
Very early versions of the KMS ABI mandated that the driver must
block (but not reject) any rendering to the old framebuffer until the
flip operation has completed and the old framebuffer is no longer
visible. This requirement has been lifted, and userspace is instead
expected to request delivery of an event and wait with recycling old
buffers until such has been received.
RETURNS:
0 on success or a negative error code on failure. Note that if a
page flip operation is already pending the callback should return
-EBUSY. Pageflips on a disabled CRTC (either by setting a NULL mode
or just runtime disabled through DPMS respectively the new atomic
“ACTIVE” state) should result in an -EINVAL error code. Note that
drm_atomic_helper_page_flip() checks this already for atomic drivers.
page_flip_target
Same as page_flip but with an additional parameter specifying the
absolute target vertical blank period (as reported by
drm_crtc_vblank_count()) when the flip should take effect.
Note that the core code calls drm_crtc_vblank_get before this entry
point, and will call drm_crtc_vblank_put if this entry point returns
any non-0 error code. It’s the driver’s responsibility to call
drm_crtc_vblank_put after this entry point returns 0, typically when
the flip completes.
set_property
This is the legacy entry point to update a property attached to the
CRTC.
This callback is optional if the driver does not support any legacy
driver-private properties. For atomic drivers it is not used because
property handling is done entirely in the DRM core.
RETURNS:
0 on success or a negative error code on failure.
atomic_duplicate_state
Duplicate the current atomic state for this CRTC and return it.
The core and helpers guarantee that any atomic state duplicated with
this hook and still owned by the caller (i.e. not transferred to the
driver by calling drm_mode_config_funcs.atomic_commit) will be
cleaned up by calling the atomic_destroy_state hook in this
structure.
It is an error to call this hook before drm_crtc.state has been
initialized correctly.
NOTE:
If the duplicate state references refcounted resources this hook must
acquire a reference for each of them. The driver must release these
references again in atomic_destroy_state.
RETURNS:
Duplicated atomic state or NULL when the allocation failed.
atomic_destroy_state
Destroy a state duplicated with atomic_duplicate_state and release
or unreference all resources it references
atomic_set_property
Decode a driver-private property value and store the decoded value
into the passed-in state structure. Since the atomic core decodes all
standardized properties (even for extensions beyond the core set of
properties which might not be implemented by all drivers) this
requires drivers to subclass the state structure.
Such driver-private properties should really only be implemented for
truly hardware/vendor specific state. Instead it is preferred to
standardize atomic extension and decode the properties used to expose
such an extension in the core.
This callback is optional if the driver does not support any
driver-private atomic properties.
NOTE:
This function is called in the state assembly phase of atomic
modesets, which can be aborted for any reason (including on
userspace’s request to just check whether a configuration would be
possible). Drivers MUST NOT touch any persistent state (hardware or
software) or data structures except the passed in state parameter.
Also since userspace controls in which order properties are set this
function must not do any input validation (since the state update is
incomplete and hence likely inconsistent). Instead any such input
validation must be done in the various atomic_check callbacks.
RETURNS:
0 if the property has been found, -EINVAL if the property isn’t
implemented by the driver (which should never happen, the core only
asks for properties attached to this CRTC). No other validation is
allowed by the driver. The core already checks that the property
value is within the range (integer, valid enum value, ...) the driver
set when registering the property.
atomic_get_property
Reads out the decoded driver-private property. This is used to
implement the GETCRTC IOCTL.
Do not call this function directly, use
drm_atomic_crtc_get_property() instead.
This callback is optional if the driver does not support any
driver-private atomic properties.
RETURNS:
0 on success, -EINVAL if the property isn’t implemented by the
driver (which should never happen, the core only asks for
properties attached to this CRTC).
late_register
This optional hook can be used to register additional userspace
interfaces attached to the crtc like debugfs interfaces.
It is called late in the driver load sequence from drm_dev_register().
Everything added from this callback should be unregistered in
the early_unregister callback.
Returns:
0 on success, or a negative error code on failure.
early_unregister
This optional hook should be used to unregister the additional
userspace interfaces attached to the crtc from
late_register. It is called from drm_dev_unregister(),
early in the driver unload sequence to disable userspace access
before data structures are torndown.
set_crc_source
Changes the source of CRC checksums of frames at the request of
userspace, typically for testing purposes. The sources available are
specific of each driver and a NULL value indicates that CRC
generation is to be switched off.
When CRC generation is enabled, the driver should call
drm_crtc_add_crc_entry() at each frame, providing any information
that characterizes the frame contents in the crcN arguments, as
provided from the configured source. Drivers must accept an “auto”
source name that will select a default source for this CRTC.
Note that “auto” can depend upon the current modeset configuration,
e.g. it could pick an encoder or output specific CRC sampling point.
This callback is optional if the driver does not support any CRC
generation functionality.
RETURNS:
0 on success or a negative error code on failure.
atomic_print_state
If driver subclasses structdrm_crtc_state, it should implement
this optional hook for printing additional driver specific state.
Do not call this directly, use drm_atomic_crtc_print_state()
instead.
get_vblank_counter
Driver callback for fetching a raw hardware vblank counter for the
CRTC. It’s meant to be used by new drivers as the replacement of
drm_driver.get_vblank_counter hook.
This callback is optional. If a device doesn’t have a hardware
counter, the driver can simply leave the hook as NULL. The DRM core
will account for missed vblank events while interrupts where disabled
based on system timestamps.
Wraparound handling and loss of events due to modesetting is dealt
with in the DRM core code, as long as drivers call
drm_crtc_vblank_off() and drm_crtc_vblank_on() when disabling or
enabling a CRTC.
See also drm_device.vblank_disable_immediate and
drm_device.max_vblank_count.
Returns:
Raw vblank counter value.
enable_vblank
Enable vblank interrupts for the CRTC. It’s meant to be used by
new drivers as the replacement of drm_driver.enable_vblank hook.
Returns:
Zero on success, appropriate errno if the vblank interrupt cannot
be enabled.
disable_vblank
Disable vblank interrupts for the CRTC. It’s meant to be used by
new drivers as the replacement of drm_driver.disable_vblank hook.
Description
The drm_crtc_funcs structure is the central CRTC management structure
in the DRM. Each CRTC controls one or more connectors (note that the name
CRTC is simply historical, a CRTC may control LVDS, VGA, DVI, TV out, etc.
connectors, not just CRTs).
Each driver is responsible for filling out this structure at startup time,
in addition to providing other modesetting features, like i2c and DDC
bus accessors.
human readable name, can be overwritten by the driver
mutex
This provides a read lock for the overall CRTC state (mode, dpms
state, ...) and a write lock for everything which can be update
without a full modeset (fb, cursor data, CRTC properties ...). A full
modeset also need to grab drm_mode_config.connection_mutex.
For atomic drivers specifically this protects state.
base
base KMS object for ID tracking etc.
primary
primary plane for this CRTC
cursor
cursor plane for this CRTC
index
Position inside the mode_config.list, can be used as an array
index. It is invariant over the lifetime of the CRTC.
cursor_x
current x position of the cursor, used for universal cursor planes
cursor_y
current y position of the cursor, used for universal cursor planes
List of drm_crtc_commit structures tracking pending commits.
Protected by commit_lock. This list holds its own full reference,
as does the ongoing commit.
“Note that the commit for a state change is also tracked in
drm_crtc_state.commit. For accessing the immediately preceding
commit in an atomic update it is recommended to just use that
pointer in the old CRTC state, since accessing that doesn’t need
any locking or list-walking. commit_list should only be used to
stall for framebuffer cleanup that’s signalled through
drm_crtc_commit.cleanup_done.”
commit_lock
Spinlock to protect commit_list.
debugfs_entry
Debugfs directory for this CRTC.
crc
Configuration settings of CRC capture.
fence_context
timeline context used for fence operations.
fence_lock
spinlock to protect the fences in the fence_context.
fence_seqno
Seqno variable used as monotonic counter for the fences
created on the CRTC’s timeline.
timeline_name
The name of the CRTC’s fence timeline.
Description
Each CRTC may have one or more connectors associated with it. This structure
allows the CRTC to be controlled.
This can be used to look up a CRTC from its userspace ID. Only used by
drivers for legacy IOCTLs and interface, nowadays extensions to the KMS
userspace interface should be done using drm_property.
Initialise a new CRTC object with specified primary and cursor planes.
Parameters
structdrm_device*dev
DRM device
structdrm_crtc*crtc
CRTC object to init
structdrm_plane*primary
Primary plane for CRTC
structdrm_plane*cursor
Cursor plane for CRTC
conststructdrm_crtc_funcs*funcs
callbacks for the new CRTC
constchar*name
printf style format string for the CRTC name, or NULL for default name
...
variable arguments
Description
Inits a new object created as base part of a driver crtc object. Drivers
should use this function instead of drm_crtc_init(), which is only provided
for backwards compatibility with drivers which do not yet support universal
planes). For really simple hardware which has only 1 plane look at
drm_simple_display_pipe_init() instead.
This function cleans up crtc and removes it from the DRM mode setting
core. Note that the function does not free the crtc structure itself,
this is the responsibility of the caller.
int drm_mode_set_config_internal(struct drm_mode_set * set)¶
This is a little helper to wrap internal calls to the
drm_mode_config_funcs.set_config driver interface. The only thing it adds is
correct refcounting dance.
This should only be used by non-atomic legacy drivers.
Frame buffers are abstract memory objects that provide a source of pixels to
scanout to a CRTC. Applications explicitly request the creation of frame
buffers through the DRM_IOCTL_MODE_ADDFB(2) ioctls and receive an opaque
handle that can be passed to the KMS CRTC control, plane configuration and
page flip functions.
Frame buffers rely on the underlying memory manager for allocating backing
storage. When creating a frame buffer applications pass a memory handle
(or a list of memory handles for multi-planar formats) through the
structdrm_mode_fb_cmd2 argument. For drivers using GEM as their userspace
buffer management interface this would be a GEM handle. Drivers are however
free to use their own backing storage object handles, e.g. vmwgfx directly
exposes special TTM handles to userspace and so expects TTM handles in the
create ioctl and not GEM handles.
The lifetime of a drm framebuffer is controlled with a reference count,
drivers can grab additional references with drm_framebuffer_get() and drop
them again with drm_framebuffer_put(). For driver-private framebuffers for
which the last reference is never dropped (e.g. for the fbdev framebuffer
when the struct structdrm_framebuffer is embedded into the fbdev helper
struct) drivers can manually clean up a framebuffer at module unload time
with drm_framebuffer_unregister_private(). But doing this is not
recommended, and it’s better to have a normal free-standing structdrm_framebuffer.
Clean up framebuffer resources, specifically also unreference the
backing storage. The core guarantees to call this function for every
framebuffer successfully created by calling
drm_mode_config_funcs.fb_create. Drivers must also call
drm_framebuffer_cleanup() to release DRM core resources for this
framebuffer.
create_handle
Create a buffer handle in the driver-specific buffer manager (either
GEM or TTM) valid for the passed-in structdrm_file. This is used by
the core to implement the GETFB IOCTL, which returns (for
sufficiently priviledged user) also a native buffer handle. This can
be used for seamless transitions between modesetting clients by
copying the current screen contents to a private buffer and blending
between that and the new contents.
Userspace can notify the driver via this callback that an area of the
framebuffer has changed and should be flushed to the display
hardware. This can also be used internally, e.g. by the fbdev
emulation, though that’s not the case currently.
See documentation in drm_mode.h for the struct drm_mode_fb_dirty_cmd
for more information as all the semantics and arguments have a one to
one mapping on this function.
base modeset object structure, contains the reference count.
comm
Name of the process allocating the fb, used for fb dumping.
format
framebuffer format information
funcs
framebuffer vfunc table
pitches
Line stride per buffer. For userspace created object this
is copied from drm_mode_fb_cmd2.
offsets
Offset from buffer start to the actual pixel data in bytes,
per buffer. For userspace created object this is copied from
drm_mode_fb_cmd2.
Note that this is a linear offset and does not take into account
tiling or buffer laytou per modifier. It meant to be used when the
actual pixel data for this framebuffer plane starts at an offset,
e.g. when multiple planes are allocated within the same backing
storage buffer object. For tiled layouts this generally means it
offsets must at least be tile-size aligned, but hardware often has
stricter requirements.
This should not be used to specifiy x/y pixel offsets into the buffer
data (even for linear buffers). Specifying an x/y pixel offset is
instead done through the source rectangle in structdrm_plane_state.
modifier
Data layout modifier. This is used to describe
tiling, or also special layouts (like compression) of auxiliary
buffers. For userspace created object this is copied from
drm_mode_fb_cmd2.
width
Logical width of the visible area of the framebuffer, in
pixels.
height
Logical height of the visible area of the framebuffer, in
pixels.
flags
Framebuffer flags like DRM_MODE_FB_INTERLACED or
DRM_MODE_FB_MODIFIERS.
hot_x
X coordinate of the cursor hotspot. Used by the legacy cursor
IOCTL when the driver supports cursor through a DRM_PLANE_TYPE_CURSOR
universal plane.
hot_y
Y coordinate of the cursor hotspot. Used by the legacy cursor
IOCTL when the driver supports cursor through a DRM_PLANE_TYPE_CURSOR
universal plane.
Note that the fb is refcounted for the benefit of driver internals,
for example some hw, disabling a CRTC/plane is asynchronous, and
scanout does not actually complete until the next vblank. So some
cleanup (like releasing the reference(s) on the backing GEM bo(s))
should be deferred. In cases like this, the driver would like to
hold a ref to the fb even though it has already been removed from
userspace perspective. See drm_framebuffer_get() and
drm_framebuffer_put().
The refcount is stored inside the mode object base.
Allocates an ID for the framebuffer’s parent mode object, sets its mode
functions & device file and adds it to the master fd list.
IMPORTANT:
This functions publishes the fb and makes it available for concurrent access
by other users. Which means by this point the fb _must_ be fully set up -
since all the fb attributes are invariant over its lifetime, no further
locking but only correct reference counting is required.
If successful, this grabs an additional reference to the framebuffer -
callers need to make sure to eventually unreference the returned framebuffer
again, using drm_framebuffer_put().
Drivers need to call this when cleaning up driver-private framebuffers, e.g.
those used for fbdev. Note that the caller must hold a reference of it’s own,
i.e. the object may not be destroyed through this call (since it’ll lead to a
locking inversion).
NOTE
This function is deprecated. For driver-private framebuffers it is not
recommended to embed a framebuffer struct info fbdev struct, instead, a
framebuffer pointer is preferred and drm_framebuffer_put() should be called
when the framebuffer is to be cleaned up.
Cleanup framebuffer. This function is intended to be used from the drivers
drm_framebuffer_funcs.destroy callback. It can also be used to clean up
driver private framebuffers embedded into a larger structure.
Note that this function does not remove the fb from active usage - if it is
still used anywhere, hilarity can ensue since userspace could call getfb on
the id and get back -EINVAL. Obviously no concern at driver unload time.
Also, the framebuffer will not be removed from the lookup idr - for
user-created framebuffers this will happen in in the rmfb ioctl. For
driver-private objects (e.g. for fbdev) drivers need to explicitly call
drm_framebuffer_unregister_private.
Scans all the CRTCs and planes in dev‘s mode_config. If they’re
using fb, removes it, setting it to NULL. Then drops the reference to the
passed-in framebuffer. Might take the modeset locks.
Note that this function optimizes the cleanup away if the caller holds the
last reference to the framebuffer. It is also guaranteed to not take the
modeset locks in this case.
int drm_framebuffer_plane_width(int width, const struct drm_framebuffer * fb, int plane)¶
width of the plane given the first plane
Parameters
intwidth
width of the first plane
conststructdrm_framebuffer*fb
the framebuffer
intplane
plane index
Return
The width of plane, given that the width of the first plane is width.
int drm_framebuffer_plane_height(int height, const struct drm_framebuffer * fb, int plane)¶
height of the plane given the first plane
Parameters
intheight
height of the first plane
conststructdrm_framebuffer*fb
the framebuffer
intplane
plane index
Return
The height of plane, given that the height of the first plane is height.
Color depth (number of bits per pixel excluding padding bits),
valid for a subset of RGB formats only. This is a legacy field, do not
use in new code and set to 0 for new formats.
The KMS API doesn’t standardize backing storage object creation and leaves it
to driver-specific ioctls. Furthermore actually creating a buffer object even
for GEM-based drivers is done through a driver-specific ioctl - GEM only has
a common userspace interface for sharing and destroying objects. While not an
issue for full-fledged graphics stacks that include device-specific userspace
components (in libdrm for instance), this limit makes DRM-based early boot
graphics unnecessarily complex.
Dumb objects partly alleviate the problem by providing a standard API to
create dumb buffers suitable for scanout, which can then be used to create
KMS frame buffers.
Note that dumb objects may not be used for gpu acceleration, as has been
attempted on some ARM embedded platforms. Such drivers really must have
a hardware-specific ioctl to allocate suitable buffer objects.
A plane represents an image source that can be blended with or overlayed on
top of a CRTC during the scanout process. Planes take their input data from a
drm_framebuffer object. The plane itself specifies the cropping and scaling
of that image, and where it is placed on the visible are of a display
pipeline, represented by drm_crtc. A plane can also have additional
properties that specify how the pixels are positioned and blended, like
rotation or Z-position. All these properties are stored in drm_plane_state.
To create a plane, a KMS drivers allocates and zeroes an instances of
structdrm_plane (possibly as part of a larger structure) and registers it
with a call to drm_universal_plane_init().
Cursor and overlay planes are optional. All drivers should provide one
primary plane per CRTC to avoid surprising userspace too much. See enum
drm_plane_type for a more in-depth discussion of these special uapi-relevant
plane types. Special planes are associated with their CRTC by calling
drm_crtc_init_with_planes().
The type of a plane is exposed in the immutable “type” enumeration property,
which has one of the following values: “Overlay”, “Primary”, “Cursor”.
Left position of visible portion of plane on crtc, signed dest
location allows it to be partially off screen.
crtc_y
Upper position of visible portion of plane on crtc, signed dest
location allows it to be partially off screen.
crtc_w
width of visible portion of plane on crtc
crtc_h
height of visible portion of plane on crtc
src_x
left position of visible portion of plane within
plane (in 16.16)
src_y
upper position of visible portion of plane within
plane (in 16.16)
src_h
height of visible portion of plane (in 16.16)
src_w
width of visible portion of plane (in 16.16)
rotation
rotation of the plane
zpos
priority of the given plane on crtc (optional)
Note that multiple active planes on the same crtc can have an identical
zpos value. The rule to solving the conflict is to compare the plane
object IDs; the plane with a higher ID must be stacked on top of a
plane with a lower ID.
normalized_zpos
normalized value of zpos: unique, range from 0 to N-1
where N is the number of active planes for given crtc. Note that
the driver must call drm_atomic_normalize_zpos() to update this before
it can be trusted.
src
clipped source coordinates of the plane (in 16.16)
dst
clipped destination coordinates of the plane
visible
Visibility of the plane. This can be false even if fb!=NULL and
crtc!=NULL, due to clipping.
commit
Tracks the pending commit to prevent use-after-free conditions,
and for async plane updates.
This is the legacy entry point to enable and configure the plane for
the given CRTC and framebuffer. It is never called to disable the
plane, i.e. the passed-in crtc and fb paramters are never NULL.
The source rectangle in frame buffer memory coordinates is given by
the src_x, src_y, src_w and src_h parameters (as 16.16 fixed point
values). Devices that don’t support subpixel plane coordinates can
ignore the fractional part.
The destination rectangle in CRTC coordinates is given by the
crtc_x, crtc_y, crtc_w and crtc_h parameters (as integer values).
Devices scale the source rectangle to the destination rectangle. If
scaling is not supported, and the source rectangle size doesn’t match
the destination rectangle size, the driver must return a
-<errorname>EINVAL</errorname> error.
This is the legacy entry point to disable the plane. The DRM core
calls this method in response to a DRM_IOCTL_MODE_SETPLANE IOCTL call
with the frame buffer ID set to 0. Disabled planes must not be
processed by the CRTC.
Clean up plane resources. This is only called at driver unload time
through drm_mode_config_cleanup() since a plane cannot be hotplugged
in DRM.
reset
Reset plane hardware and software state to off. This function isn’t
called by the core directly, only through drm_mode_config_reset().
It’s not a helper hook only for historical reasons.
This is the legacy entry point to update a property attached to the
plane.
This callback is optional if the driver does not support any legacy
driver-private properties. For atomic drivers it is not used because
property handling is done entirely in the DRM core.
RETURNS:
0 on success or a negative error code on failure.
atomic_duplicate_state
Duplicate the current atomic state for this plane and return it.
The core and helpers guarantee that any atomic state duplicated with
this hook and still owned by the caller (i.e. not transferred to the
driver by calling drm_mode_config_funcs.atomic_commit) will be
cleaned up by calling the atomic_destroy_state hook in this
structure.
It is an error to call this hook before drm_plane.state has been
initialized correctly.
NOTE:
If the duplicate state references refcounted resources this hook must
acquire a reference for each of them. The driver must release these
references again in atomic_destroy_state.
RETURNS:
Duplicated atomic state or NULL when the allocation failed.
atomic_destroy_state
Destroy a state duplicated with atomic_duplicate_state and release
or unreference all resources it references
atomic_set_property
Decode a driver-private property value and store the decoded value
into the passed-in state structure. Since the atomic core decodes all
standardized properties (even for extensions beyond the core set of
properties which might not be implemented by all drivers) this
requires drivers to subclass the state structure.
Such driver-private properties should really only be implemented for
truly hardware/vendor specific state. Instead it is preferred to
standardize atomic extension and decode the properties used to expose
such an extension in the core.
Do not call this function directly, use
drm_atomic_plane_set_property() instead.
This callback is optional if the driver does not support any
driver-private atomic properties.
NOTE:
This function is called in the state assembly phase of atomic
modesets, which can be aborted for any reason (including on
userspace’s request to just check whether a configuration would be
possible). Drivers MUST NOT touch any persistent state (hardware or
software) or data structures except the passed in state parameter.
Also since userspace controls in which order properties are set this
function must not do any input validation (since the state update is
incomplete and hence likely inconsistent). Instead any such input
validation must be done in the various atomic_check callbacks.
RETURNS:
0 if the property has been found, -EINVAL if the property isn’t
implemented by the driver (which shouldn’t ever happen, the core only
asks for properties attached to this plane). No other validation is
allowed by the driver. The core already checks that the property
value is within the range (integer, valid enum value, ...) the driver
set when registering the property.
atomic_get_property
Reads out the decoded driver-private property. This is used to
implement the GETPLANE IOCTL.
Do not call this function directly, use
drm_atomic_plane_get_property() instead.
This callback is optional if the driver does not support any
driver-private atomic properties.
RETURNS:
0 on success, -EINVAL if the property isn’t implemented by the
driver (which should never happen, the core only asks for
properties attached to this plane).
late_register
This optional hook can be used to register additional userspace
interfaces attached to the plane like debugfs interfaces.
It is called late in the driver load sequence from drm_dev_register().
Everything added from this callback should be unregistered in
the early_unregister callback.
Returns:
0 on success, or a negative error code on failure.
early_unregister
This optional hook should be used to unregister the additional
userspace interfaces attached to the plane from
late_register. It is called from drm_dev_unregister(),
early in the driver unload sequence to disable userspace access
before data structures are torndown.
atomic_print_state
If driver subclasses structdrm_plane_state, it should implement
this optional hook for printing additional driver specific state.
Do not call this directly, use drm_atomic_plane_print_state()
instead.
format_mod_supported
This optional hook is used for the DRM to determine if the given
format/modifier combination is valid for the plane. This allows the
DRM to generate the correct format bitmask (which formats apply to
which modifier).
Returns:
True if the given modifier is valid for that format on the plane.
False otherwise.
Overlay planes represent all non-primary, non-cursor planes. Some
drivers refer to these types of planes as “sprites” internally.
DRM_PLANE_TYPE_PRIMARY
Primary planes represent a “main” plane for a CRTC. Primary planes
are the planes operated upon by CRTC modesetting and flipping
operations described in the drm_crtc_funcs.page_flip and
drm_crtc_funcs.set_config hooks.
DRM_PLANE_TYPE_CURSOR
Cursor planes represent a “cursor” plane for a CRTC. Cursor planes
are the planes operated upon by the DRM_IOCTL_MODE_CURSOR and
DRM_IOCTL_MODE_CURSOR2 IOCTLs.
Description
For historical reasons not all planes are made the same. This enumeration is
used to tell the different types of planes apart to implement the different
uapi semantics for them. For userspace which is universal plane aware and
which is using that atomic IOCTL there’s no difference between these planes
(beyong what the driver and hardware can support of course).
For compatibility with legacy userspace, only overlay planes are made
available to userspace by default. Userspace clients may set the
DRM_CLIENT_CAP_UNIVERSAL_PLANES client capability bit to indicate that they
wish to receive a universal plane list containing all plane types. See also
drm_for_each_legacy_plane().
WARNING: The values of this enum is UABI since they’re exposed in the “type”
property.
Iterate over all legacy planes of dev, excluding primary and cursor planes.
This is useful for implementing userspace apis when userspace is not
universal plane aware. See also enumdrm_plane_type.
This function cleans up plane and removes it from the DRM mode setting
core. Note that the function does not free the plane structure itself,
this is the responsibility of the caller.
struct drm_plane * drm_plane_from_index(struct drm_device * dev, int idx)¶
find the registered plane at an index
Parameters
structdrm_device*dev
DRM device
intidx
index of registered plane to find for
Description
Given a plane index, return the registered plane from DRM device’s
list of planes with matching index. This is the inverse of drm_plane_index().
This functions sets a given property on a given plane object. This function
calls the driver’s ->set_property callback and changes the software state of
the property if the callback succeeds.
struct drm_display_mode {
struct list_head head;
struct drm_mode_object base;
char name[DRM_DISPLAY_MODE_LEN];
enum drm_mode_status status;
unsigned int type;
int clock;
int hdisplay;
int hsync_start;
int hsync_end;
int htotal;
int hskew;
int vdisplay;
int vsync_start;
int vsync_end;
int vtotal;
int vscan;
unsigned int flags;
int width_mm;
int height_mm;
int crtc_clock;
int crtc_hdisplay;
int crtc_hblank_start;
int crtc_hblank_end;
int crtc_hsync_start;
int crtc_hsync_end;
int crtc_htotal;
int crtc_hskew;
int crtc_vdisplay;
int crtc_vblank_start;
int crtc_vblank_end;
int crtc_vsync_start;
int crtc_vsync_end;
int crtc_vtotal;
int *private;
int private_flags;
int vrefresh;
int hsync;
enum hdmi_picture_aspect picture_aspect_ratio;
};
Members
head
struct list_head for mode lists.
base
A display mode is a normal modeset object, possibly including public
userspace id.
FIXME:
This can probably be removed since the entire concept of userspace
managing modes explicitly has never landed in upstream kernel mode
setting support.
Status of the mode, used to filter out modes not supported by the
hardware. See enum drm_mode_status.
type
A bitmask of flags, mostly about the source of a mode. Possible flags
are:
DRM_MODE_TYPE_BUILTIN: Meant for hard-coded modes, effectively
unused.
DRM_MODE_TYPE_PREFERRED: Preferred mode, usually the native
resolution of an LCD panel. There should only be one preferred
mode per connector at any given time.
DRM_MODE_TYPE_DRIVER: Mode created by the driver, which is all of
them really. Drivers must set this bit for all modes they create
and expose to userspace.
Plus a big list of flags which shouldn’t be used at all, but are
still around since these flags are also used in the userspace ABI:
DRM_MODE_TYPE_DEFAULT: Again a leftover, use
DRM_MODE_TYPE_PREFERRED instead.
DRM_MODE_TYPE_CLOCK_C and DRM_MODE_TYPE_CRTC_C: Define leftovers
which are stuck around for hysterical raisins only. No one has an
idea what they were meant for. Don’t use.
DRM_MODE_TYPE_USERDEF: Mode defined by userspace, again a vestige
from older kms designs where userspace had to first add a custom
mode to the kernel’s mode list before it could use it. Don’t use.
clock
Pixel clock in kHz.
hdisplay
horizontal display size
hsync_start
horizontal sync start
hsync_end
horizontal sync end
htotal
horizontal total size
hskew
horizontal skew?!
vdisplay
vertical display size
vsync_start
vertical sync start
vsync_end
vertical sync end
vtotal
vertical total size
vscan
vertical scan?!
flags
Sync and timing flags:
DRM_MODE_FLAG_PHSYNC: horizontal sync is active high.
DRM_MODE_FLAG_NHSYNC: horizontal sync is active low.
DRM_MODE_FLAG_PVSYNC: vertical sync is active high.
DRM_MODE_FLAG_NVSYNC: vertical sync is active low.
DRM_MODE_FLAG_INTERLACE: mode is interlaced.
DRM_MODE_FLAG_DBLSCAN: mode uses doublescan.
DRM_MODE_FLAG_CSYNC: mode uses composite sync.
DRM_MODE_FLAG_PCSYNC: composite sync is active high.
DRM_MODE_FLAG_NCSYNC: composite sync is active low.
DRM_MODE_FLAG_HSKEW: hskew provided (not used?).
DRM_MODE_FLAG_BCAST: not used?
DRM_MODE_FLAG_PIXMUX: not used?
DRM_MODE_FLAG_DBLCLK: double-clocked mode.
DRM_MODE_FLAG_CLKDIV2: half-clocked mode.
Additionally there’s flags to specify how 3D modes are packed:
DRM_MODE_FLAG_3D_NONE: normal, non-3D mode.
DRM_MODE_FLAG_3D_FRAME_PACKING: 2 full frames for left and right.
DRM_MODE_FLAG_3D_FIELD_ALTERNATIVE: interleaved like fields.
DRM_MODE_FLAG_3D_SIDE_BY_SIDE_FULL: side-by-side full frames.
DRM_MODE_FLAG_3D_L_DEPTH: ?
DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH: ?
DRM_MODE_FLAG_3D_TOP_AND_BOTTOM: frame split into top and bottom
parts.
DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF: frame split into left and
right parts.
width_mm
Addressable size of the output in mm, projectors should set this to
0.
height_mm
Addressable size of the output in mm, projectors should set this to
0.
crtc_clock
Actual pixel or dot clock in the hardware. This differs from the
logical clock when e.g. using interlacing, double-clocking, stereo
modes or other fancy stuff that changes the timings and signals
actually sent over the wire.
This is again in kHz.
Note that with digital outputs like HDMI or DP there’s usually a
massive confusion between the dot clock and the signal clock at the
bit encoding level. Especially when a 8b/10b encoding is used and the
difference is exactly a factor of 10.
crtc_hdisplay
hardware mode horizontal display size
crtc_hblank_start
hardware mode horizontal blank start
crtc_hblank_end
hardware mode horizontal blank end
crtc_hsync_start
hardware mode horizontal sync start
crtc_hsync_end
hardware mode horizontal sync end
crtc_htotal
hardware mode horizontal total size
crtc_hskew
hardware mode horizontal skew?!
crtc_vdisplay
hardware mode vertical display size
crtc_vblank_start
hardware mode vertical blank start
crtc_vblank_end
hardware mode vertical blank end
crtc_vsync_start
hardware mode vertical sync start
crtc_vsync_end
hardware mode vertical sync end
crtc_vtotal
hardware mode vertical total size
private
Pointer for driver private data. This can only be used for mode
objects passed to drivers in modeset operations. It shouldn’t be used
by atomic drivers since they can store any additional data by
subclassing state structures.
private_flags
Similar to private, but just an integer.
vrefresh
Vertical refresh rate, for debug output in human readable form. Not
used in a functional way.
This value is in Hz.
hsync
Horizontal refresh rate, for debug output in human readable form. Not
used in a functional way.
This value is in kHz.
picture_aspect_ratio
Field for setting the HDMI picture aspect ratio of a mode.
Description
The horizontal and vertical timings are defined per the following diagram.
Active Front Sync Back
Region Porch Porch
<-----------------------><----------------><-------------><-------------->
//////////////////////|
////////////////////// |
////////////////////// |.................. ................
_______________
<----- [hv]display ----->
<------------- [hv]sync_start ------------>
<--------------------- [hv]sync_end --------------------->
<-------------------------------- [hv]total ----------------------------->*
This structure contains two copies of timings. First are the plain timings,
which specify the logical mode, as it would be for a progressive 1:1 scanout
at the refresh rate userspace can observe through vblank timestamps. Then
there’s the hardware timings, which are corrected for interlacing,
double-clocking and similar things. They are provided as a convenience, and
can be appropriately computed using drm_mode_set_crtcinfo().
For printing you can use DRM_MODE_FMT and DRM_MODE_ARG().
Add mode to connector‘s probed_mode list for later use. This list should
then in a second step get filtered and all the modes actually supported by
the hardware moved to the connector‘s modes list.
struct drm_display_mode * drm_cvt_mode(struct drm_device * dev, int hdisplay, int vdisplay, int vrefresh, bool reduced, bool interlaced, bool margins)¶
create a modeline based on the CVT algorithm
Parameters
structdrm_device*dev
drm device
inthdisplay
hdisplay size
intvdisplay
vdisplay size
intvrefresh
vrefresh rate
boolreduced
whether to use reduced blanking
boolinterlaced
whether to compute an interlaced mode
boolmargins
whether to add margins (borders)
Description
This function is called to generate the modeline based on CVT algorithm
according to the hdisplay, vdisplay, vrefresh.
It is based from the VESA(TM) Coordinated Video Timing Generator by
Graham Loveridge April 9, 2003 available at
http://www.elo.utfsm.cl/~elo212/docs/CVTd6r1.xls
And it is copied from xf86CVTmode in xserver/hw/xfree86/modes/xf86cvt.c.
What I have done is to translate it by using integer calculation.
Return
The modeline based on the CVT algorithm stored in a drm_display_mode object.
The display mode object is allocated with drm_mode_create(). Returns NULL
when no mode could be allocated.
struct drm_display_mode * drm_gtf_mode_complex(struct drm_device * dev, int hdisplay, int vdisplay, int vrefresh, bool interlaced, int margins, int GTF_M, int GTF_2C, int GTF_K, int GTF_2J)¶
create the modeline based on the full GTF algorithm
Parameters
structdrm_device*dev
drm device
inthdisplay
hdisplay size
intvdisplay
vdisplay size
intvrefresh
vrefresh rate.
boolinterlaced
whether to compute an interlaced mode
intmargins
desired margin (borders) size
intGTF_M
extended GTF formula parameters
intGTF_2C
extended GTF formula parameters
intGTF_K
extended GTF formula parameters
intGTF_2J
extended GTF formula parameters
Description
GTF feature blocks specify C and J in multiples of 0.5, so we pass them
in here multiplied by two. For a C of 40, pass in 80.
Return
The modeline based on the full GTF algorithm stored in a drm_display_mode object.
The display mode object is allocated with drm_mode_create(). Returns NULL
when no mode could be allocated.
struct drm_display_mode * drm_gtf_mode(struct drm_device * dev, int hdisplay, int vdisplay, int vrefresh, bool interlaced, int margins)¶
create the modeline based on the GTF algorithm
Parameters
structdrm_device*dev
drm device
inthdisplay
hdisplay size
intvdisplay
vdisplay size
intvrefresh
vrefresh rate.
boolinterlaced
whether to compute an interlaced mode
intmargins
desired margin (borders) size
Description
return the modeline based on GTF algorithm
This function is to create the modeline based on the GTF algorithm.
Generalized Timing Formula is derived from:
And it is copied from the file of xserver/hw/xfree86/modes/xf86gtf.c.
What I have done is to translate it by using integer calculation.
I also refer to the function of fb_get_mode in the file of
drivers/video/fbmon.c
Standard GTF parameters:
M = 600
C = 40
K = 128
J = 20
Return
The modeline based on the GTF algorithm stored in a drm_display_mode object.
The display mode object is allocated with drm_mode_create(). Returns NULL
when no mode could be allocated.
extract information about pixelclk and DE polarity from videomode and store it in a separate variable
Parameters
conststructvideomode*vm
videomode structure to use
u32*bus_flags
information about pixelclk and DE polarity will be stored here
Description
Sets DRM_BUS_FLAG_DE_(LOW|HIGH) and DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE
in bus_flags according to DISPLAY_FLAGS found in vm
int of_get_drm_display_mode(struct device_node * np, struct drm_display_mode * dmode, u32 * bus_flags, int index)¶
get a drm_display_mode from devicetree
Parameters
structdevice_node*np
device_node with the timing specification
structdrm_display_mode*dmode
will be set to the return value
u32*bus_flags
information about pixelclk and DE polarity
intindex
index into the list of display timings in devicetree
Description
This function is expensive and should only be used, if only one mode is to be
read from DT. To get multiple modes start with of_get_display_timings and
work with that instead.
Return
0 on success, a negative errno code when no of videomode node was found.
modes‘s vrefresh rate in Hz, rounded to the nearest integer. Calculates the
value first if it is not yet set.
void drm_mode_get_hv_timing(const struct drm_display_mode * mode, int * hdisplay, int * vdisplay)¶
Fetches hdisplay/vdisplay for given mode
Parameters
conststructdrm_display_mode*mode
mode to query
int*hdisplay
hdisplay value to fill in
int*vdisplay
vdisplay value to fill in
Description
The vdisplay value will be doubled if the specified mode is a stereo mode of
the appropriate layout.
void drm_mode_set_crtcinfo(struct drm_display_mode * p, int adjust_flags)¶
set CRTC modesetting timing parameters
Parameters
structdrm_display_mode*p
mode
intadjust_flags
a combination of adjustment flags
Description
Setup the CRTC modesetting timing parameters for p, adjusting if necessary.
The CRTC_INTERLACE_HALVE_V flag can be used to halve vertical timings of
interlaced modes.
The CRTC_STEREO_DOUBLE flag can be used to compute the timings for
buffers containing two eyes (only adjust the timings when needed, eg. for
“frame packing” or “side by side full”).
The CRTC_NO_DBLSCAN and CRTC_NO_VSCAN flags request that adjustment not
be performed for doublescan and vscan > 1 modes respectively.
This function is a helper which can be used to validate modes against size
limitations of the DRM device/connector. If a mode is too big its status
member is updated with the appropriate validation failure code. The list
itself is not changed.
This helper function can be used to prune a display mode list after
validation has been completed. All modes who’s status is not MODE_OK will be
removed from the list, and if verbose the status code and mode name is also
printed to dmesg.
This moves the modes from the connector probed_modes list
to the actual mode list. It compares the probed mode against the current
list and only adds different/new modes.
This is just a helper functions doesn’t validate any modes itself and also
doesn’t prune any invalid modes. Callers need to do that themselves.
preallocated drm_cmdline_mode structure to fill out
Description
This parses mode_option command line modeline for modes and options to
configure the connector. If mode_option is NULL the default command line
modeline in fb_mode_option will be parsed instead.
This uses the same parameters as the fb modedb.c, except for an extra
force-enable, force-enable-digital and force-disable bit at the end:
In DRM connectors are the general abstraction for display sinks, and include
als fixed panels or anything else that can display pixels in some form. As
opposed to all other KMS objects representing hardware (like CRTC, encoder or
plane abstractions) connectors can be hotplugged and unplugged at runtime.
Hence they are reference-counted using drm_connector_get() and
drm_connector_put().
KMS driver must create, initialize, register and attach at a structdrm_connector for each such sink. The instance is created as other KMS
objects and initialized by setting the following fields. The connector is
initialized with a call to drm_connector_init() with a pointer to the
structdrm_connector_funcs and a connector type, and then exposed to
userspace with a call to drm_connector_register().
Connectors must be attached to an encoder to be used. For devices that map
connectors to encoders 1:1, the connector should be attached at
initialization time with a call to drm_mode_connector_attach_encoder(). The
driver must also set the drm_connector.encoder field to point to the
attached encoder.
For connectors which are not fixed (like built-in panels) the driver needs to
support hotplug notifications. The simplest way to do that is by using the
probe helpers, see drm_kms_helper_poll_init() for connectors which don’t have
hardware support for hotplug interrupts. Connectors with hardware hotplug
support can instead use e.g. drm_helper_hpd_irq_event().
The connector is definitely connected to
a sink device, and can be enabled.
connector_status_disconnected
The connector isn’t connected to a
sink device which can be autodetect. For digital outputs like DP or
HDMI (which can be realiable probed) this means there’s really
nothing there. It is driver-dependent whether a connector with this
status can be lit up or not.
connector_status_unknown
The connector’s status could not be
reliably detected. This happens when probing would either cause
flicker (like load-detection when the connector is in use), or when a
hardware resource isn’t available (like when load-detection needs a
free CRTC). It should be possible to light up the connector with one
of the listed fallback modes. For default configuration userspace
should only try to light up connectors with unknown status when
there’s not connector with connector_status_connected.
Description
This enum is used to track the connector status. There are no separate
#defines for the uapi!
struct drm_hdmi_info {
struct drm_scdc scdc;
unsigned long y420_vdb_modes[BITS_TO_LONGS(128)];
unsigned long y420_cmdb_modes[BITS_TO_LONGS(128)];
u64 y420_cmdb_map;
u8 y420_dc_modes;
};
Members
scdc
sink’s scdc support and capabilities
y420_vdb_modes
bitmap of modes which can support ycbcr420
output only (not normal RGB/YCBCR444/422 outputs). There are total
107 VICs defined by CEA-861-F spec, so the size is 128 bits to map
upto 128 VICs;
y420_cmdb_modes
bitmap of modes which can support ycbcr420
output also, along with normal HDMI outputs. There are total 107
VICs defined by CEA-861-F spec, so the size is 128 bits to map upto
128 VICs;
y420_cmdb_map
bitmap of SVD index, to extraxt vcb modes
y420_dc_modes
bitmap of deep color support index
Description
Describes if a given display supports advanced HDMI 2.0 features.
This information is available in CEA-861-F extension blocks (like HF-VSDB).
The drm driver has not provided any
panel orientation information (normal
for non panels) in this case the “panel
orientation” connector prop will not be
attached.
DRM_MODE_PANEL_ORIENTATION_NORMAL
The top side of the panel matches the
top side of the device’s casing.
DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP
The top side of the panel matches the
bottom side of the device’s casing, iow
the panel is mounted upside-down.
DRM_MODE_PANEL_ORIENTATION_LEFT_UP
The left side of the panel matches the
top side of the device’s casing.
DRM_MODE_PANEL_ORIENTATION_RIGHT_UP
The right side of the panel matches the
top side of the device’s casing.
Description
This enum is used to track the (LCD) panel orientation. There are no
separate #defines for the uapi!
Maximum pixel clock supported by the sink, in units of
100Hz. This mismatches the clock in drm_display_mode (which is in
kHZ), because that’s what the EDID uses as base unit.
bpc
Maximum bits per color channel. Used by HDMI and DP outputs.
subpixel_order
Subpixel order of LCD panels.
panel_orientation
Read only connector property for built-in panels,
indicating the orientation of the panel vs the device’s casing.
drm_connector_init() sets this to DRM_MODE_PANEL_ORIENTATION_UNKNOWN.
When not UNKNOWN this gets used by the drm_fb_helpers to rotate the
fb to compensate and gets exported as prop to userspace.
color_formats
HDMI Color formats, selects between RGB and YCrCb
modes. Used DRM_COLOR_FORMAT_ defines, which are _not_ the same ones
as used to describe the pixel format in framebuffers, and also don’t
match the formats in bus_formats which are shared with v4l.
bus_formats
Pixel data format on the wire, somewhat redundant with
color_formats. Array of size num_bus_formats encoded using
MEDIA_BUS_FMT_ defines shared with v4l and media drivers.
num_bus_formats
Size of bus_formats array.
bus_flags
Additional information (like pixel signal polarity) for
the pixel data on the bus, using DRM_BUS_FLAGS_ defines.
max_tmds_clock
Maximum TMDS clock rate supported by the
sink in kHz. 0 means undefined.
dvi_dual
Dual-link DVI sink?
has_hdmi_infoframe
Does the sink support the HDMI infoframe?
edid_hdmi_dc_modes
Mask of supported hdmi deep color modes. Even
more stuff redundant with bus_formats.
cea_rev
CEA revision of the HDMI sink.
hdmi
advance features of a HDMI sink.
non_desktop
Non desktop display (HMD).
Description
Describes a given display (e.g. CRT or flat panel) and its limitations. For
fixed display sinks like built-in panels there’s not much difference between
this and structdrm_connector. But for sinks with a real cable this
structure is meant to describe all the things at the other end of the cable.
For sinks which provide an EDID this can be filled out by calling
drm_add_edid_modes().
struct drm_tv_connector_state {
enum drm_mode_subconnector subconnector;
struct {
unsigned int left;
unsigned int right;
unsigned int top;
unsigned int bottom;
} margins;
unsigned int mode;
unsigned int brightness;
unsigned int contrast;
unsigned int flicker_reduction;
unsigned int overscan;
unsigned int saturation;
unsigned int hue;
};
Legacy entry point to set the per-connector DPMS state. Legacy DPMS
is exposed as a standard property on the connector, but diverted to
this callback in the drm core. Note that atomic drivers don’t
implement the 4 level DPMS support on the connector any more, but
instead only have an on/off “ACTIVE” property on the CRTC object.
This hook is not used by atomic drivers, remapping of the legacy DPMS
property is entirely handled in the DRM core.
RETURNS:
0 on success or a negative error code on failure.
reset
Reset connector hardware and software state to off. This function isn’t
called by the core directly, only through drm_mode_config_reset().
It’s not a helper hook only for historical reasons.
Check to see if anything is attached to the connector. The parameter
force is set to false whilst polling, true when checking the
connector due to a user request. force can be used by the driver to
avoid expensive, destructive operations during automated probing.
This callback is optional, if not implemented the connector will be
considered as always being attached.
FIXME:
Note that this hook is only called by the probe helper. It’s not in
the helper library vtable purely for historical reasons. The only DRM
core entry point to probe connector state is fill_modes.
drm_connector_status indicating the connector’s status.
force
This function is called to update internal encoder state when the
connector is forced to a certain state by userspace, either through
the sysfs interfaces or on the kernel cmdline. In that case the
detect callback isn’t called.
FIXME:
Note that this hook is only called by the probe helper. It’s not in
the helper library vtable purely for historical reasons. The only DRM
core entry point to probe connector state is fill_modes.
fill_modes
Entry point for output detection and basic mode validation. The
driver should reprobe the output if needed (e.g. when hotplug
handling is unreliable), add all detected modes to drm_connector.modes
and filter out any the device can’t support in any configuration. It
also needs to filter out any modes wider or higher than the
parameters max_width and max_height indicate.
Drivers using the probe helpers should use
drm_helper_probe_single_connector_modes() or
drm_helper_probe_single_connector_modes_nomerge() to implement this
function.
This is the legacy entry point to update a property attached to the
connector.
This callback is optional if the driver does not support any legacy
driver-private properties. For atomic drivers it is not used because
property handling is done entirely in the DRM core.
RETURNS:
0 on success or a negative error code on failure.
late_register
This optional hook can be used to register additional userspace
interfaces attached to the connector, light backlight control, i2c,
DP aux or similar interfaces. It is called late in the driver load
sequence from drm_connector_register() when registering all the
core drm connector interfaces. Everything added from this callback
should be unregistered in the early_unregister callback.
0 on success, or a negative error code on failure.
early_unregister
This optional hook should be used to unregister the additional
userspace interfaces attached to the connector from
late_register(). It is called from drm_connector_unregister(),
early in the driver unload sequence to disable userspace access
before data structures are torndown.
Clean up connector resources. This is called at driver unload time
through drm_mode_config_cleanup(). It can also be called at runtime
when a connector is being hot-unplugged for drivers that support
connector hotplugging (e.g. DisplayPort MST).
atomic_duplicate_state
Duplicate the current atomic state for this connector and return it.
The core and helpers guarantee that any atomic state duplicated with
this hook and still owned by the caller (i.e. not transferred to the
driver by calling drm_mode_config_funcs.atomic_commit) will be
cleaned up by calling the atomic_destroy_state hook in this
structure.
It is an error to call this hook before drm_connector.state has been
initialized correctly.
NOTE:
If the duplicate state references refcounted resources this hook must
acquire a reference for each of them. The driver must release these
references again in atomic_destroy_state.
RETURNS:
Duplicated atomic state or NULL when the allocation failed.
atomic_destroy_state
Destroy a state duplicated with atomic_duplicate_state and release
or unreference all resources it references
atomic_set_property
Decode a driver-private property value and store the decoded value
into the passed-in state structure. Since the atomic core decodes all
standardized properties (even for extensions beyond the core set of
properties which might not be implemented by all drivers) this
requires drivers to subclass the state structure.
Such driver-private properties should really only be implemented for
truly hardware/vendor specific state. Instead it is preferred to
standardize atomic extension and decode the properties used to expose
such an extension in the core.
Do not call this function directly, use
drm_atomic_connector_set_property() instead.
This callback is optional if the driver does not support any
driver-private atomic properties.
NOTE:
This function is called in the state assembly phase of atomic
modesets, which can be aborted for any reason (including on
userspace’s request to just check whether a configuration would be
possible). Drivers MUST NOT touch any persistent state (hardware or
software) or data structures except the passed in state parameter.
Also since userspace controls in which order properties are set this
function must not do any input validation (since the state update is
incomplete and hence likely inconsistent). Instead any such input
validation must be done in the various atomic_check callbacks.
RETURNS:
0 if the property has been found, -EINVAL if the property isn’t
implemented by the driver (which shouldn’t ever happen, the core only
asks for properties attached to this connector). No other validation
is allowed by the driver. The core already checks that the property
value is within the range (integer, valid enum value, ...) the driver
set when registering the property.
atomic_get_property
Reads out the decoded driver-private property. This is used to
implement the GETCONNECTOR IOCTL.
Do not call this function directly, use
drm_atomic_connector_get_property() instead.
This callback is optional if the driver does not support any
driver-private atomic properties.
RETURNS:
0 on success, -EINVAL if the property isn’t implemented by the
driver (which shouldn’t ever happen, the core only asks for
properties attached to this connector).
atomic_print_state
If driver subclasses structdrm_connector_state, it should implement
this optional hook for printing additional driver specific state.
Do not call this directly, use drm_atomic_connector_print_state()
instead.
Description
Each CRTC may have one or more connectors attached to it. The functions
below allow the core DRM code to control connectors, enumerate available modes,
etc.
human readable name, can be overwritten by the driver
mutex
Lock for general connector state, but currently only protects
registered. Most of the connector state is still protected by
drm_mode_config.mutex.
index
Compacted connector index, which matches the position inside
the mode_config.list for drivers not supporting hot-add/removing. Can
be used as an array index. It is invariant over the lifetime of the
connector.
connector_type
one of the DRM_MODE_CONNECTOR_<foo> types from drm_mode.h
connector_type_id
index into connector type enum
interlace_allowed
can this connector handle interlaced modes?
doublescan_allowed
can this connector handle doublescan?
stereo_allowed
can this connector handle stereo modes?
ycbcr_420_allowed
This bool indicates if this connector is
capable of handling YCBCR 420 output. While parsing the EDID
blocks, its very helpful to know, if the source is capable of
handling YCBCR 420 outputs.
registered
Is this connector exposed (registered) with userspace?
Protected by mutex.
modes
Modes available on this connector (from fill_modes() + user).
Protected by drm_mode_config.mutex.
status
One of the drm_connector_status enums (connected, not, or unknown).
Protected by drm_mode_config.mutex.
probed_modes
These are modes added by probing with DDC or the BIOS, before
filtering is applied. Used by the probe helpers. Protected by
drm_mode_config.mutex.
display_info
Display information is filled from EDID information
when a display is detected. For non hot-pluggable displays such as
flat panels in embedded systems, the driver should initialize the
drm_display_info.width_mm and drm_display_info.height_mm fields
with the physical size of the display.
Optional atomic property to control the upscaling.
path_blob_ptr
DRM blob property data for the DP MST path property.
tile_blob_ptr
DRM blob property data for the tile property (used mostly by DP MST).
This is meant for screens which are driven through separate display
pipelines represented by drm_crtc, which might not be running with
genlocked clocks. For tiled panels which are genlocked, like
dual-link LVDS or dual-link DSI, the driver should try to not expose
the tiling and virtualize both drm_crtc and drm_plane if needed.
polled
Connector polling mode, a combination of
DRM_CONNECTOR_POLL_HPD
The connector generates hotplug events and doesn’t need to be
periodically polled. The CONNECT and DISCONNECT flags must not
be set together with the HPD flag.
DRM_CONNECTOR_POLL_CONNECT
Periodically poll the connector for connection.
DRM_CONNECTOR_POLL_DISCONNECT
Periodically poll the connector for disconnection.
Set to 0 for connectors that don’t support connection status
discovery.
dpms
current dpms state
helper_private
mid-layer private data
cmdline_mode
mode line parsed from the kernel cmdline for this connector
force
a DRM_FORCE_<foo> state for forced mode sets
override_edid
has the EDID been overwritten through debugfs for testing?
encoder_ids
valid encoders for this connector
encoder
Currently bound encoder driving this connector, if any.
Only really meaningful for non-atomic drivers. Atomic drivers should
instead look at drm_connector_state.best_encoder, and in case they
need the CRTC driving this output, drm_connector_state.crtc.
eld
EDID-like data, if present
latency_present
AV delay info from ELD, if found
video_latency
video latency info from ELD, if found
audio_latency
audio latency info from ELD, if found
null_edid_counter
track sinks that give us all zeros for the EDID
bad_edid_counter
track sinks that give us an EDID with invalid checksum
List used only by drm_connector_iter to be able to clean up a
connector from any context, in conjunction with
drm_mode_config.connector_free_work.
Description
Each connector may be connected to one or more CRTCs, or may be clonable by
another connector if they can share a CRTC. Each connector also has a specific
position in the broader display (referred to as a ‘screen’ though it could
span multiple monitors).
Note that connector is only valid within the list body, if you want to use
connector after calling drm_connector_list_iter_end() then you need to grab
your own reference first using drm_connector_get().
int drm_connector_init(struct drm_device * dev, struct drm_connector * connector, const struct drm_connector_funcs * funcs, int connector_type)¶
Init a preallocated connector
Parameters
structdrm_device*dev
DRM device
structdrm_connector*connector
the connector to init
conststructdrm_connector_funcs*funcs
callbacks for this connector
intconnector_type
user visible type of the connector
Description
Initialises a preallocated connector. Connectors should be
subclassed as part of driver connector objects.
This function links up a connector to an encoder. Note that the routing
restrictions between encoders and crtcs are exposed to userspace through the
possible_clones and possible_crtcs bitmasks.
Tears down iter and releases any resources (like drm_connector references)
acquired while walking the list. This must always be called, both when the
iteration completes fully or when it was aborted without walking the entire
list.
Note you could abuse this and return something out of bounds, but that
would be a caller error. No unscrubbed user data should make it here.
int drm_display_info_set_bus_formats(struct drm_display_info * info, const u32 * formats, unsigned int num_formats)¶
set the supported bus formats
Parameters
structdrm_display_info*info
display info to store bus formats in
constu32*formats
array containing the supported bus formats
unsignedintnum_formats
the number of entries in the fmts array
Description
Store the supported bus formats in display info structure.
See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h for
a full list of available formats.
int drm_mode_create_dvi_i_properties(struct drm_device * dev)¶
create DVI-I specific connector properties
Parameters
structdrm_device*dev
DRM device
Description
Called by a driver the first time a DVI-I connector is made.
int drm_mode_create_tv_properties(struct drm_device * dev, unsigned int num_modes, const char *const modes)¶
create TV specific connector properties
Parameters
structdrm_device*dev
DRM device
unsignedintnum_modes
number of different TV formats (modes) supported
constchar*constmodes
array of pointers to strings containing name of each format
Description
Called by a driver’s TV initialization routine, this function creates
the TV specific connector properties for a given device. Caller is
responsible for allocating a list of format names and passing them to
this routine.
int drm_mode_create_scaling_mode_property(struct drm_device * dev)¶
create scaling mode property
Parameters
structdrm_device*dev
DRM device
Description
Called by a driver the first time it’s needed, must be attached to desired
connectors.
int drm_mode_create_aspect_ratio_property(struct drm_device * dev)¶
create aspect ratio property
Parameters
structdrm_device*dev
DRM device
Description
Called by a driver the first time it’s needed, must be attached to desired
connectors.
Return
Zero on success, negative errno on failure.
int drm_mode_create_suggested_offset_properties(struct drm_device * dev)¶
create suggests offset properties
Parameters
structdrm_device*dev
DRM device
Description
Create the the suggested x/y offset property for connectors.
int drm_mode_connector_set_path_property(struct drm_connector * connector, const char * path)¶
set tile property on connector
Parameters
structdrm_connector*connector
connector to set property on.
constchar*path
path to use for property; must not be NULL.
Description
This creates a property to expose to userspace to specify a
connector path. This is mainly used for DisplayPort MST where
connectors have a topology and we want to allow userspace to give
them more meaningful names.
Return
Zero on success, negative errno on failure.
int drm_mode_connector_set_tile_property(struct drm_connector * connector)¶
set tile property on connector
Parameters
structdrm_connector*connector
connector to set property on.
Description
This looks up the tile information for a connector, and creates a
property for userspace to parse if it exists. The property is of
the form of 8 integers using ‘:’ as a separator.
Return
Zero on success, errno on failure.
int drm_mode_connector_update_edid_property(struct drm_connector * connector, const struct edid * edid)¶
update the edid property of a connector
Parameters
structdrm_connector*connector
drm connector
conststructedid*edid
new value of the edid property
Description
This function creates a new blob modeset object and assigns its id to the
connector’s edid property.
new value of link status property (0: Good, 1: Bad)
Description
In usual working scenario, this link status property will always be set to
“GOOD”. If something fails during or after a mode set, the kernel driver
may set this link status property to “BAD”. The caller then needs to send a
hotplug uevent for userspace to re-check the valid modes through
GET_CONNECTOR_IOCTL and retry modeset.
Note
Drivers cannot rely on userspace to support this property and
issue a modeset. As such, they may choose to handle issues (like
re-training a link) without userspace’s intervention.
The reason for adding this property is to handle link training failures, but
it is not limited to DP or link training. For example, if we implement
asynchronous setcrtc, this property can be used to report any failures in that.
int drm_connector_init_panel_orientation_property(struct drm_connector * connector, int width, int height)¶
initialize the connecters panel_orientation property
Parameters
structdrm_connector*connector
connector for which to init the panel-orientation property.
intwidth
width in pixels of the panel, used for panel quirk detection
intheight
height in pixels of the panel, used for panel quirk detection
Description
This function should only be called for built-in panels, after setting
connector->display_info.panel_orientation first (if known).
This function will check for platform specific (e.g. DMI based) quirks
overriding display_info.panel_orientation first, then if panel_orientation
is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
“panel orientation” property to the connector.
Encoders represent the connecting element between the CRTC (as the overall
pixel pipeline, represented by structdrm_crtc) and the connectors (as the
generic sink entity, represented by structdrm_connector). An encoder takes
pixel data from a CRTC and converts it to a format suitable for any attached
connector. Encoders are objects exposed to userspace, originally to allow
userspace to infer cloning and connector/CRTC restrictions. Unfortunately
almost all drivers get this wrong, making the uabi pretty much useless. On
top of that the exposed restrictions are too simple for today’s hardware, and
the recommended way to infer restrictions is by using the
DRM_MODE_ATOMIC_TEST_ONLY flag for the atomic IOCTL.
Otherwise encoders aren’t used in the uapi at all (any modeset request from
userspace directly connects a connector with a CRTC), drivers are therefore
free to use them however they wish. Modeset helper libraries make strong use
of encoders to facilitate code sharing. But for more complex settings it is
usually better to move shared code into a separate drm_bridge. Compared to
encoders, bridges also have the benefit of being purely an internal
abstraction since they are not exposed to userspace at all.
Reset encoder hardware and software state to off. This function isn’t
called by the core directly, only through drm_mode_config_reset().
It’s not a helper hook only for historical reasons.
destroy
Clean up encoder resources. This is only called at driver unload time
through drm_mode_config_cleanup() since an encoder cannot be
hotplugged in DRM.
late_register
This optional hook can be used to register additional userspace
interfaces attached to the encoder like debugfs interfaces.
It is called late in the driver load sequence from drm_dev_register().
Everything added from this callback should be unregistered in
the early_unregister callback.
Returns:
0 on success, or a negative error code on failure.
early_unregister
This optional hook should be used to unregister the additional
userspace interfaces attached to the encoder from
late_register. It is called from drm_dev_unregister(),
early in the driver unload sequence to disable userspace access
before data structures are torndown.
human readable name, can be overwritten by the driver
encoder_type
One of the DRM_MODE_ENCODER_<foo> types in drm_mode.h. The following
encoder types are defined thus far:
DRM_MODE_ENCODER_DAC for VGA and analog on DVI-I/DVI-A.
DRM_MODE_ENCODER_TMDS for DVI, HDMI and (embedded) DisplayPort.
DRM_MODE_ENCODER_LVDS for display panels, or in general any panel
with a proprietary parallel connector.
DRM_MODE_ENCODER_TVDAC for TV output (Composite, S-Video,
Component, SCART).
DRM_MODE_ENCODER_VIRTUAL for virtual machine displays
DRM_MODE_ENCODER_DSI for panels connected using the DSI serial bus.
DRM_MODE_ENCODER_DPI for panels connected using the DPI parallel
bus.
DRM_MODE_ENCODER_DPMST for special fake encoders used to allow
mutliple DP MST streams to share one physical encoder.
index
Position inside the mode_config.list, can be used as an array
index. It is invariant over the lifetime of the encoder.
possible_crtcs
Bitmask of potential CRTC bindings, using
drm_crtc_index() as the index into the bitfield. The driver must set
the bits for all drm_crtc objects this encoder can be connected to
before calling drm_encoder_init().
In reality almost every driver gets this wrong.
Note that since CRTC objects can’t be hotplugged the assigned indices
are stable and hence known before registering all objects.
possible_clones
Bitmask of potential sibling encoders for cloning,
using drm_encoder_index() as the index into the bitfield. The driver
must set the bits for all drm_encoder objects which can clone a
drm_crtc together with this encoder before calling
drm_encoder_init(). Drivers should set the bit representing the
encoder itself, too. Cloning bits should be set such that when two
encoders can be used in a cloned configuration, they both should have
each another bits set.
In reality almost every driver gets this wrong.
Note that since encoder objects can’t be hotplugged the assigned indices
are stable and hence known before registering all objects.
crtc
Currently bound CRTC, only really meaningful for non-atomic
drivers. Atomic drivers should instead check
drm_connector_state.crtc.
bridge
bridge associated to the encoder
funcs
control functions
helper_private
mid-layer private data
Description
CRTCs drive pixels to encoders, which convert them into signals
appropriate for a given connector or set of connectors.
unsigned int drm_encoder_index(struct drm_encoder * encoder)¶
find the index of a registered encoder
Parameters
structdrm_encoder*encoder
encoder to find index for
Description
Given a registered encoder, return the index of that encoder within a DRM
device’s list of encoders.
printf style format string for the encoder name, or NULL for default name
...
variable arguments
Description
Initialises a preallocated encoder. Encoder should be subclassed as part of
driver encoder objects. At driver unload time drm_encoder_cleanup() should be
called from the driver’s drm_encoder_funcs.destroy hook.
A KMS device is abstracted and exposed as a set of planes, CRTCs,
encoders and connectors. KMS drivers must thus create and initialize all
those objects at load time after initializing mode setting.
A CRTC is an abstraction representing a part of the chip that contains a
pointer to a scanout buffer. Therefore, the number of CRTCs available
determines how many independent scanout buffers can be active at any
given time. The CRTC structure contains several fields to support this:
a pointer to some video memory (abstracted as a frame buffer object), a
display mode, and an (x, y) offset into the video memory to support
panning or configurations where one piece of video memory spans multiple
CRTCs.
A KMS device must create and register at least one struct
structdrm_crtc instance. The instance is
allocated and zeroed by the driver, possibly as part of a larger
structure, and registered with a call to drm_crtc_init()
with a pointer to CRTC functions.
The DRM core manages its objects’ lifetime. When an object is not needed
anymore the core calls its destroy function, which must clean up and
free every resource allocated for the object. Every
drm_*_init() call must be matched with a corresponding
drm_*_cleanup() call to cleanup CRTCs
(drm_crtc_cleanup()), planes
(drm_plane_cleanup()), encoders
(drm_encoder_cleanup()) and connectors
(drm_connector_cleanup()). Furthermore, connectors that
have been added to sysfs must be removed by a call to
drm_connector_unregister() before calling
drm_connector_cleanup().
voidintel_crt_init(structdrm_device*dev){structdrm_connector*connector;structintel_output*intel_output;intel_output=kzalloc(sizeof(structintel_output),GFP_KERNEL);if(!intel_output)return;connector=&intel_output->base;drm_connector_init(dev,&intel_output->base,&intel_crt_connector_funcs,DRM_MODE_CONNECTOR_VGA);drm_encoder_init(dev,&intel_output->enc,&intel_crt_enc_funcs,DRM_MODE_ENCODER_DAC);drm_mode_connector_attach_encoder(&intel_output->base,&intel_output->enc);/* Set up the DDC bus. */intel_output->ddc_bus=intel_i2c_create(dev,GPIOA,"CRTDDC_A");if(!intel_output->ddc_bus){dev_printk(KERN_ERR,&dev->pdev->dev,"DDC bus registration ""failed.\n");return;}intel_output->type=INTEL_OUTPUT_ANALOG;connector->interlace_allowed=0;connector->doublescan_allowed=0;drm_encoder_helper_add(&intel_output->enc,&intel_crt_helper_funcs);drm_connector_helper_add(connector,&intel_crt_connector_helper_funcs);drm_connector_register(connector);}
In the example above (taken from the i915 driver), a CRTC, connector and
encoder combination is created. A device-specific i2c bus is also
created for fetching EDID data and performing monitor detection. Once
the process is complete, the new connector is registered with sysfs to
make its properties available to applications.
As KMS moves toward more fine grained locking, and atomic ioctl where
userspace can indirectly control locking order, it becomes necessary
to use ww_mutex and acquire-contexts to avoid deadlocks. But because
the locking is more distributed around the driver code, we want a bit
of extra utility/tracking out of our acquire-ctx. This is provided
by structdrm_modeset_lock and structdrm_modeset_acquire_ctx.
For basic principles of ww_mutex, see: Documentation/locking/ww-mutex-design.txt
The basic usage pattern is to:
drm_modeset_acquire_init(ctx, DRM_MODESET_ACQUIRE_INTERRUPTIBLE)
retry:
foreach (lock in random_ordered_set_of_locks) {
ret = drm_modeset_lock(lock, ctx)
if (ret == -EDEADLK) {
ret = drm_modeset_backoff(ctx);
if (!ret)
goto retry;
}
if (ret)
goto out;
}
... do stuff ...
out:
drm_modeset_drop_locks(ctx);
drm_modeset_acquire_fini(ctx);
On top of these per-object locks using ww_mutex there’s also an overall
drm_mode_config.mutex, for protecting everything else. Mostly this means
probe state of connectors, and preventing hotplug add/removal of connectors.
Finally there’s a bunch of dedicated locks to protect drm core internal
lists and lookup data structures.
This function takes all modeset locks, suitable where a more fine-grained
scheme isn’t (yet) implemented. Locks must be dropped by calling the
drm_modeset_unlock_all() function.
This function is deprecated. It allocates a lock acquisition context and
stores it in drm_device.mode_config. This facilitate conversion of
existing code because it removes the need to manually deal with the
acquisition context, but it is also brittle because the context is global
and care must be taken not to nest calls. New code should use the
drm_modeset_lock_all_ctx() function and pass in the context explicitly.
This function drops all modeset locks taken by a previous call to the
drm_modeset_lock_all() function.
This function is deprecated. It uses the lock acquisition context stored
in drm_device.mode_config. This facilitates conversion of existing
code because it removes the need to manually deal with the acquisition
context, but it is also brittle because the context is global and care must
be taken not to nest calls. New code should pass the acquisition context
directly to the drm_modeset_drop_locks() function.
If deadlock is detected (ie. drm_modeset_lock() returns -EDEADLK),
you must call this function to drop all currently held locks and
block until the contended lock becomes available.
This function returns 0 on success, or -ERESTARTSYS if this context
is initialized with DRM_MODESET_ACQUIRE_INTERRUPTIBLE and the
wait has been interrupted.
If ctx is not NULL, then its ww acquire context is used and the
lock will be tracked by the context and can be released by calling
drm_modeset_drop_locks(). If -EDEADLK is returned, this means a
deadlock scenario has been detected and it is an error to attempt
to take any more locks without first calling drm_modeset_backoff().
If the ctx is not NULL and initialized with
DRM_MODESET_ACQUIRE_INTERRUPTIBLE, this function will fail with
-ERESTARTSYS when interrupted.
If ctx is NULL then the function call behaves like a normal,
uninterruptible non-nesting mutex_lock() call.
int drm_modeset_lock_single_interruptible(struct drm_modeset_lock * lock)¶
take a single modeset lock
Parameters
structdrm_modeset_lock*lock
lock to take
Description
This function behaves as drm_modeset_lock() with a NULL context,
but performs interruptible waits.
This function returns 0 on success, or -ERESTARTSYS when interrupted.
This function takes all modeset locks, suitable where a more fine-grained
scheme isn’t (yet) implemented.
Unlike drm_modeset_lock_all(), it doesn’t take the drm_mode_config.mutex
since that lock isn’t required for modeset state changes. Callers which
need to grab that lock too need to do so outside of the acquire context
ctx.
Locks acquired with this function should be released by calling the
drm_modeset_drop_locks() function on ctx.
Properties as represented by drm_property are used to extend the modeset
interface exposed to userspace. For the atomic modeset IOCTL properties are
even the only way to transport metadata about the desired new modeset
configuration from userspace to the kernel. Properties have a well-defined
value range, which is enforced by the drm core. See the documentation of the
flags member of structdrm_property for an overview of the different
property types and ranges.
Property values are only 64bit. To support bigger piles of data (like gamma
tables, color correction matrices or large structures) a property can instead
point at a drm_property_blob with that additional data.
Properties are defined by their symbolic name, userspace must keep a
per-object mapping from those names to the property ID used in the atomic
IOCTL and in the get/set property IOCTL.
Property flags and type. A property needs to be one of the following
types:
DRM_MODE_PROP_RANGE
Range properties report their minimum and maximum admissible unsigned values.
The KMS core verifies that values set by application fit in that
range. The range is unsigned. Range properties are created using
drm_property_create_range().
DRM_MODE_PROP_SIGNED_RANGE
Range properties report their minimum and maximum admissible unsigned values.
The KMS core verifies that values set by application fit in that
range. The range is signed. Range properties are created using
drm_property_create_signed_range().
DRM_MODE_PROP_ENUM
Enumerated properties take a numerical value that ranges from 0 to
the number of enumerated values defined by the property minus one,
and associate a free-formed string name to each value. Applications
can retrieve the list of defined value-name pairs and use the
numerical value to get and set property instance values. Enum
properties are created using drm_property_create_enum().
DRM_MODE_PROP_BITMASK
Bitmask properties are enumeration properties that additionally
restrict all enumerated values to the 0..63 range. Bitmask property
instance values combine one or more of the enumerated bits defined
by the property. Bitmask properties are created using
drm_property_create_bitmask().
Object properties work like blob properties, but in a more
general fashion. They are limited to atomic drivers and must have
the DRM_MODE_PROP_ATOMIC flag set.
DRM_MODE_PROP_BLOB
Blob properties store a binary blob without any format restriction.
The binary blobs are created as KMS standalone objects, and blob
property instance values store the ID of their associated blob
object. Blob properties are created by calling
drm_property_create() with DRM_MODE_PROP_BLOB as the type.
Actual blob objects to contain blob data are created using
drm_property_create_blob(), or through the corresponding IOCTL.
Besides the built-in limit to only accept blob objects blob
properties work exactly like object properties. The only reasons
blob properties exist is backwards compatibility with existing
userspace.
In addition a property can have any combination of the below flags:
DRM_MODE_PROP_ATOMIC
Set for properties which encode atomic modeset state. Such
properties are not exposed to legacy userspace.
DRM_MODE_PROP_IMMUTABLE
Set for properties where userspace cannot be changed by
userspace. The kernel is allowed to update the value of these
properties. This is generally used to expose probe state to
usersapce, e.g. the EDID, or the connector path property on DP
MST sinks.
name
symbolic name of the properties
num_values
size of the values array.
values
Array with limits and values for the property. The
interpretation of these limits is dependent upon the type per flags.
dev
DRM device
enum_list
List of drm_prop_enum_list structures with the symbolic names for
enum and bitmask values.
Description
This structure represent a modeset object property. It combines both the name
of the property with the set of permissible values. This means that when a
driver wants to use a property with the same name on different objects, but
with different value ranges, then it must create property for each one. An
example would be rotation of drm_plane, when e.g. the primary plane cannot
be rotated. But if both the name and the value range match, then the same
property structure can be instantiated multiple times for the same object.
Userspace must be able to cope with this and cannot assume that the same
symbolic property will have the same modeset object ID on all modeset
objects.
Properties are created by one of the special functions, as explained in
detail in the flags structure member.
Properties are also used as the generic metadatatransport for the atomic
IOCTL. Everything that was set directly in structures in the legacy modeset
IOCTLs (like the plane source or destination windows, or e.g. the links to
the CRTC) is exposed as a property with the DRM_MODE_PROP_ATOMIC flag set.
Creates a new blob property for a specified DRM device, optionally
copying data. Note that blob properties are meant to be invariant, hence the
data must be filled out before the blob is used as the value of any property.
Return
New blob property with a single reference on success, or an ERR_PTR
value on failure.
If successful, this takes an additional reference to the blob property.
callers need to make sure to eventually unreference the returned property
again, using drm_property_blob_put().
optional property holding blob ID
return 0 on success or error on failure
Description
This function will replace a global property in the blob list, optionally
updating a property which holds the ID of that property.
If length is 0 or data is NULL, no new blob will be created, and the holding
property, if specified, will be set to 0.
Access to the replace pointer is assumed to be protected by the caller, e.g.
by holding the relevant modesetting object lock for its parent.
For example, a drm_connector has a ‘PATH’ property, which contains the ID
of a blob property with the value of the MST path information. Calling this
function with replace pointing to the connector’s path_blob_ptr, length and
data set for the new path information, obj_holds_id set to the connector’s
base object, and prop_holds_id set to the path property name, will perform
a completely atomic update. The access to path_blob_ptr is protected by the
caller holding a lock on the connector.
DRM connectors have a few standardized properties:
EDID:
Blob property which contains the current EDID read from the sink. This
is useful to parse sink identification information like vendor, model
and serial. Drivers should update this property by calling
drm_mode_connector_update_edid_property(), usually after having parsed
the EDID using drm_add_edid_modes(). Userspace cannot change this
property.
DPMS:
Legacy property for setting the power state of the connector. For atomic
drivers this is only provided for backwards compatibility with existing
drivers, it remaps to controlling the “ACTIVE” property on the CRTC the
connector is linked to. Drivers should never set this property directly,
it is handled by the DRM core by calling the drm_connector_funcs.dpms
callback. For atomic drivers the remapping to the “ACTIVE” property is
implemented in the DRM core. This is the only standard connector
property that userspace can change.
Note that this property cannot be set through the MODE_ATOMIC ioctl,
userspace must use “ACTIVE” on the CRTC instead.
WARNING:
For userspace also running on legacy drivers the “DPMS” semantics are a
lot more complicated. First, userspace cannot rely on the “DPMS” value
returned by the GETCONNECTOR actually reflecting reality, because many
drivers fail to update it. For atomic drivers this is taken care of in
drm_atomic_helper_update_legacy_modeset_state().
The second issue is that the DPMS state is only well-defined when the
connector is connected to a CRTC. In atomic the DRM core enforces that
“ACTIVE” is off in such a case, no such checks exists for “DPMS”.
Finally, when enabling an output using the legacy SETCONFIG ioctl then
“DPMS” is forced to ON. But see above, that might not be reflected in
the software value on legacy drivers.
Summarizing: Only set “DPMS” when the connector is known to be enabled,
assume that a successful SETCONFIG call also sets “DPMS” to on, and
never read back the value of “DPMS” because it can be incorrect.
PATH:
Connector path property to identify how this sink is physically
connected. Used by DP MST. This should be set by calling
drm_mode_connector_set_path_property(), in the case of DP MST with the
path property the MST manager created. Userspace cannot change this
property.
TILE:
Connector tile group property to indicate how a set of DRM connector
compose together into one logical screen. This is used by both high-res
external screens (often only using a single cable, but exposing multiple
DP MST sinks), or high-res integrated panels (like dual-link DSI) which
are not gen-locked. Note that for tiled panels which are genlocked, like
dual-link LVDS or dual-link DSI, the driver should try to not expose the
tiling and virtualize both drm_crtc and drm_plane if needed. Drivers
should update this value using drm_mode_connector_set_tile_property().
Userspace cannot change this property.
link-status:
Connector link-status property to indicate the status of link. The default
value of link-status is “GOOD”. If something fails during or after modeset,
the kernel driver may set this to “BAD” and issue a hotplug uevent. Drivers
should update this value using drm_mode_connector_set_link_status_property().
non_desktop:
Indicates the output should be ignored for purposes of displaying a
standard desktop environment or console. This is most likely because
the output device is not rectilinear.
Connectors also have one standardized atomic property:
CRTC_ID:
Mode object ID of the drm_crtc this connector should be connected to.
Connectors for LCD panels may also have one standardized property:
panel orientation:
On some devices the LCD panel is mounted in the casing in such a way
that the up/top side of the panel does not match with the top side of
the device. Userspace can use this property to check for this.
Note that input coordinates from touchscreens (input devices with
INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
coordinates, so if userspace rotates the picture to adjust for
the orientation it must also apply the same transformation to the
touchscreen input coordinates.
The basic plane composition model supported by standard plane properties only
has a source rectangle (in logical pixels within the drm_framebuffer), with
sub-pixel accuracy, which is scaled up to a pixel-aligned destination
rectangle in the visible area of a drm_crtc. The visible area of a CRTC is
defined by the horizontal and vertical visible pixels (stored in hdisplay
and vdisplay) of the requested mode (stored in drm_crtc_state.mode). These
two rectangles are both stored in the drm_plane_state.
For the atomic ioctl the following standard (atomic) properties on the plane object
encode the basic plane composition model:
SRC_X:
X coordinate offset for the source rectangle within the
drm_framebuffer, in 16.16 fixed point. Must be positive.
SRC_Y:
Y coordinate offset for the source rectangle within the
drm_framebuffer, in 16.16 fixed point. Must be positive.
SRC_W:
Width for the source rectangle within the drm_framebuffer, in 16.16
fixed point. SRC_X plus SRC_W must be within the width of the source
framebuffer. Must be positive.
SRC_H:
Height for the source rectangle within the drm_framebuffer, in 16.16
fixed point. SRC_Y plus SRC_H must be within the height of the source
framebuffer. Must be positive.
CRTC_X:
X coordinate offset for the destination rectangle. Can be negative.
CRTC_Y:
Y coordinate offset for the destination rectangle. Can be negative.
CRTC_W:
Width for the destination rectangle. CRTC_X plus CRTC_W can extend past
the currently visible horizontal area of the drm_crtc.
CRTC_H:
Height for the destination rectangle. CRTC_Y plus CRTC_H can extend past
the currently visible vertical area of the drm_crtc.
FB_ID:
Mode object ID of the drm_framebuffer this plane should scan out.
CRTC_ID:
Mode object ID of the drm_crtc this plane should be connected to.
Note that the source rectangle must fully lie within the bounds of the
drm_framebuffer. The destination rectangle can lie outside of the visible
area of the current mode of the CRTC. It must be apprpriately clipped by the
driver, which can be done by calling drm_plane_helper_check_update(). Drivers
are also allowed to round the subpixel sampling positions appropriately, but
only to the next full pixel. No pixel outside of the source rectangle may
ever be sampled, which is important when applying more sophisticated
filtering than just a bilinear one when scaling. The filtering mode when
scaling is unspecified.
On top of this basic transformation additional properties can be exposed by
the driver:
Rotation is set up with drm_plane_create_rotation_property(). It adds a
rotation and reflection step between the source and destination rectangles.
Without this property the rectangle is only scaled, but not rotated or
reflected.
Note that all the property extensions described here apply either to the
plane or the CRTC (e.g. for the background color, which currently is not
exposed and assumed to be black).
int drm_plane_create_rotation_property(struct drm_plane * plane, unsigned int rotation, unsigned int supported_rotations)¶
create a new rotation property
Parameters
structdrm_plane*plane
drm plane
unsignedintrotation
initial value of the rotation property
unsignedintsupported_rotations
bitmask of supported rotations and reflections
Description
This creates a new property with the selected support for transformations.
Since a rotation by 180° degress is the same as reflecting both along the x
and the y axis the rotation property is somewhat redundant. Drivers can use
drm_rotation_simplify() to normalize values of this property.
The property exposed to userspace is a bitmask property (see
drm_property_create_bitmask()) called “rotation” and has the following
bitmask enumaration values:
DRM_MODE_ROTATE_0:
“rotate-0”
DRM_MODE_ROTATE_90:
“rotate-90”
DRM_MODE_ROTATE_180:
“rotate-180”
DRM_MODE_ROTATE_270:
“rotate-270”
DRM_MODE_REFLECT_X:
“reflect-x”
DRM_MODE_REFLECT_Y:
“reflect-y”
Rotation is the specified amount in degrees in counter clockwise direction,
the X and Y axis are within the source rectangle, i.e. the X/Y axis before
rotation. After reflection, the rotation is applied to the image sampled from
the source rectangle, before scaling it to fit the destination rectangle.
unsigned int drm_rotation_simplify(unsigned int rotation, unsigned int supported_rotations)¶
Try to simplify the rotation
Parameters
unsignedintrotation
Rotation to be simplified
unsignedintsupported_rotations
Supported rotations
Description
Attempt to simplify the rotation to a form that is supported.
Eg. if the hardware supports everything except DRM_MODE_REFLECT_X
one could call this function like this:
to eliminate the DRM_MODE_ROTATE_X flag. Depending on what kind of
transforms the hardware supports, this function may not
be able to produce a supported transform, so the caller should
check the result afterwards.
int drm_plane_create_zpos_property(struct drm_plane * plane, unsigned int zpos, unsigned int min, unsigned int max)¶
create mutable zpos property
Parameters
structdrm_plane*plane
drm plane
unsignedintzpos
initial value of zpos property
unsignedintmin
minimal possible value of zpos property
unsignedintmax
maximal possible value of zpos property
Description
This function initializes generic mutable zpos property and enables support
for it in drm core. Drivers can then attach this property to planes to enable
support for configurable planes arrangement during blending operation.
Drivers that attach a mutable zpos property to any plane should call the
drm_atomic_normalize_zpos() helper during their implementation of
drm_mode_config_funcs.atomic_check(), which will update the normalized zpos
values and store them in drm_plane_state.normalized_zpos. Usually min
should be set to 0 and max to maximal number of planes for given crtc - 1.
If zpos of some planes cannot be changed (like fixed background or
cursor/topmost planes), driver should adjust min/max values and assign those
planes immutable zpos property with lower or higher values (for more
information, see drm_plane_create_zpos_immutable_property() function). In such
case driver should also assign proper initial zpos values for all planes in
its plane_reset() callback, so the planes will be always sorted properly.
The property exposed to userspace is called “zpos”.
Return
Zero on success, negative errno on failure.
int drm_plane_create_zpos_immutable_property(struct drm_plane * plane, unsigned int zpos)¶
create immuttable zpos property
Parameters
structdrm_plane*plane
drm plane
unsignedintzpos
value of zpos property
Description
This function initializes generic immutable zpos property and enables
support for it in drm core. Using this property driver lets userspace
to get the arrangement of the planes for blending operation and notifies
it that the hardware (or driver) doesn’t support changing of the planes’
order. For mutable zpos see drm_plane_create_zpos_property().
The property exposed to userspace is called “zpos”.
Return
Zero on success, negative errno on failure.
int drm_atomic_normalize_zpos(struct drm_device * dev, struct drm_atomic_state * state)¶
calculate normalized zpos values for all crtcs
Parameters
structdrm_device*dev
DRM device
structdrm_atomic_state*state
atomic state of DRM device
Description
This function calculates normalized zpos value for all modified planes in
the provided atomic state of DRM device.
For every CRTC this function checks new states of all planes assigned to
it and calculates normalized zpos value for these planes. Planes are compared
first by their zpos values, then by plane id (if zpos is equal). The plane
with lowest zpos value is at the bottom. The drm_plane_state.normalized_zpos
is then filled with unique values from 0 to number of active planes in crtc
minus one.
Color management or color space adjustments is supported through a set of 5
properties on the drm_crtc object. They are set up by calling
drm_crtc_enable_color_mgmt().
“DEGAMMA_LUTâ??:
Blob property to set the degamma lookup table (LUT) mapping pixel data
from the framebuffer before it is given to the transformation matrix.
The data is interpreted as an array of structdrm_color_lut elements.
Hardware might choose not to use the full precision of the LUT elements
nor use all the elements of the LUT (for example the hardware might
choose to interpolate between LUT[0] and LUT[4]).
Setting this to NULL (blob property value set to 0) means a
linear/pass-thru gamma table should be used. This is generally the
driver boot-up state too. Drivers can access this blob through
drm_crtc_state.degamma_lut.
â??DEGAMMA_LUT_SIZEâ??:
Unsinged range property to give the size of the lookup table to be set
on the DEGAMMA_LUT property (the size depends on the underlying
hardware). If drivers support multiple LUT sizes then they should
publish the largest size, and sub-sample smaller sized LUTs (e.g. for
split-gamma modes) appropriately.
â??CTMâ??:
Blob property to set the current transformation matrix (CTM) apply to
pixel data after the lookup through the degamma LUT and before the
lookup through the gamma LUT. The data is interpreted as a struct
drm_color_ctm.
Setting this to NULL (blob property value set to 0) means a
unit/pass-thru matrix should be used. This is generally the driver
boot-up state too. Drivers can access the blob for the color conversion
matrix through drm_crtc_state.ctm.
â??GAMMA_LUTâ??:
Blob property to set the gamma lookup table (LUT) mapping pixel data
after the transformation matrix to data sent to the connector. The
data is interpreted as an array of structdrm_color_lut elements.
Hardware might choose not to use the full precision of the LUT elements
nor use all the elements of the LUT (for example the hardware might
choose to interpolate between LUT[0] and LUT[4]).
Setting this to NULL (blob property value set to 0) means a
linear/pass-thru gamma table should be used. This is generally the
driver boot-up state too. Drivers can access this blob through
drm_crtc_state.gamma_lut.
â??GAMMA_LUT_SIZEâ??:
Unsigned range property to give the size of the lookup table to be set
on the GAMMA_LUT property (the size depends on the underlying hardware).
If drivers support multiple LUT sizes then they should publish the
largest size, and sub-sample smaller sized LUTs (e.g. for split-gamma
modes) appropriately.
This function lets the driver enable the color correction
properties on a CRTC. This includes 3 degamma, csc and gamma
properties that userspace can set and 2 size properties to inform
the userspace of the lut sizes. Each of the properties are
optional. The gamma and degamma properties are only attached if
their size is not 0 and ctm_property is only attached if has_ctm is
true.
int drm_mode_crtc_set_gamma_size(struct drm_crtc * crtc, int gamma_size)¶
set the gamma table size
Parameters
structdrm_crtc*crtc
CRTC to set the gamma table size for
intgamma_size
size of the gamma table
Description
Drivers which support gamma tables should set this to the supported gamma
table size when initializing the CRTC. Currently the drm core only supports a
fixed gamma table size.
Tile groups are used to represent tiled monitors with a unique integer
identifier. Tiled monitors using DisplayID v1.3 have a unique 8-byte handle,
we store this in a tile group, so we have a common identifier for all tiles
in a monitor group. The property is called “TILE”. Drivers can manage tile
groups using drm_mode_create_tile_group(), drm_mode_put_tile_group() and
drm_mode_get_tile_group(). But this is only needed for internal panels where
the tile group information is exposed through a non-standard way.
Explicit fencing allows userspace to control the buffer synchronization
between devices. A Fence or a group of fences are transfered to/from
userspace using Sync File fds and there are two DRM properties for that.
IN_FENCE_FD on each DRM Plane to send fences to the kernel and
OUT_FENCE_PTR on each DRM CRTC to receive fences from the kernel.
As a contrast, with implicit fencing the kernel keeps track of any
ongoing rendering, and automatically ensures that the atomic update waits
for any pending rendering to complete. For shared buffers represented with
a structdma_buf this is tracked in structreservation_object.
Implicit syncing is how Linux traditionally worked (e.g. DRI2/3 on X.org),
whereas explicit fencing is what Android wants.
“IN_FENCE_FDâ??:
Use this property to pass a fence that DRM should wait on before
proceeding with the Atomic Commit request and show the framebuffer for
the plane on the screen. The fence can be either a normal fence or a
merged one, the sync_file framework will handle both cases and use a
fence_array if a merged fence is received. Passing -1 here means no
fences to wait on.
If the Atomic Commit request has the DRM_MODE_ATOMIC_TEST_ONLY flag
it will only check if the Sync File is a valid one.
On the driver side the fence is stored on the fence parameter of
structdrm_plane_state. Drivers which also support implicit fencing
should set the implicit fence using drm_atomic_set_fence_for_plane(),
to make sure there’s consistent behaviour between drivers in precedence
of implicit vs. explicit fencing.
“OUT_FENCE_PTRâ??:
Use this property to pass a file descriptor pointer to DRM. Once the
Atomic Commit request call returns OUT_FENCE_PTR will be filled with
the file descriptor number of a Sync File. This Sync File contains the
CRTC fence that will be signaled when all framebuffers present on the
Atomic Commit * request for that given CRTC are scanned out on the
screen.
The Atomic Commit request fails if a invalid pointer is passed. If the
Atomic Commit request fails for any other reason the out fence fd
returned will be -1. On a Atomic Commit with the
DRM_MODE_ATOMIC_TEST_ONLY flag the out fence will also be set to -1.
Note that out-fences don’t have a special interface to drivers and are
internally represented by a structdrm_pending_vblank_event in struct
drm_crtc_state, which is also used by the nonblocking atomic commit
helpers and for the DRM event handling for existing userspace.
When this property is set to Limited 16:235 and CTM is set, the hardware will be programmed with the result of the multiplication of CTM by the limited range matrix to ensure the pixels normaly in the range 0..1.0 are remapped to the range 16/255..235/255.
Vertical blanking plays a major role in graphics rendering. To achieve
tear-free display, users must synchronize page flips and/or rendering to
vertical blanking. The DRM API offers ioctls to perform page flips
synchronized to vertical blanking and wait for vertical blanking.
The DRM core handles most of the vertical blanking management logic, which
involves filtering out spurious interrupts, keeping race-free blanking
counters, coping with counter wrap-around and resets and keeping use counts.
It relies on the driver to generate vertical blanking interrupts and
optionally provide a hardware vertical blanking counter.
Vertical blanking interrupts can be enabled by the DRM core or by drivers
themselves (for instance to handle page flipping operations). The DRM core
maintains a vertical blanking use count to ensure that the interrupts are not
disabled while a user still needs them. To increment the use count, drivers
call drm_crtc_vblank_get() and release the vblank reference again with
drm_crtc_vblank_put(). In between these two calls vblank interrupts are
guaranteed to be enabled.
On many hardware disabling the vblank interrupt cannot be done in a race-free
manner, see drm_driver.vblank_disable_immediate and
drm_driver.max_vblank_count. In that case the vblank core only disables the
vblanks after a timer has expired, which can be configured through the
vblankoffdelay module parameter.
Vertical Blanking and Interrupt Handling Functions Reference¶
struct drm_vblank_crtc {
struct drm_device *dev;
wait_queue_head_t queue;
struct timer_list disable_timer;
seqlock_t seqlock;
u64 count;
ktime_t time;
atomic_t refcount;
u32 last;
unsigned int inmodeset;
unsigned int pipe;
int framedur_ns;
int linedur_ns;
struct drm_display_mode hwmode;
bool enabled;
};
Members
dev
Pointer to the drm_device.
queue
Wait queue for vblank waiters.
disable_timer
Disable timer for the delayed vblank disabling
hysteresis logic. Vblank disabling is controlled through the
drm_vblank_offdelay module option and the setting of the
drm_device.max_vblank_count value.
seqlock
Protect vblank count and time.
count
Current software vblank counter.
time
Vblank timestamp corresponding to count.
refcount
Number of users/waiters of the vblank interrupt. Only when
this refcount reaches 0 can the hardware interrupt be disabled using
disable_timer.
last
Protected by drm_device.vbl_lock, used for wraparound handling.
inmodeset
Tracks whether the vblank is disabled due to a modeset.
For legacy driver bit 2 additionally tracks whether an additional
temporary vblank reference has been acquired to paper over the
hardware counter resetting/jumping. KMS drivers should instead just
call drm_crtc_vblank_off() and drm_crtc_vblank_on(), which explicitly
save and restore the vblank count.
Cache of the current hardware display mode. Only valid when enabled
is set. This is used by helpers like
drm_calc_vbltimestamp_from_scanoutpos(). We can’t just access the
hardware mode by e.g. looking at drm_crtc_state.adjusted_mode,
because that one is really hard to get from interrupt context.
enabled
Tracks the enabling state of the corresponding drm_crtc to
avoid double-disabling and hence corrupting saved state. Needed by
drivers not using atomic KMS, since those might go through their CRTC
disabling functions multiple times.
Description
This structure tracks the vblank state for one CRTC.
Note that for historical reasons - the vblank handling code is still shared
with legacy/non-kms drivers - this is a free-standing structure not directly
connected to structdrm_crtc. But all public interface functions are taking
a structdrm_crtc to hide this implementation detail.
This function is similar to drm_crtc_vblank_count() but this function
interpolates to handle a race with vblank interrupts using the high precision
timestamping support.
This is mostly useful for hardware that can obtain the scanout position, but
doesn’t have a hardware frame counter.
int drm_vblank_init(struct drm_device * dev, unsigned int num_crtcs)¶
initialize vblank support
Parameters
structdrm_device*dev
DRM device
unsignedintnum_crtcs
number of CRTCs supported by dev
Description
This function initializes vblank support for num_crtcs display pipelines.
Cleanup is handled by the DRM core, or through calling drm_dev_fini() for
drivers with a drm_driver.release callback.
Return
Zero on success or a negative error code on failure.
This function returns a pointer to the vblank waitqueue for the CRTC.
Drivers can use this to implement vblank waits using wait_event() and related
functions.
drm_crtc whose timestamp constants should be updated.
conststructdrm_display_mode*mode
display mode containing the scanout timings
Description
Calculate and store various constants which are later needed by vblank and
swap-completion timestamping, e.g, by
drm_calc_vbltimestamp_from_scanoutpos(). They are derived from CRTC’s true
scanout timing, so they take things like panel scaling or other adjustments
into account.
bool drm_calc_vbltimestamp_from_scanoutpos(struct drm_device * dev, unsigned int pipe, int * max_error, ktime_t * vblank_time, bool in_vblank_irq)¶
precise vblank timestamp helper
Parameters
structdrm_device*dev
DRM device
unsignedintpipe
index of CRTC whose vblank timestamp to retrieve
int*max_error
Desired maximum allowable error in timestamps (nanosecs)
On return contains true maximum error of timestamp
ktime_t*vblank_time
Pointer to time which should receive the timestamp
boolin_vblank_irq
True when called from drm_crtc_handle_vblank(). Some drivers
need to apply some workarounds for gpu-specific vblank irq quirks
if flag is set.
Description
Implements calculation of exact vblank timestamps from given drm_display_mode
timings and current video scanout position of a CRTC. This can be directly
used as the drm_driver.get_vblank_timestamp implementation of a kms driver
if drm_driver.get_scanout_position is implemented.
The current implementation only handles standard video modes. For double scan
and interlaced modes the driver is supposed to adjust the hardware mode
(taken from drm_crtc_state.adjusted mode for atomic modeset drivers) to
match the scanout position reported.
Fetches the “cooked” vblank count value that represents the number of
vblank events since the system was booted, including lost events due to
modesetting activity. Note that this timer isn’t correct against a racing
vblank interrupt (since it only reports the software vblank counter), see
drm_crtc_accurate_vblank_count() for such use-cases.
retrieve “cooked” vblank counter value and the system timestamp corresponding to that vblank counter value
Parameters
structdrm_crtc*crtc
which counter to retrieve
ktime_t*vblanktime
Pointer to time to receive the vblank timestamp.
Description
Fetches the “cooked” vblank count value that represents the number of
vblank events since the system was booted, including lost events due to
modesetting activity. Returns corresponding system timestamp of the time
of the vblank interval that corresponds to the current vblank counter value.
A lot of drivers need to generate vblank events for the very next vblank
interrupt. For example when the page flip interrupt happens when the page
flip gets armed, but not when it actually executes within the next vblank
period. This helper function implements exactly the required vblank arming
behaviour.
NOTE
Drivers using this to send out the drm_crtc_state.event as part of an
atomic commit must ensure that the next vblank happens at exactly the same
time as the atomic commit is committed to the hardware. This function itself
does not protect against the next vblank interrupt racing with either this
function call or the atomic commit operation. A possible sequence could be:
Driver commits new hardware state into vblank-synchronized registers.
A vblank happens, committing the hardware state. Also the corresponding
vblank interrupt is fired off and fully processed by the interrupt
handler.
The event is only send out for the next vblank, which is wrong.
An equivalent race can happen when the driver calls
drm_crtc_arm_vblank_event() before writing out the new hardware state.
The only way to make this work safely is to prevent the vblank from firing
(and the hardware from committing anything else) until the entire atomic
commit sequence has run to completion. If the hardware does not have such a
feature (e.g. using a “go” bit), then it is unsafe to use this functions.
Instead drivers need to manually send out the event from their interrupt
handler by calling drm_crtc_send_vblank_event() and make sure that there’s no
possible race with the hardware committing the atomic update.
Caller must hold a vblank reference for the event e, which will be dropped
when the next vblank arrives.
Release ownership of a given vblank counter, turning off interrupts
if possible. Disable interrupts after drm_vblank_offdelay milliseconds.
void drm_wait_one_vblank(struct drm_device * dev, unsigned int pipe)¶
wait for one vblank
Parameters
structdrm_device*dev
DRM device
unsignedintpipe
CRTC index
Description
This waits for one vblank to pass on pipe, using the irq driver interfaces.
It is a failure to call this when the vblank irq for pipe is disabled, e.g.
due to lack of driver support or because the crtc is off.
This waits for one vblank to pass on crtc, using the irq driver interfaces.
It is a failure to call this when the vblank irq for crtc is disabled, e.g.
due to lack of driver support or because the crtc is off.
Drivers can use this function to shut down the vblank interrupt handling when
disabling a crtc. This function ensures that the latest vblank frame count is
stored so that drm_vblank_on can restore it again.
Drivers must use this function when the hardware vblank counter can get
reset, e.g. when suspending or disabling the crtc in general.
Drivers can use this function to reset the vblank state to off at load time.
Drivers should use this together with the drm_crtc_vblank_off() and
drm_crtc_vblank_on() functions. The difference compared to
drm_crtc_vblank_off() is that this function doesn’t save the vblank counter
and hence doesn’t need to call any driver hooks.
This is useful for recovering driver state e.g. on driver load, or on resume.
This functions restores the vblank interrupt state captured with
drm_crtc_vblank_off() again and is generally called when enabling crtc. Note
that calls to drm_crtc_vblank_on() and drm_crtc_vblank_off() can be
unbalanced and so can also be unconditionally called in driver load code to
reflect the current hardware state of the crtc.
bool drm_handle_vblank(struct drm_device * dev, unsigned int pipe)¶
handle a vblank event
Parameters
structdrm_device*dev
DRM device
unsignedintpipe
index of CRTC where this event occurred
Description
Drivers should call this routine in their vblank interrupt handlers to
update the vblank counter and send any signals that may be pending.