Talk:Direct Rendering Manager

Licensing issues and BSD kernels

The DRM source code, as part of the Linux kernel is generally assumed to be GPL-licensed, but the reality is most source files have a MIT-style license, and only a few are GPL-licensed. For example, in the main directory drivers/gpu/drm/drm_edid_load.c, drivers/gpu/drm/drm_fb_cma_helper.c or drivers/gpu/drm/drm_gem_cma_helper.c are GPL licensed. There are also drivers with significant number of files under GPL, like gma500, exynos, tegra and others.

The question is BSD developers refuse to include GPL source code with their BSD-licensed code (because, by the viral nature of the GPL license, the whole resulting binary would be subject to the clausules of the GPL, and they don't want that). And for that reason, I strongly doubt that FreeBSD or OpenBSD kernels are using the Linux version of DRM. Perhaps they use a modified version with the GPL files removed or rewritten, or they use a completely different but compatible layer. I don't know. What I do know is DRM is essentially a Linux kernel project inside the Linux kernel development process, later ported (if ported) to other operating systems. And that should be clear in the Wikipedia article. Therefore, my recomendations are:

• any mention to other operating systems should be in its own devoted section (something like "DRM in other operating systems" or similar)
• reliable sources of the porting process or port status should be providing to comply with WP:VERIFY. Otherwise we may be giving false information (old or incompatible versions of DRM).

--JavierCantero (talk) 14:18, 28 July 2014 (UTC)

AFAIU it is the Direct Rendering Infrastructure that defines the API, that the DRM exposes. Maybe DRI and DRM should also be merged into a better article... And AFAIK at least FreeBSD and OpenBSD have implemented DRI into their kernels. I care about Linux, so I won't bother to search for references for that; as a comparison between User:ScotXW/Linux as platform and Linux, etc. should prove, there should be enough BSD-fans around to do that work.

I thought DRM code was dual-licensed, libDRM code under LPGL and Mesa 3D code is mostly under MIT License, though several older drivers were GPLv2. Calling the GNU GPL "viral" could be interpreted as "polemic". The scope of the GPL is to make sure, that the code is not re-used as part of proprietary software to compete with the original source code. See e.g. PlayStation 4 system software, JunOS, etc.

Since the GNU-fans are pushing hard for the GNU/Linux denomination, shouldn't we make it much clearer, that the entire Linux graphics stack is Freedesktop.org and push to call the family of Linux kernel-based operating systems: GNU/Linux/freedesktop.org?

What about Android (operating system)? There is much talk about Android-only device drivers, yet I've seen no explanation of this actually means. See my contributions to Free and open-source graphics device driver and understand that I am interested in a much better understanding of the technical POV of this. User:ScotXW^t@lk 10:41, 20 August 2014 (UTC)

Now that other applications also use the DRM API (i.e. Wayland) there is no more only defined by DRI. Also, tecnically, DRM is a kernel component (really a whole subsystem) and DRI is user space stuff, quite different and worth keeping apart.

libDRM is MIT-license (except 5 files from exynos driver, and the autotools files of course). You can check it in the libdrm sources. I repeat that the BSD folks don't touch anything with GPL or LGPL license, as they consider them "virals". Not my point of view or opinion but theirs. And because their attitude, they can't just pick up and merge the linux DRM code in their kernels, they need to check licenses and remove or substitute the L/GPL ones at least (and probably adapt the code to the BSD internals, quite different from linux internals). This is not a trivial task, so prove me that they are doing it before stating it in Wikipedia (WP:PROVEIT). It's easy: only a link is needed (better several links to achieve WP:VERIFY).

I don't know about Android graphics stack, but since DRM includes several ARM GPUs (like Samsung's exynos and such) it's possible that Android also uses DRM at the lowest-level. In any case, it also need to be documented before stating it as a fact. --JavierCantero (talk) 08:13, 22 August 2014 (UTC)

This article from LWN sumarizes the current situation of DRM in *BSD operating systems: Graphics drivers and the BSDs. --JavierCantero (talk) 15:18, 25 October 2014 (UTC)

Merger proposal

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

The result of this discussion was to merge --JavierCantero (talk) 15:53, 12 May 2016 (UTC)

---

