Skip to content

Update OpenBSD support to new drm API introduced in 6.9 #216

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: develop
Choose a base branch
from

Conversation

tobhe
Copy link

@tobhe tobhe commented Feb 25, 2025

This makes OpenBSD work properly on my machine.

WIP because it depends on a libc change in rust-lang/libc#4285 (comment)

My rust experience is rather limited so I'm looking forward to hear how this could be improved.

One potential problem I see is that devname() is not thread-safe as is because the name buffer is static. Does this need to be copied safely, guarded by a lock or marked unsafe?

@MarijnS95
Copy link
Contributor

This was based on upstream libdrm, which still defines those original constants for OpenBSD to be different from the rest: https://gitlab.freedesktop.org/mesa/drm/-/blob/a7eb2cfd53a70fcd9ba9dcfad80a3994642f362f/xf86drm.h#L79-90

Any clue as to how/when this was changing, and is this PR backwards-compatible "enough"?

@tobhe
Copy link
Author

tobhe commented Mar 2, 2025

Any clue as to how/when this was changing, and is this PR backwards-compatible "enough"?

It looks like this changed in 2021 openbsd/xenocara@9d1e1e2

OpenBSD only supports the last two releases, with one release every 6 months that means we don't need to worry (besides, breaking API and ABI across releases is not a huge issue in OpenBSD land).

@tobhe
Copy link
Author

tobhe commented Mar 2, 2025

Latest push includes a few fixes based on feedback from @MarijnS95. I also added a check to handle the actual error case "??" properly. I am not convinced that buf.is_null() is actually possible here but it probably doesn't hurt to keep that check.

@Drakulix
Copy link
Member

Drakulix commented Mar 3, 2025

One potential problem I see is that devname() is not thread-safe as is because the name buffer is static. Does this need to be copied safely, guarded by a lock or marked unsafe?

We can't really mark a function as thread-unsafe in rust, so I am afraid this would need a global lock variable.

@tobhe
Copy link
Author

tobhe commented Mar 3, 2025

Clarified the /dev/dri node change in the commit message, changed the libc dependency to a more realistic target (if I understand their versioning right) and added a global lock for the static buffer returned by devname().

@tobhe tobhe changed the title WIP: Fix OpenBSD support Fix OpenBSD support Jun 15, 2025
@tobhe
Copy link
Author

tobhe commented Jun 15, 2025

libc with devname support is now available so I force pushed to remove the XXX comment and removed WIP in the PR title

Copy link
Contributor

@MarijnS95 MarijnS95 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! Wish we could retitle this PR to explain that it's not really a "fix" but a "change" to accomodate for recent breaking changes in the OpenBSD API that you linked?

}

let dev_str =
unsafe { CStr::from_ptr(buf).to_str() }.expect("Returned device name is not valid utf8");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think to_str() can be outside of the unsafe block where .expect() already resides.

Comment on lines +234 to +238
#[cfg(target_os = "openbsd")]
use std::sync::Mutex;

#[cfg(target_os = "openbsd")]
static DEVNAME_LOCK: Mutex<()> = Mutex::new(());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to keep this static locally inside the function for now? And/or do we expect other calls to devname()?

Note that this won't help if user code - through other means - calls libc::devname() without knowing about "your / our" lock 😅

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to keep this static locally inside the function for now? And/or do we expect other calls to devname()?

Sure, I can do that

Note that this won't help if user code - through other means - calls libc::devname() without knowing about "your / our" lock 😅

True, but that's how the underlying API works so not much we can do about it imho.

@tobhe tobhe changed the title Fix OpenBSD support Update OpenBSD to new drm API introduced in 6.9 Jun 21, 2025
@tobhe tobhe changed the title Update OpenBSD to new drm API introduced in 6.9 Update OpenBSD support to new drm API introduced in 6.9 Jun 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants