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