I'd like to propose to merge Graphics Execution Manager into Direct Rendering Manager. Really GEM, as part of DRM, never should have had a separate article (except as a highly technical expansion, but that's not the case). GEM can't be explained outside the scope of DRM, and any description of DRM is incomplete without GEM. Furthermore, GEM is currently very brief and incomplete, and it's easy to migrate its content to its own section in DRM. --JavierCantero (talk) 11:05, 10 August 2014 (UTC)

• I second that motion. User:ScotXW^t@lk 10:24, 20 August 2014 (UTC)

It's been almost two years and nobody has opposed the merge of Graphics Execution Manager, so I will proceed to do so. --JavierCantero (talk) 15:52, 12 May 2016 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Render Nodes subsection in History section

I stumbled upon this article while looking for something else and noticed that my name is being mentioned in the Direct_Rendering_Manager#Render_nodes_2 section. I'd like to clarify a few things about that work, because as it reads now, it's not accurate. Also, as it will become clear later, I think that this little subsection should be removed. It is true that Dave Airlie started the intial work on Render Nodes in an effort so add multiseat support and it is true that I followed up on that work. The objective was to allow the user space to partition the GPU's display resources into disjoint subsets and create de-facto sub-devices within a device. This would allow multiple, independent instances of X to run on the top of the same GPU. However, what was ultimately merged in the kernel under name "Render Node" (David Herrmann's work) is only a support for a render device with no display resources.

The remaining parts (mechanism to partition display resources) were left unmerged and people started to refer to them as "Modeset Nodes". David Herrmann has a good explanation of Render Nodes and Modeset Nodes in his blog [1]. So the subsection in question is confusing in the sense that it mixes up the functionality of the two node types. At this time, it is still unclear when or if or in which form the Modeset Nodes will be merged.

I propose that the Direct_Rendering_Manager#Render_nodes_2 section be removed on several grounds. First, as I explained above, this is still very much work in progress, so it's a moving target. Second, there is already a correct description of current state of the Render Node feature in Direct_Rendering_Manager#Render_nodes. Third, the way it is written now, the Direct_Rendering_Manager#History section leaves the reader with an impression that Render Nodes are some kind of a big deal, where in reality it's just another feature among the many. Finally, on a personal note, it gives me more credit that I rightfully deserve :-).

Ihadzic (talk) 01:38, 5 December 2014 (UTC)

I wrote it, so I can remove it without hesitation. But I want to point out a few things. First, my intention was (is) not to mix the technical description with non-technical aspects (hence the History section describing the who-when-where). Another possible approach is fully describe each item in its section, mixing history, authors, ... with the description of the technology itself, but personally I find it confusing. Second, the credit may seem disproportionate, but that's because the History section is hardly developed. In the draft that I maintain in User:JavierCantero/Direct Rendering Manager#Recent developments there are 3 "recent developments", and the larger text should correspond (IMHO) the atomic modesetting and pageflip. Besides, the general history of the DRM subsystem should be much longer, make the "recent developments" section look smaller. Third, the link you provide [2] is already in there (cite [26] now) and is the source of credit for Dave and you: "As part of the X.org Foundation mentoring organization, I will try to pick up the work from Ilija Hadzic, Dave Airlie, Kristian Hoegsberg, Martin Peres and others", with the links [24] and [25] used as proof, extracted directly from there. Each statement in Wikipedia must be backed by a source, and I read and used them to try to assemble a narrative discourse based on those links. Sorry if I did not understand the story correctly, and thanks for the clarification. --JavierCantero (talk) 11:52, 5 December 2014 (UTC)

Kernel mode setting

Kernel mode setting – what is it? Well, "Kernel mode setting" is yet another brain-damage denomination for a kernel component/subsystem/API/paradigm switch/you-name it. Maybe we should start calling "it" the "DRM Mode-Setting Interface".

The naming, again, can only be understood if put into some historical context. Long time ago, the was the Device Dependent X (DDX). This (still) is a device driver for the graphics card and part of the x-server. Then DRM was created, and some time after, functionality regarding the mode-setting was moved from the DDX into the DRM. The new code and the interface it offer to user-space has been called KMS (kernel mode-setting) ever since. User:ScotXW^t@lk 13:17, 14 October 2015 (UTC)

