This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
This article is within the scope of WikiProject Linux, a collaborative effort to improve the coverage of Linux on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.LinuxWikipedia:WikiProject LinuxTemplate:WikiProject LinuxLinux articles
This article is within the scope of WikiProject Computer graphics, a collaborative effort to improve the coverage of computer graphics on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Computer graphicsWikipedia:WikiProject Computer graphicsTemplate:WikiProject Computer graphicscomputer graphics articles
This article is within the scope of WikiProject Technology, a collaborative effort to improve the coverage of technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.TechnologyWikipedia:WikiProject TechnologyTemplate:WikiProject TechnologyTechnology articles
This article links to one or more target anchors that no longer exist.
[[AMD Accelerated Processing Unit#Puma.2B architecture .282015.29: Carrizo-L .28laptop and mobile processors.29|Carrizo]] The anchor (#Puma.2B architecture .282015.29: Carrizo-L .28laptop and mobile processors.29) has been deleted by other users before.
Please help fix the broken anchors. You can remove this template after fixing the problems. | Reporting errors
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).
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?
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)[reply]
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.
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)[reply]
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.
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 :-).
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)[reply]
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:ScotXWt@lk13:17, 14 October 2015 (UTC)[reply]
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)[reply]
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:ScotXWt@lk10:05, 19 October 2015 (UTC)[reply]
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)[reply]
"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 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:
When you have finished reviewing my changes, please set the checked parameter below to trueorfailed 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.
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:
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.
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.
