Non-deprecated coverage about drm-rs HOT 10 OPEN

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.

from drm-rs.

@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

from drm-rs.

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.

from drm-rs.

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.

from drm-rs.

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.

from drm-rs.

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.

from drm-rs.

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

from drm-rs.

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.

from drm-rs.

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.

from drm-rs.

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

No worries, I had no time as well in the last couple of weeks, but I want to get started working on smithay again soon.

So thanks for your info, I will check that out and try to get something working soon. :)

from drm-rs.