I am currently trying to do some low-level GPU programming (for Nvidia cards using the open-source nouveau driver) and so, I need access to driver-specific APIs for managing buffers and executing command lists.

It seems I'm not the only one needing this, since there are already other projects using this crate (eg. rudihorn/drm-vc4-grabber) that implement their own bindings for driver-specific APIs, so it would make sense to unify them under this crate.

Is this considered to be in-scope for this crate? If so, I would be happy to contribute to this crate.

Hi ! Thank you for these crates, they are very useful for low level graphics management.
The drm crate as available to crates.io is pretty complete, but it lacks a feature or two that I would like to use in a project, related to cursor management. I see that these features have actually been implemented, but on the develop branch only.
Is anything preventing the crate update ?

At the moment people have the option to use the use_bindgen feature to generate bindings from libdrm. This means that features get implemented in the kernel first, then into libdrm, then finally here once we manually update.

I'd like to know anyone's opinions on possibly generating these low-level bindings based on the upstream Linux kernel code automatically when new versions come out. This subsystem actually has all the proper #ifdefs to allow for BSD bindings to be generated as well, so I don't think that will be an issue.

All of the required header files are in include/uapi/drm, and that's just pulled directly into libdrm from what I can tell. This would just eliminate using libdrm as a middle-man for those files.

If nobody has any issues with this, I'll use the opportunity to see if we can generate bindings for all the other driver-specific APIs as well (see !105)

Hi, I'm trying to test VblankEvent and PageFlipEvent:
https://github.com/Smithay/drm-rs/blob/master/src/control/crtc.rs#L192

Is this working now? If so, is there any example for this?
This event handling was removed from the master branch. Is there any plan for replacing this code?

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

I'm not sure there's any value in having Device be a trait the user has to implement. Since the supplied functionality essentially make the trait a trivial wrapper around RawFd, it would be a lot more straight-forward to simply implement Device as a struct that can be constructed from any one of RawFd, File, or some form of path representation. I don't think there is any loss of flexibility. Is it expected that anyone would ever want to implement the Device trait for anything other than RawFd given that AsRawFd is required to satisfy the trait?

99% of the time applications will simply be opening /dev/dri/card0, or else every card in /dev/dri in turn. For the remaining 1%, I don't think there's any situation that passing in an already open file descriptor doesn't cover.

From a consumer's perspective, having to implement this arbitrary set of types in my client code feels too much like inheritance, and this doesn't seem like a situation where I'd reach for inheritance even in C++.

Hello, I've come across these transmutes when browsing the code:

They are transmuting Vec<drm_mode_modeinfo> into Vec<Mode>. However, Vec has an unspecified layout and this can lead to UB. This is even mentioned in the documentation https://doc.rust-lang.org/std/mem/fn.transmute.html#alternatives (scroll to "Turning a Vec<&T> into a Vec<Option<&T>>.")

The documentation also offers an alternative:

let after = unsafe {
    let mut before = std::mem::ManuallyDrop::new(before);
    Vec::from_raw_parts(before.as_mut_ptr() as *mut _, before.len(), before.capacity())
};

Secondly, I have also notices these two Handle types aren't repr(transparent) as they should be. Other Handle types are, so I assume this is just an oversight.

I can open a PR to fix these, should be very simple.

The crate seems to output a wrong list of CRTCs on my system. I used this example program and compared its output to the output of the modetest tool from mesa (see instructions for using it), and they differ on the crtc list.

This is the list printed by the drm-rs example:

[
    (
        crtc::Handle(63),
        Err(Error(Unix(Sys(ENOENT)), State { next_error: None } ) )
    ),
    (
        crtc::Handle(64),
        Err(Error(Unix(Sys(ENOENT)), State { next_error: None } ) )
    ),
    (
        crtc::Handle(46),
        Ok(
            Info {
                handle: crtc::Handle(46),
                position: (0, 0),
                fb: framebuffer::Handle(0),
                gamma_length: 256
            }
        )
    )
]

while modetest lists crtcs with numbers 32, 39 and 46.

Note also that the reported 63 and 64 crtcs here seem to be invalid, as trying to query their info returns an error.

Both OpenBSD and FreeBSD expose a DRM API. We should try to include prebuilt bindings for these operating systems.

I'll be blunt: I have no idea what I'm doing, however I did find the legacy_modeset.rs example helpful because it seems coherent with how the internet says DRM works, and it's pretty close to the C equivalent of getting stuff on screen.

Compiling this and running it myself on Ubuntu Server 21.10 (no x server, nothing but TTY) yields the error.

thread 'main' panicked at 'Could not set CRTC: InvalidArgument', legacy_modeset.rs:77:9.

I don't even really know where to begin to figure this out; I'm new to DRM, Rust, DRM-RS etc. Some pointers would be much appreciated

    card.set_crtc(crtc.handle(), Some(fb), (0, 0), &[con.handle()], Some(mode))
        .expect("Could not set CRTC");

