smithay / drm-rs Goto Github PK
View Code? Open in Web Editor NEWA low-level abstraction of the Direct Rendering Manager API
License: MIT License
A low-level abstraction of the Direct Rendering Manager API
License: MIT License
Hello, I've come across these transmutes when browsing the code:
Line 170 in e5f5b14
Line 539 in e5f5b14
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.
Line 11 in e5f5b14
Line 20 in e5f5b14
I can open a PR to fix these, should be very simple.
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?
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 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.
in the README, the [crtcs](https://docs.rs/drm/*/drm/control/crtcs/index.html)
link leads to a non-existent page
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
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.
https://patchwork.freedesktop.org/series/120103/ has been merged from what I heard over on wlroots.
Any tutorial explaining how to take a screenshot?
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 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++.
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:
The example how this works you can see in the following projects:
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 ?
This is used in the dirty_framebuffer
function but isn't exposed in the main drm
crate, necessitating the import of drm-sys
.
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.
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!
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 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?
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.
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
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.
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.
I think there's a zero missing in src/control/mod.rs line 868:
vblank_event.tv_usec * 100,
^^^
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.
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.
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?
Both OpenBSD and FreeBSD expose a DRM API. We should try to include prebuilt bindings for these operating systems.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.