Re: DRM enhancements document
Hi, On Tue, Sep 04, 2007 at 10:52:41AM -0700, Jesse Barnes wrote: On Sunday, September 2, 2007 6:21 pm [EMAIL PROTECTED] wrote: As for EDID, I totally agree that this can be done in user space just fine. What I'm saying is that no central daemon is required for that. Handling this data should be totally uncritical -- it can be done by a library linked to the actual client processes. (X server, console etc.) Ideally, using a DRM backend to a generic library like libggi, which adds a lot of additional flexibility :-) Right, there's no reason most of this code can't be in a set of libraries. Nor is there any reason to *require* the use of a gfx daemon in many cases. It's just that for some of the cases we have in mind (multiple users, each with multiple clients, possibly doing direct rendering), a gfx daemon to arbitrate things may be a good approach. Yeah, I guess some kind of daemon is necessary to manage access policy in more complex cases, like multiple physical users. However, the design should not *depend* on such a daemon. Also, I don't think this daemon really needs to do an awful lot: Basically, it only has to assign the available devices to the various users. Once the devices are assigned, there is no further need for any third party: Probing hardware capabilities, determining available modes, setting a desired mode -- this can all be done by the user process with the help of the kernel; there are no further policy decisions involved with that. Also, I don't think that assigning the devices requires any special mechanism. Seems to me that it boils down to setting ordinary file access permissions on the graphics device files. As for multiple clients: This is actually only interesting when having multiple clients *on one VT*, i.e. when using an X server, or maybe some other windowing environment. However, this manager only needs to manage the clients on *one* VT -- this doesn't require special privileges, and can be done by the X server itself. If there is another server on a different VT, it can do it's own management for that VT. Again, no need for a system-wide daemon. -antrik- - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Sunday, September 2, 2007 6:21 pm [EMAIL PROTECTED] wrote: Hi, On Fri, Aug 24, 2007 at 08:31:10AM -0700, Jesse Barnes wrote: On Thursday, August 23, 2007 6:44:49 pm [EMAIL PROTECTED] wrote: I am *not* opposed to a scheme where userspace has to provide information how to set up a desired mode. (Although I'm not conviced it's really necessary -- both Keith Packard and Dave Airlie argued that mode setting is simple enough to be done in the kernel completely...) I'm not sure what you mean here--the kernel does fully set the mode in this scheme, all userspace does is provide the mode info (timings, etc.). Well, some people argue that even the timings etc. could be calculated directly in the kernel -- unless I totally misunderstood their remarks. Anyways, my point was that I'm fine with both variants. Yeah, that could be done either way; in fact the kernel already has some timing formulas builtin. We could add a GTF version if needed. At a minimum, there must be a program to determine which outputs have monitors attached, and what modes are available on those monitors. It's possible this could be hardcoded in simple or embedded cases, but for a dynamic system it should probably be done in userspace, since EDID overrides will be fairly common, and various platform specific quirks will probably be necessary. I'm pretty sure detecting the outputs is something that can be done in the kernel without problems. And it *should* be done there, so the kernel can actually manage the available hardware. Yeah, I think output enumeration should be done in the kernel. But figuring out what's attached to a given output and what it supports is a little more burdensome (e.g. EDID as you mention below): not only are there a huge number of devices and combinations (think of just monitors and KVMs as an example) but myriad broken or simple devices that provide incorrect information or no information at all. As for EDID, I totally agree that this can be done in user space just fine. What I'm saying is that no central daemon is required for that. Handling this data should be totally uncritical -- it can be done by a library linked to the actual client processes. (X server, console etc.) Ideally, using a DRM backend to a generic library like libggi, which adds a lot of additional flexibility :-) Right, there's no reason most of this code can't be in a set of libraries. Nor is there any reason to *require* the use of a gfx daemon in many cases. It's just that for some of the cases we have in mind (multiple users, each with multiple clients, possibly doing direct rendering), a gfx daemon to arbitrate things may be a good approach. Jesse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
Hi, On Fri, Aug 24, 2007 at 08:31:10AM -0700, Jesse Barnes wrote: On Thursday, August 23, 2007 6:44:49 pm [EMAIL PROTECTED] wrote: I am *not* opposed to a scheme where userspace has to provide information how to set up a desired mode. (Although I'm not conviced it's really necessary -- both Keith Packard and Dave Airlie argued that mode setting is simple enough to be done in the kernel completely...) I'm not sure what you mean here--the kernel does fully set the mode in this scheme, all userspace does is provide the mode info (timings, etc.). Well, some people argue that even the timings etc. could be calculated directly in the kernel -- unless I totally misunderstood their remarks. Anyways, my point was that I'm fine with both variants. However, I do not see why some central daemon should be involved when an X server or framebuffer application or console driver or whatever wants to set up a mode on its VT; or if the system is suspended/resumed. At a minimum, there must be a program to determine which outputs have monitors attached, and what modes are available on those monitors. It's possible this could be hardcoded in simple or embedded cases, but for a dynamic system it should probably be done in userspace, since EDID overrides will be fairly common, and various platform specific quirks will probably be necessary. I'm pretty sure detecting the outputs is something that can be done in the kernel without problems. And it *should* be done there, so the kernel can actually manage the available hardware. As for EDID, I totally agree that this can be done in user space just fine. What I'm saying is that no central daemon is required for that. Handling this data should be totally uncritical -- it can be done by a library linked to the actual client processes. (X server, console etc.) Ideally, using a DRM backend to a generic library like libggi, which adds a lot of additional flexibility :-) -antrik- - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
Hi, On Fri, Aug 24, 2007 at 06:08:57AM +0300, Daniel Stone wrote: On Fri, Aug 24, 2007 at 03:50:04AM +0200, [EMAIL PROTECTED] wrote: Graphics chips are complicated, but the bulk of the complexity is not in modesetting. Do you really think that modesetting (and other graphics hardware management) is more complex than say a wireless network driver? The API modesetting requires you to export is vastly more complicated than the API a wireless network driver requires you to export; But the discussion was about the complexity of the code in the kernel, not of the API... -antrik- - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Aug 23, 07 12:00:39 +0300, Daniel Stone wrote: If you have ioctl number 32, your next free one is 43, and you want to change the semantics of UPDATE_WINDOW, then you rename 32 to UPDATE_WINDOW_OLD, create UPDATE_WINDOW as 43 with the new structure, and handle both cases. I consider this giving headaches. I never had any similar issues with a tag-based approach. The problem there comes with the added complexity of parsing all the data. Maybe I'm a bit biased (had an Amiga for a long time, and this was the base argument parsing for OS routines), but it worked astonishingly well. If every tag is int32 and its parameter int32 as well, this isn't too problematic. Question is whether everything needed can be represented in 32 bit values, strings are a completely different concept and don't match well here, as pointers are probably difficult to handle over the user land / kernel barrier... Easy to use, hard to use right. Right. Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Thursday, August 23, 2007 6:44:49 pm [EMAIL PROTECTED] wrote: I am *not* opposed to a scheme where userspace has to provide information how to set up a desired mode. (Although I'm not conviced it's really necessary -- both Keith Packard and Dave Airlie argued that mode setting is simple enough to be done in the kernel completely...) I'm not sure what you mean here--the kernel does fully set the mode in this scheme, all userspace does is provide the mode info (timings, etc.). However, I do not see why some central daemon should be involved when an X server or framebuffer application or console driver or whatever wants to set up a mode on its VT; or if the system is suspended/resumed. At a minimum, there must be a program to determine which outputs have monitors attached, and what modes are available on those monitors. It's possible this could be hardcoded in simple or embedded cases, but for a dynamic system it should probably be done in userspace, since EDID overrides will be fairly common, and various platform specific quirks will probably be necessary. As I pointed out in my FOSDEM talk, the kernel does *not* strictly need to know how to determine what modes are available, or how to set up a mode with desired properties -- this can be handled by the client. However, the kernel *does* need to know enough about the hardware, to be able to safely switch between arbitrary client-supplied modes. (Or back to a default mode, if a client dies.) Yep, no disagreement here. Generally the kernel can grab the currently programmed mode at boot time, and assume its fairly safe should something catastrophic happen. Jesse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Thursday, August 23, 2007 8:38:46 pm Tiago Vignatti wrote: I hope you guys are not forgetting who wants to start two (or more) instances of the Xorg server (for multiseat purposes or what ever). Oh definitely not. This work should make muliseat much easier. In this case, the daemon - in kernel or not - would be useful to handle the routing of the VGA code to the right legacy cards. An external daemon is also needed to control the resources provided by the vga card in the case of multiseat (which would be overlapped in a multi-head environment if the Resource Access Control (RAC) never existed on Xorg). Yeah, this subsystem might be a good place for benh's VGA arbitration kernel code... Jesse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
At a minimum, there must be a program to determine which outputs have monitors attached, and what modes are available on those monitors. It's possible this could be hardcoded in simple or embedded cases, but for a dynamic system it should probably be done in userspace, since EDID overrides will be fairly common, and various platform specific quirks will probably be necessary. It needs to be hotpluggable to work properly on modern systems. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Wed, 2007-08-22 at 20:09 +0200, Matthias Hopf wrote: On Aug 22, 07 17:21:09 +0300, Daniel Stone wrote: Without a version field, this is made impossible, something that must be avoided at all costs. Except that your ioctl then becomes variably-sized unless you add loads of padding and hope for the best. If every tag is int32 and its parameter int32 as well, this isn't too problematic. Right, e.g. the actual ioctl struct could just contain pointers to the tag arrays. Question is whether everything needed can be represented in 32 bit values, strings are a completely different concept and don't match well here, as pointers are probably difficult to handle over the user land / kernel barrier... They basically need to be passed as 64 bit integers, and care must be taken wrt alignment of struct members. But yeah, FWIW I don't think there's any real technical barriers preventing this approach. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Wed, Aug 22, 2007 at 08:09:18PM +0200, Matthias Hopf wrote: On Aug 22, 07 17:21:09 +0300, Daniel Stone wrote: But that exactly makes version control difficult (lots of cases, especially if the exact requirements aren't clear from day one). I honestly don't understand the problem. Your ioctl number is _that_ request. It's not referring to a vague concept, but a single structure you've already specified. Well, you already know what parameters you need for selecting crtcs/outputs/modes/etc.? I would assume that the needed parameters will change over time, as new features are thought of etc. And I could imagine that this happens frequently. Yes. So, just as with requests, when you change the parameters, you no longer have the same ioctl. So you renumber. If you have ioctl number 32, your next free one is 43, and you want to change the semantics of UPDATE_WINDOW, then you rename 32 to UPDATE_WINDOW_OLD, create UPDATE_WINDOW as 43 with the new structure, and handle both cases. I consider this giving headaches. I never had any similar issues with a tag-based approach. The problem there comes with the added complexity of parsing all the data. Without a version field, this is made impossible, something that must be avoided at all costs. Except that your ioctl then becomes variably-sized unless you add loads of padding and hope for the best. If every tag is int32 and its parameter int32 as well, this isn't too problematic. Question is whether everything needed can be represented in 32 bit values, strings are a completely different concept and don't match well here, as pointers are probably difficult to handle over the user land / kernel barrier... Easy to use, hard to use right. Cheer,s Daniel signature.asc Description: Digital signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
Hi, On Mon, Aug 20, 2007 at 05:27:43PM +0200, Matthias Hopf wrote: On Aug 12, 07 17:50:12 +0200, [EMAIL PROTECTED] wrote: I fail to understand why you want to put the manager in a daemon, instead of just letting the kernel do the management, like it does for all other hardware. Why is graphics hardware supposed to be different in this regard? You just cannot compare graphics hardware with any other hardware at all. Graphics chips are more complicated than any CPU on the market, which other hardware type is similar? Graphics chips are complicated, but the bulk of the complexity is not in modesetting. Do you really think that modesetting (and other graphics hardware management) is more complex than say a wireless network driver? -antrik- - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
Hi, On Sun, Aug 12, 2007 at 09:36:32PM -0700, Jesse Barnes wrote: On Sunday, August 12, 2007 8:50:12 am [EMAIL PROTECTED] wrote: I fail to understand why you want to put the manager in a daemon, instead of just letting the kernel do the management, like it does for all other hardware. Why is graphics hardware supposed to be different in this regard? Graphics hardware is somewhat different in this regard due to the large userland component to the driver. The userland component, translating abstract requests into low-level hardware-specific commands, is is large; and this is fine. My point was that *management* -- which is *not* large -- belongs into the kernel. It just doesn't make sense to have console setup and console switching -- which, on a monolithic system, is part of the kernel -- depend on a userspace daemon. This would be almost as bad as the current situation, where a userspace daemon called X server is doing all the management... Well, I'm not sure it's quite as bad as you make out. The kernel must still come up with *some* initial mode, though this may typically be whatever the bootloader gave us at handoff time. Once the kernel has started init, however, a userspace program (call it 'gfxmgr') can do full output probing (i.e. monitor mode detection, output-crtc mapping, and initial mode picking) taking better advantage of the hardware. The 'gfxmgr' program should be *much* smaller than the X server, since it will be doing far less--just output probing and access control, not full mode setting (the kernel will do this), protocol management, and client scheduling. Well, obviously it's an improvement to move this functionality out of the big server; yet the fundamental problems remain the same. I am *not* opposed to a scheme where userspace has to provide information how to set up a desired mode. (Although I'm not conviced it's really necessary -- both Keith Packard and Dave Airlie argued that mode setting is simple enough to be done in the kernel completely...) However, I do not see why some central daemon should be involved when an X server or framebuffer application or console driver or whatever wants to set up a mode on its VT; or if the system is suspended/resumed. As I pointed out in my FOSDEM talk, the kernel does *not* strictly need to know how to determine what modes are available, or how to set up a mode with desired properties -- this can be handled by the client. However, the kernel *does* need to know enough about the hardware, to be able to safely switch between arbitrary client-supplied modes. (Or back to a default mode, if a client dies.) Any scheme that tries to delegate this knowledge to some external daemon, is inherently complicated and fragile, and will end up with the very same problems we have today. -antrik- - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Fri, Aug 24, 2007 at 03:50:04AM +0200, [EMAIL PROTECTED] wrote: Graphics chips are complicated, but the bulk of the complexity is not in modesetting. Do you really think that modesetting (and other graphics hardware management) is more complex than say a wireless network driver? The API modesetting requires you to export is vastly more complicated than the API a wireless network driver requires you to export; noting also that a wireless network driver requires a userspace component to do WPA anyway. signature.asc Description: Digital signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
Hi, [EMAIL PROTECTED] escreveu: On Sun, Aug 12, 2007 at 09:36:32PM -0700, Jesse Barnes wrote: On Sunday, August 12, 2007 8:50:12 am [EMAIL PROTECTED] wrote: I fail to understand why you want to put the manager in a daemon, instead of just letting the kernel do the management, like it does for all other hardware. Why is graphics hardware supposed to be different in this regard? Graphics hardware is somewhat different in this regard due to the large userland component to the driver. The userland component, translating abstract requests into low-level hardware-specific commands, is is large; and this is fine. My point was that *management* -- which is *not* large -- belongs into the kernel. It just doesn't make sense to have console setup and console switching -- which, on a monolithic system, is part of the kernel -- depend on a userspace daemon. This would be almost as bad as the current situation, where a userspace daemon called X server is doing all the management... Well, I'm not sure it's quite as bad as you make out. The kernel must still come up with *some* initial mode, though this may typically be whatever the bootloader gave us at handoff time. Once the kernel has started init, however, a userspace program (call it 'gfxmgr') can do full output probing (i.e. monitor mode detection, output-crtc mapping, and initial mode picking) taking better advantage of the hardware. The 'gfxmgr' program should be *much* smaller than the X server, since it will be doing far less--just output probing and access control, not full mode setting (the kernel will do this), protocol management, and client scheduling. Well, obviously it's an improvement to move this functionality out of the big server; yet the fundamental problems remain the same. I am *not* opposed to a scheme where userspace has to provide information how to set up a desired mode. (Although I'm not conviced it's really necessary -- both Keith Packard and Dave Airlie argued that mode setting is simple enough to be done in the kernel completely...) However, I do not see why some central daemon should be involved when an X server or framebuffer application or console driver or whatever wants to set up a mode on its VT; or if the system is suspended/resumed. As I pointed out in my FOSDEM talk, the kernel does *not* strictly need to know how to determine what modes are available, or how to set up a mode with desired properties -- this can be handled by the client. However, the kernel *does* need to know enough about the hardware, to be able to safely switch between arbitrary client-supplied modes. (Or back to a default mode, if a client dies.) Any scheme that tries to delegate this knowledge to some external daemon, is inherently complicated and fragile, and will end up with the very same problems we have today. I hope you guys are not forgetting who wants to start two (or more) instances of the Xorg server (for multiseat purposes or what ever). In this case, the daemon - in kernel or not - would be useful to handle the routing of the VGA code to the right legacy cards. An external daemon is also needed to control the resources provided by the vga card in the case of multiseat (which would be overlapped in a multi-head environment if the Resource Access Control (RAC) never existed on Xorg). -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Aug 20, 07 19:51:31 +0300, Daniel Stone wrote: On Mon, Aug 20, 2007 at 05:27:43PM +0200, Matthias Hopf wrote: On Aug 12, 07 17:50:12 +0200, [EMAIL PROTECTED] wrote: On Thu, Aug 02, 2007 at 07:31:01PM +0200, Jerome Glisse wrote: There should be master (possibly one for each card) which be the only one being able to do this call: DRM_IOCTL_MODE_SETCRTC - set CRTC parameters Please be sure that if you design this using ioctls the design should be forward and backward compatible. AFAICS the only way to ensure this is some sort of tag-based parameter space (parameters are a list of tag,value pairs, terminated by a special tag). Otherwise you're stuck with one parameter list, which you cannot enhance easily, and version control both in user and kernel space will be a nightmare. With tags you can just ignore the tags you don't know about. Well, either that, or you can have a version field as the very first member (think: X11 requests), or simply bump the ioctl number every time you change the API (think: shared libraries). But that exactly makes version control difficult (lots of cases, especially if the exact requirements aren't clear from day one). Without a version field, this is made impossible, something that must be avoided at all costs. Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Aug 20, 07 15:45:00 -0700, Keith Packard wrote: On Mon, 2007-08-20 at 17:27 +0200, Matthias Hopf wrote: Because we won't get an ix86 emulator in kernel space, Linus and others have been pretty clear about that. Graphics hardware sometimes needs BIOS calls, on non-i386 hardware that has to be done by an emulator. Post-boot, for the primary card, I don't know what hardware requires BIOS calls at ths point. We certainly shouldn't encourage people to build drivers that do. No. But you already limit yourself to the primary card, a new design shouldn't be limited that way. And an astonishingly big number of people have to rely on vesa fb, because driver development for their hardware sucks big time (no docs, no hardware in time, etc.). Currently AFAIK we don't allow changing the resolution here during runtime, I'd like to see a new framework being flexible enough with this respect. Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Wed, Aug 22, 2007 at 03:42:49PM +0200, Matthias Hopf wrote: On Aug 20, 07 19:51:31 +0300, Daniel Stone wrote: On Mon, Aug 20, 2007 at 05:27:43PM +0200, Matthias Hopf wrote: On Aug 12, 07 17:50:12 +0200, [EMAIL PROTECTED] wrote: Please be sure that if you design this using ioctls the design should be forward and backward compatible. AFAICS the only way to ensure this is some sort of tag-based parameter space (parameters are a list of tag,value pairs, terminated by a special tag). Otherwise you're stuck with one parameter list, which you cannot enhance easily, and version control both in user and kernel space will be a nightmare. With tags you can just ignore the tags you don't know about. Well, either that, or you can have a version field as the very first member (think: X11 requests), or simply bump the ioctl number every time you change the API (think: shared libraries). But that exactly makes version control difficult (lots of cases, especially if the exact requirements aren't clear from day one). I honestly don't understand the problem. Your ioctl number is _that_ request. It's not referring to a vague concept, but a single structure you've already specified. If you have ioctl number 32, your next free one is 43, and you want to change the semantics of UPDATE_WINDOW, then you rename 32 to UPDATE_WINDOW_OLD, create UPDATE_WINDOW as 43 with the new structure, and handle both cases. This is what we've done for ioctl BC in our kernel tree, and it's worked fine. Without a version field, this is made impossible, something that must be avoided at all costs. Except that your ioctl then becomes variably-sized unless you add loads of padding and hope for the best. Cheers, Daniel signature.asc Description: Digital signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Wed, Aug 22, 2007 at 03:47:31PM +0200, Matthias Hopf wrote: No. But you already limit yourself to the primary card, a new design shouldn't be limited that way. And an astonishingly big number of people have to rely on vesa fb, because driver development for their hardware sucks big time (no docs, no hardware in time, etc.). Currently AFAIK we don't allow changing the resolution here during runtime, I'd like to see a new framework being flexible enough with this respect. Why on earth do you need vesafb? Just use the vesa driver and be done with it. (Also, there's nothing preventing runtime mode changes when using the fbdev driver. If there's a missing hook, then just add it.) Cheers, Daniel signature.asc Description: Digital signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Wednesday, August 22, 2007 6:47:31 am Matthias Hopf wrote: On Aug 20, 07 15:45:00 -0700, Keith Packard wrote: On Mon, 2007-08-20 at 17:27 +0200, Matthias Hopf wrote: Because we won't get an ix86 emulator in kernel space, Linus and others have been pretty clear about that. Graphics hardware sometimes needs BIOS calls, on non-i386 hardware that has to be done by an emulator. Post-boot, for the primary card, I don't know what hardware requires BIOS calls at ths point. We certainly shouldn't encourage people to build drivers that do. No. But you already limit yourself to the primary card, a new design shouldn't be limited that way. And an astonishingly big number of people have to rely on vesa fb, because driver development for their hardware sucks big time (no docs, no hardware in time, etc.). Currently AFAIK we don't allow changing the resolution here during runtime, I'd like to see a new framework being flexible enough with this respect. Well, you'll still be able to run current code, hopefully that's flexible enough. If there's no native driver available, I don't really see how any of the new features can be reasonably provided (e.g. memory management, kernel suspend/resume support, native modesetting in the kernel). OTOH, I don't think we want to break tools like vbetool or prevent basic VESA drivers from working, it's just that users won't get anything new from them... Jesse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Aug 22, 07 17:21:09 +0300, Daniel Stone wrote: But that exactly makes version control difficult (lots of cases, especially if the exact requirements aren't clear from day one). I honestly don't understand the problem. Your ioctl number is _that_ request. It's not referring to a vague concept, but a single structure you've already specified. Well, you already know what parameters you need for selecting crtcs/outputs/modes/etc.? I would assume that the needed parameters will change over time, as new features are thought of etc. And I could imagine that this happens frequently. If you have ioctl number 32, your next free one is 43, and you want to change the semantics of UPDATE_WINDOW, then you rename 32 to UPDATE_WINDOW_OLD, create UPDATE_WINDOW as 43 with the new structure, and handle both cases. I consider this giving headaches. I never had any similar issues with a tag-based approach. Well, it's not my baby, I won't cry ;-) Just trying to give some help. Without a version field, this is made impossible, something that must be avoided at all costs. Except that your ioctl then becomes variably-sized unless you add loads of padding and hope for the best. If every tag is int32 and its parameter int32 as well, this isn't too problematic. Question is whether everything needed can be represented in 32 bit values, strings are a completely different concept and don't match well here, as pointers are probably difficult to handle over the user land / kernel barrier... CU Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Aug 12, 07 17:50:12 +0200, [EMAIL PROTECTED] wrote: On Thu, Aug 02, 2007 at 07:31:01PM +0200, Jerome Glisse wrote: There should be master (possibly one for each card) which be the only one being able to do this call: DRM_IOCTL_MODE_SETCRTC - set CRTC parameters Please be sure that if you design this using ioctls the design should be forward and backward compatible. AFAICS the only way to ensure this is some sort of tag-based parameter space (parameters are a list of tag,value pairs, terminated by a special tag). Otherwise you're stuck with one parameter list, which you cannot enhance easily, and version control both in user and kernel space will be a nightmare. With tags you can just ignore the tags you don't know about. I fail to understand why you want to put the manager in a daemon, instead of just letting the kernel do the management, like it does for all other hardware. Why is graphics hardware supposed to be different in this regard? Because we won't get an ix86 emulator in kernel space, Linus and others have been pretty clear about that. Graphics hardware sometimes needs BIOS calls, on non-i386 hardware that has to be done by an emulator. This is just one reason. One other is that you want to address graphics in user space anyways for performance reason. Of course, mode setting isn't exactly performance critical. You just cannot compare graphics hardware with any other hardware at all. Graphics chips are more complicated than any CPU on the market, which other hardware type is similar? Even high-speed interconnects like infiniband are trivial compared to that. That said, I'm not 100% confident that the currently discussed way is the right solution. OTOH I don't know the right solution myself either... Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Mon, Aug 20, 2007 at 05:27:43PM +0200, Matthias Hopf wrote: On Aug 12, 07 17:50:12 +0200, [EMAIL PROTECTED] wrote: On Thu, Aug 02, 2007 at 07:31:01PM +0200, Jerome Glisse wrote: There should be master (possibly one for each card) which be the only one being able to do this call: DRM_IOCTL_MODE_SETCRTC - set CRTC parameters Please be sure that if you design this using ioctls the design should be forward and backward compatible. AFAICS the only way to ensure this is some sort of tag-based parameter space (parameters are a list of tag,value pairs, terminated by a special tag). Otherwise you're stuck with one parameter list, which you cannot enhance easily, and version control both in user and kernel space will be a nightmare. With tags you can just ignore the tags you don't know about. Well, either that, or you can have a version field as the very first member (think: X11 requests), or simply bump the ioctl number every time you change the API (think: shared libraries). Cheers, Daniel signature.asc Description: Digital signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Mon, 2007-08-20 at 17:27 +0200, Matthias Hopf wrote: Because we won't get an ix86 emulator in kernel space, Linus and others have been pretty clear about that. Graphics hardware sometimes needs BIOS calls, on non-i386 hardware that has to be done by an emulator. Post-boot, for the primary card, I don't know what hardware requires BIOS calls at ths point. We certainly shouldn't encourage people to build drivers that do. This is just one reason. One other is that you want to address graphics in user space anyways for performance reason. Of course, mode setting isn't exactly performance critical. Without mode setting capabilities in the kernel, we cannot get S3 support working reliably. What we've done, however, is split the mechanism from the policy so that the kernel piece does no more than actually drive the hardware; configuration and the rest remain in user space where they belong. You just cannot compare graphics hardware with any other hardware at all. Graphics chips are more complicated than any CPU on the market, which other hardware type is similar? Even high-speed interconnects like infiniband are trivial compared to that. The kernel driver manages video mode selection, memory, interrupts, DMA and the basic ring. The rest of the driver is in user space, including all of the complicated language compilation bits. That said, I'm not 100% confident that the currently discussed way is the right solution. OTOH I don't know the right solution myself either... The correct solution is a kernel driver that manages the card configuration and resources. Anything else eliminates many of the desirable benefits of providing a kernel driver in the first place. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
Hi, On Thu, Aug 02, 2007 at 07:31:01PM +0200, Jerome Glisse wrote: There should be master (possibly one for each card) which be the only one being able to do this call: DRM_IOCTL_MODE_SETCRTC - set CRTC parameters [...] master (big boss) - X server (got its framebuffer) - X application - sub GL window of this application (might want to have its framebuffer) - GL application (dri) client running X application (got its framebuffer which can used as a texture by the compositor, hello redirected direct rendering :)) - EGL program (got its framebuffer) - Console (got its framebuffer) - GL app offscreen rendering (no framebuffer for scanout) I fail to understand why you want to put the manager in a daemon, instead of just letting the kernel do the management, like it does for all other hardware. Why is graphics hardware supposed to be different in this regard? It just doesn't make sense to have console setup and console switching -- which, on a monolithic system, is part of the kernel -- depend on a userspace daemon. This would be almost as bad as the current situation, where a userspace daemon called X server is doing all the management... -antrik- - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Sunday, August 12, 2007 8:50:12 am [EMAIL PROTECTED] wrote: Hi, On Thu, Aug 02, 2007 at 07:31:01PM +0200, Jerome Glisse wrote: There should be master (possibly one for each card) which be the only one being able to do this call: DRM_IOCTL_MODE_SETCRTC - set CRTC parameters [...] master (big boss) - X server (got its framebuffer) - X application - sub GL window of this application (might want to have its framebuffer) - GL application (dri) client running X application (got its framebuffer which can used as a texture by the compositor, hello redirected direct rendering :)) - EGL program (got its framebuffer) - Console (got its framebuffer) - GL app offscreen rendering (no framebuffer for scanout) I fail to understand why you want to put the manager in a daemon, instead of just letting the kernel do the management, like it does for all other hardware. Why is graphics hardware supposed to be different in this regard? Graphics hardware is somewhat different in this regard due to the large userland component to the driver. It just doesn't make sense to have console setup and console switching -- which, on a monolithic system, is part of the kernel -- depend on a userspace daemon. This would be almost as bad as the current situation, where a userspace daemon called X server is doing all the management... Well, I'm not sure it's quite as bad as you make out. The kernel must still come up with *some* initial mode, though this may typically be whatever the bootloader gave us at handoff time. Once the kernel has started init, however, a userspace program (call it 'gfxmgr') can do full output probing (i.e. monitor mode detection, output-crtc mapping, and initial mode picking) taking better advantage of the hardware. The 'gfxmgr' program should be *much* smaller than the X server, since it will be doing far less--just output probing and access control, not full mode setting (the kernel will do this), protocol management, and client scheduling. Of course, most of this has yet to be prototyped, though most of the code is already written (in some cases several times over), lying around in various projects... Jesse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
Jesse Barnes wrote: I finally found some time to create a new wiki page for all the modesetting/configuration related DRM enhancements we've been talking about: http://dri.freedesktop.org/wiki/DrmModesetting Please take a look and let me know what you think. I still have to go through all the feedback I received from the lkml post I made awhile back, and make sure it's captured (I think it is, albeit at a fairly high level mostly), and add more detail in the design and development sections. Jakub, hopefully you can go over it and add more detail about the userland APIs? Dave and Keith, we talked about the new device node scheme awhile back, but I only have notes on what the master node should be responsible for, did we have any new ioctls for the slave nodes? Ring buffer mapping, etc. should probably be there? Thanks, Jesse This likely does not really fit exactly in modesetting rework so sorry if i hijack this thread a bit. I have been thinking to vblank stuff in drm and i am wondering if while rearchitecturing the drm it would be nice to get rid of current vblank things and use fence instead. So having special fence for vblank, with a vblank fence queue for each crtc. If this was already in some plan ignore this mail :). Btw i think that some GPU can wait on vblank using cmd ie you don't need to ask the card to emit irq you just insert a cmd in stream which stall further cmd execution until vblank happen, this might be good for power consumption. And will also be nice with app trying to avoid flickering/tearing (mostly movie player). Concern is on application using things like GLX_SGI_video_sync as without using IRQ we likely miss some vblank and thus can't maintain accurate counter, thus maybe this fence vblank stuff might just be an addition to vblank rework you already proposed few weeks ago. Cheers, Jerome Glisse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Thu, 2007-08-02 at 17:44 +0200, Jerome Glisse wrote: Btw i think that some GPU can wait on vblank using cmd ie you don't need to ask the card to emit irq you just insert a cmd in stream which stall further cmd execution until vblank happen, this might be good for power consumption. It's generally a bad idea because it prevents the GPU from doing anything else that could be done before vertical blank. And will also be nice with app trying to avoid flickering/tearing (mostly movie player). IME this can be achieved perfectly by scheduling the buffer swap to be executed from the interrupt handler, see the i915 DRM. Concern is on application using things like GLX_SGI_video_sync as without using IRQ we likely miss some vblank and thus can't maintain accurate counter, thus maybe this fence vblank stuff might just be an addition to vblank rework you already proposed few weeks ago. Yes, while vblank fences would be a useful addition (without them, the above swap scheduling is prone to a race condition with multiple logical CPUs), I don't think they can be a replacement for the current vblank mechanisms, at least not all of them. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
Michel Dänzer wrote: On Thu, 2007-08-02 at 17:44 +0200, Jerome Glisse wrote: Btw i think that some GPU can wait on vblank using cmd ie you don't need to ask the card to emit irq you just insert a cmd in stream which stall further cmd execution until vblank happen, this might be good for power consumption. It's generally a bad idea because it prevents the GPU from doing anything else that could be done before vertical blank. This is true on cards with a single command stream - if you had per-context ringbuffers and a hardware scheduler, it might be better. Unfortunately, you still end up forcing the cliprects not to change, unless you also have some hardware mechanism for that, which I think is pretty rare nowdays. Hmm. Maybe you could use the frontbuffer alpha bits as a window id. You'd still need to either lock the window position, or find some way of telling the hardware about window position changes, or... something else... Anyway, it gets complicated... Keith - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
Jesse Barnes wrote: I finally found some time to create a new wiki page for all the modesetting/configuration related DRM enhancements we've been talking about: http://dri.freedesktop.org/wiki/DrmModesetting Please take a look and let me know what you think. I still have to go through all the feedback I received from the lkml post I made awhile back, and make sure it's captured (I think it is, albeit at a fairly high level mostly), and add more detail in the design and development sections. Jakub, hopefully you can go over it and add more detail about the userland APIs? Dave and Keith, we talked about the new device node scheme awhile back, but I only have notes on what the master node should be responsible for, did we have any new ioctls for the slave nodes? Ring buffer mapping, etc. should probably be there? Thanks, Jesse This time i do not hijack the thread :) So we just discussed with Jakob and Jesse on this on irc and here is what i believe we agreed on: There should be master (possibly one for each card) which be the only one being able to do this call: DRM_IOCTL_MODE_SETCRTC - set CRTC parameters (which i assume is set the mode, associat crtc-output and set framebuffer) Other call can be made by any others client: - DRM_IOCTL_MODE_ADDFB - add a new FB object - DRM_IOCTL_MODE_RMFB - remove an FB object - DRM_IOCTL_MODE_GETFB - get info about an FB object ... In order to make this possible pinning a buffer will be done in SETCRTC in which a FB that can fit the mode must be given. Thus ADDFB will create a buffer but not pinned until used for scan out, so pinning happen in SETCRTC. Note that each client does not necessarily create its own framebuffer. The idea behind this is that we can have a daemon (one for each card or one for all of them) and this daemon can take framebuffer from client and easily change btw scan out buffer (switching from X to console will be made by the daemon and X might just not be aware of this). There is other use case one can come up with such scheme like developping EGL app under X and display its framebuffer by using it as a texture in a GL app. So there is master (big boss of crtcs) and client or slave humble provider of framebuffer. One point that might be also usefull is relation btw client should we do somethings like parent/child ? So this might looks like this (left are parent) master (big boss) - X server (got its framebuffer) - X application - sub GL window of this application (might want to have its framebuffer) - GL application (dri) client running X application (got its framebuffer which can used as a texture by the compositor, hello redirected direct rendering :)) - EGL program (got its framebuffer) - Console (got its framebuffer) - GL app offscreen rendering (no framebuffer for scanout) The idea behind this is that parent can use any object created by their child in anyway they like (this why we call them parent as parent always play with toy created by their child :o)). Maybe parent could also put restriction on what their child can do (which is another characteristics of parents). If people are happy with this i will update the wiki. Cheers, Jerome Glisse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On 02/08/07, Jerome Glisse [EMAIL PROTECTED] wrote: Jesse Barnes wrote: I finally found some time to create a new wiki page for all the modesetting/configuration related DRM enhancements we've been talking about: http://dri.freedesktop.org/wiki/DrmModesetting Please take a look and let me know what you think. I still have to go through all the feedback I received from the lkml post I made awhile back, and make sure it's captured (I think it is, albeit at a fairly high level mostly), and add more detail in the design and development sections. Jakub, hopefully you can go over it and add more detail about the userland APIs? Dave and Keith, we talked about the new device node scheme awhile back, but I only have notes on what the master node should be responsible for, did we have any new ioctls for the slave nodes? Ring buffer mapping, etc. should probably be there? Thanks, Jesse This time i do not hijack the thread :) So we just discussed with Jakob and Jesse on this on irc and here is what i believe we agreed on: I don't agree with everything but the general idea is a good one. There should be master (possibly one for each card) which be the only one being able to do this call: DRM_IOCTL_MODE_SETCRTC - set CRTC parameters (which i assume is set the mode, associat crtc-output and set framebuffer) Other call can be made by any others client: - DRM_IOCTL_MODE_ADDFB - add a new FB object - DRM_IOCTL_MODE_RMFB - remove an FB object - DRM_IOCTL_MODE_GETFB - get info about an FB object ... I don't feel it is necessary for the clients to be able to create a framebuffer, why, because from the kernel standpoint where the said object will live, it will only be a small container containing the buffer object(s), a list of crtc that is using the buffer object(s) as a scanout buffer and the information about its size and format. Read below for more. In order to make this possible pinning a buffer will be done in SETCRTC in which a FB that can fit the mode must be given. Thus ADDFB will create a buffer but not pinned until used for scan out, so pinning happen in SETCRTC. Note that each client does not necessarily create its own framebuffer. The idea behind this is that we can have a daemon (one for each card or one for all of them) and this daemon can take framebuffer from client and easily change btw scan out buffer (switching from X to console will be made by the daemon and X might just not be aware of this). There is other use case one can come up with such scheme like developping EGL app under X and display its framebuffer by using it as a texture in a GL app. So there is master (big boss of crtcs) and client or slave humble provider of framebuffer. One point that might be also usefull is relation btw client should we do somethings like parent/child ? So this might looks like this (left are parent) master (big boss) - X server (got its framebuffer) - X application - sub GL window of this application (might want to have its framebuffer) - GL application (dri) client running X application (got its framebuffer which can used as a texture by the compositor, hello redirected direct rendering :)) - EGL program (got its framebuffer) - Console (got its framebuffer) - GL app offscreen rendering (no framebuffer for scanout) The idea behind this is that parent can use any object created by their child in anyway they like (this why we call them parent as parent always play with toy created by their child :o)). Maybe parent could also put restriction on what their child can do (which is another characteristics of parents). So why shouldn't the clients be able to creating framebuffer, because its only needed for in the kernel for setting the mode and for creating virtual dev nodes. That is its only used in the cases: User - /dev/dri/0fb1 - crtc/output User - /dev/dri/0fb2 - virtual It should not be used for passing around information to and from clients and sub clients. A framebuffer (the kernel side object) is not needed for offscreen rendering in theory only a BufferObject is needed for that and the userspace api can transmit the needed information between the different clients and sub client. IE: X the server is the client and a gl app rendering to a opengl framebuffer. This can be handled by a userspace API that is above/below the kernel sphere of interest. If people are happy with this i will update the wiki. Cheers, Jerome Glisse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net
Re: DRM enhancements document
Well ain't I'm rude not signing off :) Cheers Jakob Wlallbraker Bornecrekrantz. I just about can't do anything right to day :) Cheers Jakob. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
I don't agree with everything but the general idea is a good one. There should be master (possibly one for each card) which be the only one being able to do this call: DRM_IOCTL_MODE_SETCRTC - set CRTC parameters (which i assume is set the mode, associat crtc-output and set framebuffer) Other call can be made by any others client: - DRM_IOCTL_MODE_ADDFB - add a new FB object - DRM_IOCTL_MODE_RMFB - remove an FB object - DRM_IOCTL_MODE_GETFB - get info about an FB object ... I don't feel it is necessary for the clients to be able to create a framebuffer, why, because from the kernel standpoint where the said object will live, it will only be a small container containing the buffer object(s), a list of crtc that is using the buffer object(s) as a scanout buffer and the information about its size and format. Read below for more. In order to make this possible pinning a buffer will be done in SETCRTC in which a FB that can fit the mode must be given. Thus ADDFB will create a buffer but not pinned until used for scan out, so pinning happen in SETCRTC. Note that each client does not necessarily create its own framebuffer. The idea behind this is that we can have a daemon (one for each card or one for all of them) and this daemon can take framebuffer from client and easily change btw scan out buffer (switching from X to console will be made by the daemon and X might just not be aware of this). There is other use case one can come up with such scheme like developping EGL app under X and display its framebuffer by using it as a texture in a GL app. So there is master (big boss of crtcs) and client or slave humble provider of framebuffer. One point that might be also usefull is relation btw client should we do somethings like parent/child ? So this might looks like this (left are parent) master (big boss) - X server (got its framebuffer) - X application - sub GL window of this application (might want to have its framebuffer) - GL application (dri) client running X application (got its framebuffer which can used as a texture by the compositor, hello redirected direct rendering :)) - EGL program (got its framebuffer) - Console (got its framebuffer) - GL app offscreen rendering (no framebuffer for scanout) The idea behind this is that parent can use any object created by their child in anyway they like (this why we call them parent as parent always play with toy created by their child :o)). Maybe parent could also put restriction on what their child can do (which is another characteristics of parents). So why shouldn't the clients be able to creating framebuffer, because its only needed for in the kernel for setting the mode and for creating virtual dev nodes. That is its only used in the cases: User - /dev/dri/0fb1 - crtc/output User - /dev/dri/0fb2 - virtual It should not be used for passing around information to and from clients and sub clients. A framebuffer (the kernel side object) is not needed for offscreen rendering in theory only a BufferObject is needed for that and the userspace api can transmit the needed information between the different clients and sub client. IE: X the server is the client and a gl app rendering to a opengl framebuffer. This can be handled by a userspace API that is above/below the kernel sphere of interest. If people are happy with this i will update the wiki. Cheers, Jerome Glisse Well ain't I'm rude not signing off :) Cheers Jakob Wlallbraker Bornecrekrantz. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
Jakob Bornecrantz wrote: There should be master (possibly one for each card) which be the only one being able to do this call: DRM_IOCTL_MODE_SETCRTC - set CRTC parameters (which i assume is set the mode, associat crtc-output and set framebuffer) Other call can be made by any others client: - DRM_IOCTL_MODE_ADDFB - add a new FB object - DRM_IOCTL_MODE_RMFB - remove an FB object - DRM_IOCTL_MODE_GETFB - get info about an FB object ... I don't feel it is necessary for the clients to be able to create a framebuffer, why, because from the kernel standpoint where the said object will live, it will only be a small container containing the buffer object(s), a list of crtc that is using the buffer object(s) as a scanout buffer and the information about its size and format. Read below for more. The reasons why i wanted to expose frame buffer to client is because there is constraint to a frame buffer and this depend on the card, and if you want to take advantage of card you likely will want to follow this constraint when rendering. For instance if you got a card capable of supporting tiles you will want to render to a tiled buffer, i don't think this is easy to expose this to the client when creating a BO as BO are generic and can be used for vertex, or others data. In fact i do see a framebuffer as a special instance of BO which follow constraint of the card for rendering, we maybe can even force all rendering to happen into framebuffer (or others name if that's what matter). This way you know that you follow card constraints (tiles, stride size, alignement, component separation, ) If we force all rendering to happen into framebuffer then each client can either have its own or a part of another framebuffer (X client got a part of another if no compositing). So to resume having framebuffer might let us put specificity of memory layout, needed for efficient GPU rendering, into the kernel. We can let each driver accept additional parameter on ADDFB to tweak this (force tile off/on, RGB16, RGB32, ...). And also provide additional function for framebuffer addressing (like get pixel, get area, set pixel, set area) i believe fb driver expose such function and i believe this make writting console driver easier. Also, this way one can wrote a dumb app for any card which is graphical and don't have any dependency. It also make coding GL driver easier as you basicly use framebuffer (with associated Z/stencil buffer) from the kernel side and then you only matter on creating command stream not on how you should arrange things in memory. But maybe you still need anyway to put this knowledge into the driver (texture tiling, cube map specific memory organization, ...). Oh and as each client can carry its frame buffer(s) and it can believe being displayed while maybe somethings else is scanned out. Client are not aware of sharing the card the believe they own it and don't need to ask for a slice of a common frame buffer. That just might be given the chance of being scanout like they just might be never displayed (i am sure some one want to play quake without even seeing the screen ;)). I believe this make card virtualization total as the master will be in control and have the possibility to choose between each card available frame buffer, this can also help for instance when transitioning from fullscreen game to windowed without changing anythings. Hope some of arguments make sense :) and that i explained properly why i think putting all framebuffer layout specificity knowledge into kernel sounds better to me. Cheers, Jerome Glisse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM enhancements document
I finally found some time to create a new wiki page for all the modesetting/configuration related DRM enhancements we've been talking about: http://dri.freedesktop.org/wiki/DrmModesetting Please take a look and let me know what you think. I still have to go through all the feedback I received from the lkml post I made awhile back, and make sure it's captured (I think it is, albeit at a fairly high level mostly), and add more detail in the design and development sections. Jakub, hopefully you can go over it and add more detail about the userland APIs? Dave and Keith, we talked about the new device node scheme awhile back, but I only have notes on what the master node should be responsible for, did we have any new ioctls for the slave nodes? Ring buffer mapping, etc. should probably be there? Thanks, Jesse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