I started a draft of that section (it's here), but it's not finished. In fact, that's only the very beginning. I can move it to the article right now as it is, or I can wait, do more writing —when I have time— and move it in a more polished state. --JavierCantero (talk) 14:04, 14 October 2015 (UTC)

Nice. But please be more precise and replace "video card" with "display controller", e.g. mobile devices don't have a video card. Also, the "3D engine" and the "display controller" could be from different manufacturers! Then please do use a link to Device Dependent X (DDX) and explain this ancient piece of junk there. Last but not least it could be less correct but more usefull to link to the article X.Org Server rather then X Server. User:ScotXW^t@lk 10:05, 19 October 2015 (UTC)

You are right, "video card" is not longer a proper card in many current computing devices, but there's the thing: the mode-setting is not only for the "display controller" part, the 3D engine also needs to be configured to generate the proper mode into the framebuffer as expected by the display controller. So it's a property of the entire set GPU+VRAM+Display Controller, not one in particular. How we could call it? Graphics adapter? It redirects to video card. The vast majority of people still calls them video cards, despite being discrete or integrated GPUs. It's hard to tell what is the best choice.

Another question: the problem with X.Org Server link is that DRM predates X.Org since it starts when the code was called XFree86, so pointing to X.Org server could be a bit confusing from a historical point of view. Opinions? --JavierCantero (talk) 15:04, 19 October 2015 (UTC)

"the 3D engine also needs to be configured to generate the proper mode into the framebuffer as expected by the display controller" exactly! Does a CPU or a GPU need to be a distinct chip/die, or could it share the same die with all sorts of other ASICs? Anyway, what is a "chip"? Does it refer to a "die" or to a "chip carrier package"?

I propose the article X.Org Server because the article X server is a redirect to X Window System. That article is pure confusion! Template:XWinSys lists a couple of alternative X servers. I inserted SurfaceFlinger into the article display server, but some graphics/more text would be cool. User:ScotXW^t@lk 14:06, 26 October 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Direct Rendering Manager. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added {{dead link}} tag to https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/README.drm
• Added archive https://web.archive.org/web/20160405145025/http://www.botchco.com:80/agd5f/?p=51 to http://www.botchco.com/agd5f/?p=51

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 16:30, 13 December 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on Direct Rendering Manager. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20150210173401/http://airlied.livejournal.com/71734.html to http://airlied.livejournal.com/71734.html
• Corrected formatting/usage for http://www.botchco.com/agd5f/?p=51

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 20:15, 5 April 2017 (UTC)

Driving Virtual Reality from Linux – support for Head-mounted displays

File:New Linux lease infrastructure.png

We can now lease connector/CRTC pairs to applications (yes, this should be redone in SVG)

Hi, interested people could watch the video "Driving Virtual Reality from Linux" on YouTube of Keith Packard's talk https://rego.linux.conf.au/schedule/presentation/46/ at LCA2018. He talks about the changes done to DRM (Linux kernel) and XRandr (X11 augment) to enable support for Head-mounted display (HMDs). The money for the development came from Valve Corporation. User:ScotXW^t@lk 20:05, 27 January 2018 (UTC)

a) Talk pages are not a forum. As the policy says: bear in mind that article talk pages exist solely to discuss how to improve articles; they are not for general discussion about the subject of the article, nor are they a help desk for obtaining instructions or technical assistance.

b) You can't assign the copyright of a screenshot as if it's yours (see Commons:Screenshots). Please provide the license details of the original source.

c) The contribution in the article is very poor: it doesn't provide any explanation or context that links it with the subject of the article.

d) the mentions to a sponsor sound like advertising.

--JavierCantero (talk) 09:30, 29 January 2018 (UTC)

Good job

Just some nice words — Preceding unsigned comment added by Maxorazon (talk • contribs) 20:44, 29 November 2021 (UTC)

Need clarification on PRIME

The statement of:

> The trend to include two GPUs in a computer—a discrete GPU and an integrated one—led to new problems such as GPU switching that also needed to be solved at the DRM layer. In order to match the Nvidia Optimus technology, DRM was provided with GPU offloading abilities, called PRIME

seems contradict with:

> While historically problematic, the binary Nvidia driver since beta version 435.17 officially supports Optimus render offloading for OpenGL and Vulkan applications under the name "PRIME"

so is this "PRIME" are part of NVIDIA or a separate thing? or maybe I just misunderstand what is PRIME ReYuki (talk) 07:59, 6 August 2024 (UTC)