Re: DRI2 Protocol Spec Draft
On Wed, 2008-09-10 at 11:54 -0400, Kristian Høgsberg wrote: The buffer types available? This is for when you want to check if, say, a DRI2_BUFFER_YUV is available, and if not fall back to something else? I was thinking of the direct rendering libraries which it knows about, but yeah, the available set of buffers as well. Yeah. Though, I imagine the GEM interaction text will be implementation notes/suggestion type of stuff, we want the DRI2 spec to be DRM and GEM independent. I'll try to spell out the requirements DRI2 has on the underlying system (essentially, the ability to name buffers by a 32 bit integer and share them and the auth mechanism). Having notes about how this works with GEM would be useful, although it should be a separate appendix. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: DRI2 Protocol Spec Draft
On Wed, 2008-09-10 at 17:28 -0400, Kristian Høgsberg wrote: No that's why the existing scheme is better, it doesn't rely on random/cryptographical tokens. It just needs to be a unique handle that lets the server identify the right client to authenticate. If you can pass this token to the X server you're authenticated. What better way to establish that than, erh, passing it through protocol? The key point is that the server does the ioctl that authenticates the client. Ok, so the kernel generates a unique token that identifies the client which the client takes and hands to the X server to pass back into the kernel to authorize the client. Just trying to figure out how this stuff is supposed to work. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: DRI2 Protocol Spec Draft
On Tue, 2008-09-09 at 13:27 +0200, Michel Dänzer wrote: I think it'd be good if the authentication stuff could be made/kept optional or at least not DRM specific. (I'm not sure GEM or the DRM in general is within scope of this spec at all) I have to admit that I'm not very excited by the existing authentication protocol. What we want is a way to let applications identify themselves with the kernel and 'prove' that they have permission to access kernel objects. It seems like having the X server return a 'cookie' that the client could use with the kernel module might make things simpler: ┌─── DRI2Connect window: WINDOW type: STRING ▶ driver: STRING device: STRING -- device file name auth-data: LISTofCARD8 └─── 'auth-data' is an arbitrary array of bytes which the client passes to the direct rendering system to validate the client's access of direct rendering objects created by the X server. It seems like this offers precisely the right guarantee -- the client proves to the kernel that it is connected to the X server and thus should be granted permission to access the X server objects. Under some tighter access control mechanisms, the 'auth-data' could even be generated per-client so that the client would only have access to a sub-set of X server objects. I do wonder if DRI2GetBuffers should return the drawable position relative to the origin of each buffer... guess it isn't strictly necessary except maybe for the real frontbuffer. One of the requirements in DRI2 is that the 'real' front buffer be invisible to applications; there's no way the application can sensibly use those contents. Moreover, the drawable position may change without any warning due to window configuration. For DRI2CopyRegion, you're leaving it to the DDX driver to pick the CRTC to synchronize to? I'm not sure that'll work too well with overlapping viewports, where the user may want to choose which CRTC to synchronize to for each application. Yeah, I don't see a good way to avoid this, and the client can always pass in 'Automatic' (0) and let the server pick the 'right' one. This request also still seems to be missing return values for the sequence number when the copy is expected to take place and tokens for synchronization of direct rendering to the source/destination buffer. Eliminating the reply avoids a round trip, so I'm in favor of not providing any if it's not strictly necessary. I don't know if the GL api requires us to provide the expected sequence number back to the application. For synchronization, we should expect the kernel module to perform this automatically -- once the X server has processed this request, the kernel can pend further rendering to the source buffer until the copy has finished. That would, of course, require that the application know that the kernel has received the copy command from the X server -- so the client would need to get something from X server indicating that it had finished processing the Copy request. The easiest thing to use would be a reply, but we'd structure the library so that the client wouldn't pend on the reply and could block just before touching the back buffer again. Note that there isn't any synchronization on the real front buffer; that isn't a legal target for direct rendering. Oh, and I think it should take relative sequence numbers as well as absolute ones. Yeah, GL does kinda require this. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: DRI2 Protocol Spec Draft
On Tue, 2008-09-09 at 08:46 -0700, Keith Packard wrote: On Tue, 2008-09-09 at 13:27 +0200, Michel Dänzer wrote: I think it'd be good if the authentication stuff could be made/kept optional or at least not DRM specific. (I'm not sure GEM or the DRM in general is within scope of this spec at all) I have to admit that I'm not very excited by the existing authentication protocol. What we want is a way to let applications identify themselves with the kernel and 'prove' that they have permission to access kernel objects. It seems like having the X server return a 'cookie' that the client could use with the kernel module might make things simpler: Sounds like the DRI1 authentication mechanism. :) I do wonder if DRI2GetBuffers should return the drawable position relative to the origin of each buffer... guess it isn't strictly necessary except maybe for the real frontbuffer. One of the requirements in DRI2 is that the 'real' front buffer be invisible to applications; there's no way the application can sensibly use those contents. Moreover, the drawable position may change without any warning due to window configuration. GLX_EXT_texture_from_pixmap needs the real front buffer. Consider me convinced that it doesn't need to return any position information though. This request also still seems to be missing return values for the sequence number when the copy is expected to take place and tokens for synchronization of direct rendering to the source/destination buffer. Eliminating the reply avoids a round trip, so I'm in favor of not providing any if it's not strictly necessary. I don't know if the GL api requires us to provide the expected sequence number back to the application. Some GLX synchronization extensions provide information about whether a buffer swap hit or missed the target. For synchronization, we should expect the kernel module to perform this automatically -- once the X server has processed this request, the kernel can pend further rendering to the source buffer until the copy has finished. That would, of course, require that the application know that the kernel has received the copy command from the X server -- so the client would need to get something from X server indicating that it had finished processing the Copy request. The easiest thing to use would be a reply, but we'd structure the library so that the client wouldn't pend on the reply and could block just before touching the back buffer again. Yeah, something like that could work. Oh, and I think it should take relative sequence numbers as well as absolute ones. Yeah, GL does kinda require this. Rather driconf vblank_mode=3. Hmm, though that would also require DRI2CopyRegion not to execute the copy if the target was missed... Generally, if DRI2CopyRegion seriously wants to be useful for synchronization purposes, it probably needs to provide at least the same functionality as the DRM vblank related ioctls. Of course, for redirected windows it should really synchronize to the compositing manager rather than to the display hardware directly, but I'm not sure that matters at this point. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: DRI2 Protocol Spec Draft
On Tue, 2008-09-09 at 10:11 -0700, Keith Packard wrote: On Tue, 2008-09-09 at 18:41 +0200, Michel Dänzer wrote: GLX_EXT_texture_from_pixmap needs the real front buffer. Sure, but that's not through DRI2, this just references the object as an X pixmap. I don't understand what you mean. How would a direct rendering, zero-copy implementation of GLX_EXT_texture_from_pixmap work without getting the pixmap buffer ID via DRI2GetBuffers? Some GLX synchronization extensions provide information about whether a buffer swap hit or missed the target. We could have the request return an error if the sequence target could not be met. So in order to find out the effective sequence number, the client would need to keep incrementing the target number and check for the error? Doesn't sound very appealing to me. Not to mention X protocol errors tend to be a PITA. Generally, if DRI2CopyRegion seriously wants to be useful for synchronization purposes, it probably needs to provide at least the same functionality as the DRM vblank related ioctls. Certainly the combination of DRI2CopyRegion and DRM should be able to provide sufficient synchronization. The question is what portion of this task belongs in the extension and what portion belongs in the DRM kernel API. If the GLX implementation is to use DRI2CopyRegion for synchronization purposes, then the interface of the latter needs to be at least as expressive as the DRM synchronization interfaces currently used by the former. Of course, for redirected windows it should really synchronize to the compositing manager rather than to the display hardware directly, but I'm not sure that matters at this point. For redirected windows, the CopyRegion will not block, and the compositing manager will get a Damage event when it occurs. At that point, it's up to the compositing manager to 'do the right thing' to get contents sync'd to the screen (presumably by using CopyRegion itself). Eventually there will need to be some kind of synchronization mechanism between direct rendering clients and the compositing manager, or smooth animation at the display framerate isn't possible with redirected windows. That mechanism could be basically the same as the existing sync-to-vblank mechanisms, but with 'vertical blank' replaced by 'compositing manager screen update'. So it would provide the client with a way to express the display frame at which the buffer swap should take effect and to synchronize to the compositing manager making it so. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: DRI2 Protocol Spec Draft
On Mon, 2008-09-08 at 17:58 -0400, Kristian Høgsberg wrote: Hi, Keith talked me intro writing a spec for DRI2, which I grudgingly must admit is a good idea. I used the randr spec as a template, except I replaced the flowery section dividers with a more fitting gears motif. It's still a work in progress, mostly the introductory/background sections though. The requests and wire encoding sections are mostly complete and is close to what's in the git repos at this point. The implementation isn't fully uptodate with the spec yet, but I figured it would be wise to circulate the spec before doing more code churn, so here it is. You probably don't need the sub-pixel ordering stuff :-) Do you want a request to list the available DRI2 types? I don't think we want the window position in the GetBuffers request, that makes the buffers 'obviously' independent of position. Oh, and some checking to make sure the remaining 'randr' wording is cleaned up. It would also be nice to see some additional description about how this works with GEM. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
