- Sep 30, 2024
-
-
Lyude Paul authored
Add optional trait methods for DRM's prepare_fb() and cleanup_fb() callbacks now that we have proper Framebuffer bindings. As well, introduce a new PlaneState mutator: PlaneStateMutator. The purpose of this mutator type is for callbacks where we want the implementor to be able to modify the atomic plane state, without providing access to the rest of the atomic state. TODO: * Write documentation Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
Add some bindings to allow the use of drm_rect in rust code. Since drm_rect is a very basic type - four i32s on top of each other in a trench coat - we don't abstract this type very much and allow direct access to the bindings::drm_rect within. We also port a few of the helper functions for drm_rect over. Because drm_rect is a simple enough type, and most of these helpers are very short, we just do some search and replace to convert them directly to rust code. This allows us to define them as const functions. We do however try to call down to the actual C functions where possible. Finally, it's worth noting that these helpers follow a slightly different pattern then the DRM ones. Instead of modifying rects through references, we simply pass them around by value - which is a lot more idiomatic in rust since it allows expressions such as: let rect = /* ... */ let rotated = rect.translate_to(5, 5); Signed-off-by:
Lyude Paul <lyude@redhat.com> TODO: * I don't think we'll be using most of these right away so we probably want to shrink this patch down a bit
-
Lyude Paul authored
A binding for retrieving the current rotation of a DRM plane state. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
Just a binding for drm_simplify_rotation(). We add this in a new module blend.rs in order to match the layout of the C side of things. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
Just add some short-hand aliases to the raw bindings, since that's basically all we need. We put this in a new mode.rs module to match the layout of the C side of KMS. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
Bindings for returning the src and dst rectangles for an atomic plane state. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
There's another class of state that many drivers keep track of, usually for intermediate state that needs to be tracked during the middle of a commit. There isn't really a name for this kind of state, so I've named it EphemeralData. This data is not expected to be accessible outside of a modeset context, and should only be used for modesetting state that changes within the process of a commit rather than from commit to commit. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
This adds the ability to have driver-private commit state in a CRTC state that is both guaranteed to be pinned, and thus - must rely on its own synchronization in order to be mutated. This in theory should allow it to be used outside of the main context for an atomic commit (with care). Drivers we'll likely need this, and we'll likely need this for handling work that is tied to a CRTC's commit state. For the time being it's unused though. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
TODO: Write a commit message and stuff, maybe consider moving this to another module since we don't have most of the dma pool stuff pulled in anymore
-
Lyude Paul authored
Using the dma_set_mask_and_coherent() wrapper that we just added. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
Which we'll use for the next wrapper Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
Now that we've added all of the bits that we need for the KMS API, it's time to introduce rvkms! This is a port of the VKMS driver to rust, with the intent of acting as an example usecase of the KMS bindings that we've come up with so far in preparation for writing a display driver for nova. Currently RVKMS is an extremely bear bones driver - it only registers a device and emulates vblanking, but it exercises a good portion of the API that we've introduced so far! Eventually I hope to introduce CRC generation and maybe writeback connectors like. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
A quick note: this is one of my favorite bindings so far :). It sounds way overly complicated, but so far actually writing implementations of this in rust has been a breeze. Anyway: RVKMS has a slightly different atomic_commit_tail than normal, which means we need to write up some bindings for atomic_commit_tail. This is a lot more interesting then it might seem on the surface as implementing atomic_commit_tail incorrectly could result in UB. And in general, DRM has up until now relied entirely on the programmer to do this correctly through implicit ordering requirements. In the universe of rust though, we want no UB at all! To ensure this, we need to make sure that all atomic commit callbacks follow all of these requirements: * Disable/enable modeset commits must happen exactly once * A disable modeset must be committed for a resource before an enable modeset may be committed for a resource * Plane updates must happen exactly once * drm_atomic_commit_hw_done() must be called exactly once, and only after all commits have been completed. * The state may not be mutated after drm_atomic_commit_hw_done() is called * Access to the prior atomic states are revoked after drm_atomic_commit_hw_done() is called (and our "new" states become "old" states) To handle this, we introduce a number of new objects and types: tokens: * AtomicCommitTail Main object for controlling the commit_tail process * ModesetsReadyToken A single use token indicating that no modesets have been committed with the AtomicCommitTail yet * commit_modeset_disables() -> DisablesCommittedToken This function consumes the ModesetsReadyToken, commits modeset disables, and then returns a DisablesCommittedToken * commit_modeset_enables() -> EnablesCommittedToken This function consumes a DisablesCommittedToken, commits modeset enables, and then returns a EnablesCommittedToken EnablesCommittedToken - enforcing the disables -> enables order. * commit_planes() -> PlaneUpdatesCommittedToken Consumes a PlaneUpdatesReadyToken and returns a PlaneUpdatesCommittedToken. * commit_hw_done() -> CommittedAtomicState Revokes access to the AtomicCommitTailObject, and consumes both the EnablesCommittedToken and PlaneUpdatesCommitted tokens. This ensures that all modesets and plane updates have occurred exactly once. * CommittedAtomicState - main object for controlling the atomic_commit_tail after the state has been swapped in. This must be returned from the atomic_commit_tail function to prove that all of the required commits have occurred. Signed-off-by:
Lyude Paul <lyude@redhat.com> --- TODO: * Currently this solution wouldn't be sufficient for drivers that need precise control over the order of each individual modeset or plane update. However, this should be very easy to add. * Figure out something better for enforcing the plane cleanup then what we have right now (e.g. cleaning up planes in the destructor for CommittedAtomicState). * Add iterator functions that take mutable references to the atomic state objects here. This will prevent functions like commit_modeset_disables() from being called while a state borrow is taken out, while still allowing easy access to the contents of the atomic state at any portion of the atomic commit tail. * Actually add some macros for generating bitmasks like we do with PlaneCommitFlags - right now we just do this by hand.
-
Lyude Paul authored
This commit adds bindings for implementing vblank support for a driver's CRTCs. These bindings are optional, to account for the fact that not all drivers have dedicated hardware vblanks. In order to accomplish this, we introduce the VblankSupport trait which can be implemented on DriverCrtc by drivers which support vblanks. This works in the same way as the main Kms trait - drivers which don't support hardware vblanks can simply pass PhantomData<Self> to the associated type on DriverCrtc. If a driver chooses to implement VblankSupport, VblankImpl will be implemented by DRM automatically - and can be passed to the VblankImpl associated type on DriverCrtc. Additionally, we gate methods which only apply to vblank-supporting drivers by introducing a VblankDriverCrtc trait that is automatically implemented by DRM for CRTC drivers implementing VblankSupport. This works basically in the same way as Kms and KmsDriver, but for CRTCs. Signed-off-by:
Lyude Paul <lyude@redhat.com> --- Notes: * One thing to keep in mind: this trait is implemented on the CRTC as opposed to the KMS driver due to the possibility that a driver may have multiple different types of CRTCs. As a result, it's not impossible that there could potentially be differences in each type's vblank hardware implementation. In theory this could lead to a driver mistakenly only implementing VblankSupport for some CRTCs and not others, which isn't really defined behavior in DRM. As such, one of the dependencies in the branch for this patch series preview is a fix to ensure that DRM disallows registering drivers that make this mistake. TODO: * Technically this patch introduces a soundness issue. We currently allow access to a kernel::drm::Device (through UnregisteredKmsDevice's Deref implementation) within the kernel::drm::kms::Kms::create_objects trait method. A caller could potentially access an uninitialized mutex by calling Crtc::vblank_lock() within this context. My solution for this is likely going to be adding unregistered variants of Crtc and other mode-objects that don't have access to the full set of methods on mode objects.
-
Lyude Paul authored
A binding for checking drm_device.num_crtcs. We'll need this in a moment for vblank support, since setting it up requires knowing the number of CRTCs that a driver has initialized. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
This is just a crate-private helper to use Lock::from_raw() to provide an immutable reference to the DRM event_lock, so that it can be used like a normal rust spinlock. We'll need this for adding vblank related bindings. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
Optional trait methods for implementing the atomic_enable and atomic_disable callbacks of a CRTC. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
Optional trait methods for implementing the atomic_begin and atomic_flush callbacks for a CRTC. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
Returns the Framebuffer currently assigned in an atomic plane state. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
This adds some very simple bindings for drm_framebuffer. We don't use them much yet, but we'll eventually be using them when rvkms eventually gets CRC and writeback support. Just like Connector objects, these use RcModeObject. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
Add a binding for drm_atomic_helper_check_plane_state(). Since we want to make sure that the user is passing in the new state for a Crtc instead of an old state, we explicitly ask for a reference to a BorrowedCrtcState. Signed-off-by:
Lyude Paul <lyude@redhat.com> --- TODO: * Add support for scaling options
-
Lyude Paul authored
Add a binding for checking drm_plane_state.crtc. Note that we don't have a way of knowing what DriverCrtc implementation would be used here (and want to make this function also available on OpaquePlaneState types), so we return an OpaqueCrtc. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
A binding for checking drm_crtc_state.active. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
Optional trait method for implementing a plane's atomic_check(). Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
A mandatory trait method used for implementing DRM's atomic plane update callback. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
An optional trait method for implementing a CRTC's atomic state check. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
Next up is introducing bindings that we can use to represent the global DRM atomic state, along with all of the various object states contained within. We do this by introducing a few new concepts: borrowed states, atomic state mutators, and atomic state composers. To understand these, we need to quickly touch upon the general life of an atomic commit. Assuming a driver does its own internal atomic commit, the procedure looks something like this: * Allocate a new atomic state * Duplicate the atomic state of each mode object we want to mutate, and add the duplicated state to the new atomic state * Check (possibly more then once) the atomic state, possibly modifying it along the way * Commit the atomic state to software (we'll call this commit time). At this point no new objects can be added to the state * Finish committing the atomic state to hardware asynchronously With this in mind, we introduce AtomicStateMutator and AtomicStateComposer (along with leaky variants intended for uses in FFI calls). An AtomicStateMutator allows mutating an atomic state but does not allow for adding new objects to the state. Subsequently, an AtomicStateComposer allows for both mutating an atomic state and adding new mode objects. We control when we expose each of these types in order to implement the limitations required by the aforementioned example. Note as well that AtomicStateComposer is intended to eventually be usable directly by drivers. In this scenario, a driver will be able to create an AtomicStateComposer (the equivalent of allocating an atomic state in C) and then commit it by passing it to our DRM bindings by-value, insuring that once the commit process begins it is impossible to keep using the AtomicStateComposer. The next part of this is allowing users to modify the atomic states of all of the objects contained within an atomic state. Since it's an extremely common usecase for objects to mutate the atomic state of multiple objects at once in an unpredictable order, we need a mechanism that will allow us to hand out &mut references to each state while ensuring at runtime that we do not break rust's data aliasing rules (which disallow us from ever having more then one &mut reference to the same piece of data). We do this by introducing the concept of a "borrowed" state. This is a very similar concept to RefCell, where it is ensured during runtime that when a &mut reference is taken out another one cannot be created until the corresponding Ref object has been dropped. Our equivalent Ref types are BorrowedConnectorState, BorrowedCrtcState, and BorrowedPlaneState. Each one of these types can be used in the same manner as a Ref - no additional borrows for an atomic state may be taken until the existing one has been dropped. Subsequently, all of these types implement their respective AsRaw* and FromRaw* counter-parts - and allow dereferencing to each driver-private data structure for fully qualified borrows (like BorrowedCrtcState<'a, CrtcState<T>>. This allows a pretty clean way of mutating multiple states at once without ever breaking rust's mutability rules. We'll use all of these types over the next few commits to begin introducing various atomic modeset callbacks to each mode object type. Signed-off-by:
Lyude Paul <lyude@redhat.com> --- TODO: * Finish adding state iterators We only have one iterator for planes right now, but the plan is to have iterators for all types and have two different kind of iterators: * State object iterators Basically, these just iterate through all of the mode objects of a specific type present in an atomic state. Currently this is what our plane iterator does. * State mutator iterators With the existence of AtomicStateMutator and friends, it makes sense to have a type of iterator that: * Only iterates through unborrowed atomic states, removing the need to deal with the Option<> that get_new_*_state() functions return * Returns each (object, old_state, new_state) triplet as a dedicated type (PlaneUpdate, CrtcUpdate, ConnectorUpdate) that can be upcasted from an Opaque type using a single call. This is desirable, as it would make iterating through objects with a specific Driver* implementation as easy as just adding a .filter_map() call to the iterator. * Upcast functions for the Borrowed* types
-
Lyude Paul authored
Same thing as OpaquePlane, but for encoders now. Signed-off-by:
Lyude Paul <lyude@redhat.com> --- TODO: * Add upcast functions for this
-
Lyude Paul authored
Same thing as RawCrtc and RawCrtcState, but for DRM planes now Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
Same thing as RawConnector and RawConnectorState, just for CRTCs now. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
Now that we have more then one way to refer to connectors, we also want to ensure that any methods which are common to any kind of connector type can be used on all connector representations. This is where RawConnector and RawConnectorState come in: we implement these traits for any type which implements AsRawConnector or AsRawConnectorState respectively. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
Same thing as OpaqueCrtc and OpaqueCrtcState, but for plane states now. Signed-off-by:
Lyude Paul <lyude@redhat.com> --- TODO: * Finish adding upcast functions.
-
Lyude Paul authored
This is the same thing as OpaqueConnector and OpaqueConnectorState, but for CRTCs now. Signed-off-by:
Lyude Paul <lyude@redhat.com> --- TODO: * Add upcast functions
-
Lyude Paul authored
Since we allow drivers to have multiple implementations of DriverConnector and DriverConnectorState (in C, the equivalent of this is having multiple structs which embed drm_connector) - there are some situations we will run into where it's not possible for us to know the corresponding DriverConnector or DriverConnectorState for a given connector. The most obvious one is iterating through all connectors on a KMS device. So, take advantage of the various connector traits we added to introduce OpaqueConnector<> and OpaqueConnectorState<> which both can be used as a DRM connector and connector state respectively without needing to know the corresponding traits. Signed-off-by:
Lyude Paul <lyude@redhat.com> --- TODO: * Add upcast functions for these types
-
Lyude Paul authored
Add a wrapper for `drm_set_preferred_mode()` for our new `ConnectorGuard` type so we can set the preferred mode for RVKMS connectors. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
A simple binding for drm_add_modes_noedid() using the ConnectorGuard type we just added. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
Next up is filling out some of the basic connector hotplugging callbacks - which we'll need for setting up the fbdev helpers for KMS devices. Note that connector hotplugging in DRM follows a BFL scheme: pretty much all probing is protected under the mighty drm_device->mode_config.lock, which of course is a bit counter-intuitive to rust's locking schemes where data is always associated with its lock. Since that lock is embedded in an FFI type and not a rust type, we need to introduce our own wrapper type that acts as a lock acquisition for this. This brings us to introducing a few new types: * ModeConfigGuard - the most basic lock guard, as long as this object is alive we are guaranteed to be holding drm_device->mode_config.lock. This object doesn't do much else on its own currently. * ConnectorGuard - an object which corresponds to a specific typed DRM connector. This can only be acquired with a ModeConfigGuard, and will be used to allow calling methods that are only safe to call with drm_device->mode_config.lock held. Since it implements Deref<Target=Connector<T>> as well, it can also be used for any other operations that would normally be available on a DRM connector. And finally, we add the DriverConnector::get_modes() trait method which drivers can use to implement the drm_connector_helper_funcs.get_modes callback. Note that while we make this trait method mandatory, we only do so for the time being since VKMS doesn't do very much with DRM connectors - and as such we have no need yet to implement alternative connector probing schemes outside of get_modes(). Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
This adds a simple binding for completing the last step of creating a DRM connector - attaching its encoder. This function should only be called before the connector is registered, and DRM should enforce this itself by returning an error if a driver tries to add an encoder to an already-registered DRM connector. Note that unlike most of the methods we'll be adding to DRM mode objects, this is directly implemented on the Connector<T> type since I don't really think it would make sense for us to allow this operation on an OpaqueConnector (a DRM connector without a known DriverConnector implementation, something we'll be adding in the next few commits). Signed-off-by:
Lyude Paul <lyude@redhat.com> --- TODO: * Figure out a solution for making sure that this can only be called when a Connector is unregistered, probably via an UnregisteredConnector type.
-
Lyude Paul authored
The last thing we need to be able to register a KMS driver is the ability to create DRM encoders, so let's add bindings for that. Again, these bindings follow the same general pattern as CRTCs, planes, and connector with one difference: encoders don't have an atomic state. Note that not having an atomic state doesn't mean there aren't plenty of valid usecases for a driver to stick private data within a DRM encoder, hence why we reuse the aforementioned pattern. Signed-off-by:
Lyude Paul <lyude@redhat.com>
-
Lyude Paul authored
This introduces basic bindings for DRM CRTCs which follow the same general pattern as connectors and planes (e.g. AsRawCrtc, AsRawCrtcState, etc.). There is one big difference though - drm_crtc_state appears to be the one atomic state that actually has data which can be mutated from outside of the atomic commit phase - which means we can't keep rust referencs to it, and instead need to use the Opaque type and implement things through pointers instead. This should be the last mode object we're introducing for the time being with its own atomic state. Note that we've not added bindings for private modesetting objects yet, but I don't think those will be needed for rvkms - and the same general patterns we're using here should work for adding private modesetting objects. Signed-off-by:
Lyude Paul <lyude@redhat.com> --- TODO: * Add commit data in the future
-