Summary: |
first argument to drmOpen() is a no-op |
Product: |
xorg
|
Reporter: |
Robert Millan <rmh> |
Component: |
Driver/Radeon | Assignee: |
xf86-video-ati maintainers <xorg-driver-ati> |
Status: |
RESOLVED
FIXED
|
QA Contact: |
Xorg Project Team <xorg-team> |
Severity: |
normal
|
|
|
Priority: |
medium
|
|
|
Version: |
unspecified | |
|
Hardware: |
Other | |
|
OS: |
FreeBSD | |
|
Whiteboard: |
|
i915 platform:
|
|
i915 features:
|
|
Attachments: |
Description |
Flags |
patch
|
none
|
|
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 90951 [details] patch Since the introduction of a call to drmCheckModesettingSupported() in radeon_kernel_mode_enabled(), with abort condition if such call fails, the first argument to drmOpen() call in radeon_open_drm_master() has become a no-op red herring. Such argument (a kernel module name) is supposed to result in load of specified kernel module. However, this will never happen. The problem is that if the code containing drmOpen() call is reached, it means that drmCheckModesettingSupported() check has previously succeeded, which implies the module is already loaded. So, drmOpen() will never load a kernel module. But it gives the impression that it will. In order to avoid this confusion, I suggest replacing it with NULL, like xf86-video-intel driver does: src/intel_device.c: fd = drmOpen(NULL, id); and then taking care of module load elsewhere (I'll submit a separate bug for that).