Non-deprecated coverage

[Slabity]

I've sorted through all the different functions that the DRM API exposes and filtered out all the deprecated functionality that the kernel no longer recommends using. Any function that was mapped to drm_noop, drm_invalid_op, or one of the drm_legacy_* functions in the Linux 4.9 kernel have been removed from the crate. The drm-sys crate will continue to include bindings to them, but unless someone wants me to specifically support that deprecated functionality, they will be kept out of drm-rs. This should keep the crate lean and clean.

I'd also like to move low-level ffi-based logic into the ffi module. It's currently scattered around the crate.

This crate should also support #[no_std] if possible. I don't see any dependencies that this requires.

Finally, remove all memory allocation and management. Let the user decide how to organize their program's memory.

Basic

• get_unique - Returns the bus ID of the device
• get_client - Returns information about the client
• get_cap - Returns the capabilities of the device
• set_client_cap - Informs the device to expose a specific capability
• set_version - Sets the requested interface version
• version - Gets the current interface version
• get_magic - Returns the client's authentication token
• auth_magic - Authenticates a client with their authentication token
• set_master - Acquires the DRM master lock
• drop_master - Releases the DRM master lock
• irq_from_busid - Gets the IRQ from the bus id
• wait_vblank - Enables the vblank interrupt and sleeps until it goes off

Modesetting

• getresources - Returns a list of all modesetting resources
• getplaneresources - Returns a list of all plane resources
• getconnector
• getencoder
• getcrtc
• setcrtc - Modifies the state of a CRTC
• getfb
• addfb
• addfb2
• rmfb
• dirtyfb
• getplane
• setplane - Modifies the state of a plane
• getgamma
• setgamma - Sets a gamma ramp on a CRTC

DumbBuffers

• create_dumb
• map_dumb
• destroy_dumb

Cursors

• cursor
• cursor2

Properties

• getproperty
• setproperty
• obj_getproperties
• obj_setproperty
• getpropblob
• createpropblob
• destroypropblob

Atomic

• page_flip
• atomic

GEM Buffers

• gem_open
• gem_close
• gem_flink - Pass a GEM buffer to another client

PRIME handles

• prime_fd_to_handle - Converts a dma-buf file descriptor into a buffer handle
• prime_handle_to_fd - Converts a buffer handle into a dma-buf file descriptor

[Drakulix]

Whats the state of this? It seems many of these changes did already happen on the 'feature-failure' branch, am I right?
I am thinking about supporting atomic modesetting in smithay, so if you could need a helping hand to implement these functions, just let me know.

[Slabity]

@Drakulix - Yes, all of the recent work has been in the feature-failure branch. That branch was originally suppose to only be switching error handling from the error-chain crate to the failure crate, but it sort of became a development branch.

I'm right now moving the low-level logic into the ffi module. I'm also modifying it so that the buffers are GenericArrays to avoid using the heap or std crate at all. Once that's done, each of the above commands can be implemented one by one. Once all of these are implemented (and rigorously tested on a range of systems), then it'll be released as 1.0

[Drakulix]

Alright, sounds like you got a bunch of refactoring ahead. Once you are settled on a structure of the code, I am happy to help.

[Drakulix]

Hey @Slabity,
how is the rework coming along? I would like to help out again!
smithay needs planes and atomic modesetting to progress further and I would rather not try to fix the old branch.

[Slabity]

I apologize for the delay. My notifications are apparently disabled for some reason.

I'll update the list above to show what is covered now in the develop branch so far.

[Drakulix]

I apologize for the delay. My notifications are apparently disabled for some reason.

I'll update the list above to show what is covered now in the develop branch so far.

That sounds good!

My biggest question regarding your design decisions of the develop branch is where the functions are supposed to live now.

• In master we have free-standing functions like framebuffer::create.
• In the develop branch we have Commands-traits like in buffer::Commands.
• And in both we have types containing the corresponding functions and taking the Device as an argument like in control::dumbbuffer::Dumbbuffer.

I would prefer to unify this. Dumbbuffer::create_from_device seems unusual, I would rather expect to be able to use my ControlDevice and to have a create function that returns a Dumbbuffer.

I have no opinion regards free-standing functions vs Commands-Traits, however I do not see the point in using traits for these, because I would not expect anyone to implement these commands themselves. Both solutions look nice and feel clean and I really like your current work on the develop branch so far.

[Slabity]

Agreed. I plan on unifying the functions to make them easier to work with. I'd like to put all operations that require a Device (which is pretty much everything) in the Device traits themselves.

The dumbbuffer module is not rewritten yet, which is why the create_from_device function is still there. This will be moved to control::Device

[Drakulix]

Hey @Slabity,
I would really like to help you wrap up a first RC-version of this re-write for smithay. Could you maybe mentor me on what's missing for atomic modesetting? That + my currently still open PRs would give me all the features I need. I am also happy to help with anything else, blocking a potential release.

[Slabity]

Hey @Drakulix, sorry for the delays. Life gets in the way.

The good news is that there is only one more piece of functionality for atomic modesetting, which is the actual atomic commands themselves (as long as you don't need custom property blobs, which might be a bit more difficult).

An atomic 'commit' is actually just a bunch of resource properties you want to modify at once. I'd recommend looking at kmscube's drm-atomic.c to get a sense for how it's used. The caveat is that these resource properties need to be ordered in a specific way or else the driver will complain about bad arguments.

As for your other PRs, I can look through those today.

On a slightly related note, I've made a new example, kms_interactive, that allows you to run DRM modesetting commands one at a time on a CLI. This is good for probing and testing how different modesetting operations actually work.