I should mention, I tried multiple different things, like running under root, adding the current user to the video group, to no avail

While Cargo.toml specifies that this codebase is licensed under the MIT license, the repository itself includes no license file. I think it would be wise to include one for clarity.

I'm going to start moving the code in the tests directory into different examples. This should be a bit more suitable for this type of crate.

I was done some fixes for version which published on crates.
This is minor changes related to wider platforms support and updating dependencies.
But it important for me because my projects targeted to stable Rust.

Are you still accept PRs based on master branch for stable Rust?
Could you publish 0.3.x releases on crates.io?

When running a smithay compositor, or an example like list_modes in valgrind, various uninitialized memory errors are reported in drm-rs, like Syscall param ioctl(generic) points to uninitialised byte(s) and Conditional jump or move depends on uninitialised value(s).

I think Valgrind may be overly strict about arbitrary ioctls that it isn't familiar with, but it would be good to fix or suppress this in some way so that valgrind can be used for testing without dealing with a bunch of spurious messages.

It might make sense to change things like map_reserve! to zero initialize memory.

I copied the example for atomic mode setting but changed the card to /dev/dri/card1. It keeps failing with

thread 'main' panicked at 'Failed to set mode: InvalidArgument'

Any advice on how to debug it?

This is used in the dirty_framebuffer function but isn't exposed in the main drm crate, necessitating the import of drm-sys.

The drm headers define:

#define DRM_RDWR O_RDWR
#define DRM_CLOEXEC O_CLOEXEC

These can be passed to prime_handle_to_fd and should be exported by the drm crate.

I'm trying to create bindings to https://gitlab.freedesktop.org/emersion/libliftoff which uses libdrm and use it in a project that uses drm-rs. Unfortunately AtomicModeReq is not compatible with drmModeAtomicReq from xf86drmMode.h, nor is there any other type compatible with it. This means I can't commit the atomic mode setting request created by libliftoff.

So unfortunately, the cexpr crate (and as such, bindgen), does not support C functional macros (jethrogb/rust-cexpr#3), so we can't directly create bindings for them.

We can however, use a neat little hack to get around this, which is to define a constant variable that takes the value of the macro. I've put this workaround into the build script. All we need to do is put each functional macro name into the list of names.

Hey there,
as I am currently trying to develop a drm backend for smithay and I am in need of a working drm library I am looking into contributing to this library.

Do you have some kind of roadmap what still needs to be done? It currently seems to be lacking quite a bit functionality, I immediately did run into problems trying to find something like drmHandleEvent and I expect more to be missing, but this looks the most promising of all of them.

I do not have very deep knowledge about libdrm, so some hints on whats easy to do and some references would be nice.

Thanks for you work,
Drakulix

https://patchwork.freedesktop.org/series/120103/ has been merged from what I heard over on wlroots.

in the README, the [crtcs](https://docs.rs/drm/*/drm/control/crtcs/index.html) link leads to a non-existent page

Hi!
When I'm trying to to run kms-interacive example in dev branch it fails when creating framebuffer with InvalidArgument error. I've checked that in my case it's converted from SystemError which comes from ioctl::mode::add_fb function. But it's not clear what is exactly wrong (just in case I'm of course running it without terminal emulator).

Can you suggest what could go wrong?

I think there's a zero missing in src/control/mod.rs line 868:

vblank_event.tv_usec * 100,
                       ^^^

let card = Card::open_global();
let resources = card.resource_handles().unwrap();

for (i, handle) in resources.connectors().iter().enumerate() {
    let info = card.get_connector(*handle).unwrap();
    eprintln!("Connector {} encoders: {:?}", i, info.encoders());
}

Connector 0 encoders: [Some(encoder::Handle(77)), None, None]
Connector 1 encoders: [Some(encoder::Handle(83)), None, None]
Connector 2 encoders: [Some(encoder::Handle(88)), None, None]
Connector 3 encoders: [Some(encoder::Handle(93)), None, None]
Connector 4 encoders: [None, None, None]
Connector 5 encoders: [None, None, None]

drm_info shows Encoders: {4, 5, 6, 7} for Connector 4 and Connector 5. Which are DisplayPort over USB-C devices connected to my HP Dev One laptop with AMD graphics.

Not sure exactly what is wrong with the ioctl call, but it seems assuming there would be at most 3 encoders is not correct.

How about adding some CI to this project (And also for other such as gbm.rs, input.rs, udev-rs and etc.)?

We can automate the following tasks using CI:

• Check code formatting rules
• Check code quality using clippy
• Check building on all supported platforms
• Generate bindings for supported platforms
• Create pull-requests for updating generated bindings
• Publish crates when pushing version tag

The example how this works you can see in the following projects:

• rquickjs
• oboe-rs