Re: Sprite transforms in RandR
On Tue, Dec 07, 2010 at 07:47:28AM -0800, ext Keith Packard wrote: On Tue, 7 Dec 2010 15:44:36 +0200, Ville Syrjälä ville.syrj...@nokia.com wrote: Say, for example, that you have a portrait scanned LCD (which has it's own memory) and TV out, and let's say you want everything to be in landscape all the time. The LCD could do the required 90/270 degree rotation for free (since it has it's own memory), and for TV out you then want no rotation. In this case you probably don't want to use VRFB (the rotation thingy Daniel mentioned), since all memory access would happen in landscape direction, and VRFB's tile format would make that less efficient. Does the TV out support rotation in hardware at all? There are three places where you can do the rotation. 1. VRFB rotation in SDRAM controller. Physical memory in tiled layout, accessed through mmio windows to make it look linear. The hardware provides four windows for each VRFB context, one for each roation angle. 2. DMA rotation in the display controller. Using this for 90/270 degree rotation with SDRAM is a bad idea due to the sub optimal memory access pattern. It's really meant to be used only if you put the framebuffer into OMAP internal SRAM, but the SRAM is generally too small to be useful. 3. Display rotation, in case the display has it's own memory. 1 and 2 are always available. 3 depends on the display hardware. For example the N900 display doesn't support option 3, so VRFB is used. So if you can specify 90 degree rotation for one CRTC and 0 degree for another, the driver could allocate the pixmap in the most efficient format. If you have just one rotation parameter the driver would have no choice but to assume that rotation will be used even with the TV out, and thus would be forced to use VRFB all the time. Hrm. Right now, there is per-CRTC rotation support information, so you can tell whether a particular CRTC does rotation at all, of course that's all mixed in with the software rotation support in the server which I'm hoping to deprecate when compositing managers gain appropriate built-in rotation support. If we remove the software rotation support, and expose only 'native' rotation in the per-CRTC information, then the question about SCANOUTPIXMAPINFO is whether two CRTCs need a *different* format for the same rotation. In you case, I think you'd set the CRTC that could drive the TV as supporting only RR_Rotation_0 and the CRTC that could drive the LCD as supporting RR_Rotation_0|RR_Rotation_90|RR_Rotation_270. That would work although perhaps it's a bit limiting. I suppose you could have a device that supports two operation modes, where in one you'd want to rotate only the LCD, and in the other you'd want to rotate the TV out as well. So in this case the driver would always need to use VRFB even in the LCD only rotation mode. If CreateScanoutPixmap would take a list of CRTCs, and for each CRTC a list of rotations, then the driver could choose the optimal format for the pixmap. Not sure if that's worth the effort though. Or do we need separate per-*output* rotation information which is distinct from the CRTCs too? I don't think that's necessary, at least for OMAPs. -- Ville Syrjälä ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Sprite transforms in RandR
On Mon, Dec 06, 2010 at 08:44:41AM -0800, ext Keith Packard wrote: On Mon, 6 Dec 2010 15:20:01 +, Daniel Stone dan...@fooishbar.org wrote: Nope, we don't have any per-CRTC differences there, it's just that rotation is essentially another property of the mode that we need to know about in order to set up both the CRTC and the underlying surfaces, rather than an additional BlockHandler and a transform somewhere. If we don't have any existing hardware which requires per-CRTC scanout formats, I have to admit I'm tempted to leave the interface alone instead of making things more complicated for both applications and the server. I thinkl the OMAP case could probably make use of that. Say, for example, that you have a portrait scanned LCD (which has it's own memory) and TV out, and let's say you want everything to be in landscape all the time. The LCD could do the required 90/270 degree rotation for free (since it has it's own memory), and for TV out you then want no rotation. In this case you probably don't want to use VRFB (the rotation thingy Daniel mentioned), since all memory access would happen in landscape direction, and VRFB's tile format would make that less efficient. So if you can specify 90 degree rotation for one CRTC and 0 degree for another, the driver could allocate the pixmap in the most efficient format. If you have just one rotation parameter the driver would have no choice but to assume that rotation will be used even with the TV out, and thus would be forced to use VRFB all the time. -- Ville Syrjälä ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Sprite transforms in RandR
On Tue, 7 Dec 2010 15:44:36 +0200, Ville Syrjälä ville.syrj...@nokia.com wrote: Say, for example, that you have a portrait scanned LCD (which has it's own memory) and TV out, and let's say you want everything to be in landscape all the time. The LCD could do the required 90/270 degree rotation for free (since it has it's own memory), and for TV out you then want no rotation. In this case you probably don't want to use VRFB (the rotation thingy Daniel mentioned), since all memory access would happen in landscape direction, and VRFB's tile format would make that less efficient. Does the TV out support rotation in hardware at all? So if you can specify 90 degree rotation for one CRTC and 0 degree for another, the driver could allocate the pixmap in the most efficient format. If you have just one rotation parameter the driver would have no choice but to assume that rotation will be used even with the TV out, and thus would be forced to use VRFB all the time. Hrm. Right now, there is per-CRTC rotation support information, so you can tell whether a particular CRTC does rotation at all, of course that's all mixed in with the software rotation support in the server which I'm hoping to deprecate when compositing managers gain appropriate built-in rotation support. If we remove the software rotation support, and expose only 'native' rotation in the per-CRTC information, then the question about SCANOUTPIXMAPINFO is whether two CRTCs need a *different* format for the same rotation. In you case, I think you'd set the CRTC that could drive the TV as supporting only RR_Rotation_0 and the CRTC that could drive the LCD as supporting RR_Rotation_0|RR_Rotation_90|RR_Rotation_270. Or do we need separate per-*output* rotation information which is distinct from the CRTCs too? -- keith.pack...@intel.com pgpPBxDwamIPP.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Sprite transforms in RandR
Hi, On Sun, Dec 05, 2010 at 06:15:04PM -0800, Keith Packard wrote: On Sun, 5 Dec 2010 16:38:52 -0800, Aaron Plattner aplatt...@nvidia.com wrote: The actual text sounds reasonable to me, but it's not clear what the 'rotations' field of RRCreateScanoutPixmap is used for. Is it a set of hardware rotation modes that might be used for that crtc with that pixmap? Yes. Daniel Stone was working with some whacky omap hardware last year and if he wanted to have a scanout pixmap that *could* be rotated, he'd need to know in advance. Yep, the OMAP handles rotation by accessing through a special memory window set up by the SDRAM scheduler: you tell it the mode associated with it, and it translates the reads and writes for you. It also has its own pitch alignment requirements, etc, so we need to know in advance if it's going to be used. (Also, memory is fairly tight, so the aim was to be able to go from an 800x480 unrotated screen with a matching-sized pixmap, to a 90° rotation - 480x800. Previously, this required you to disable the CRTC, change the screen size, and then re-enable with the new configuration.) Also, is the set of supported rotations screen-wide, or associated with the particular format passed in? Is it possible for a driver to list multiple SCANOUTPIXMAPINFO with matching formats? E.g. I wonder if there's hardware that has, say, hardware rotation for one crtc but not another. It sounds like RandR expects the crtcs to have matching capabilities. Good point. I hadn't considered the case where different crtcs would have different rotation support. Definitely seems possible though. The current design doesn't tie the scanout pixmaps to a specific crtc, so I didn't think of having per-crtc scanout pixmap formats. I don't want to design beyond the hardware, so perhaps Daniel will know if this was the case in the hardware he was dealing with. Nope, we don't have any per-CRTC differences there, it's just that rotation is essentially another property of the mode that we need to know about in order to set up both the CRTC and the underlying surfaces, rather than an additional BlockHandler and a transform somewhere. This also required a patch to add a rotate hook to the RandR CRTC API which let the driver deal with rotation requests and skip the whole shadow + copy nightmare. I did have this on p.fd.o at one point, but it appears to have been lost; Tiago might know where it is. Cheers, Daniel signature.asc Description: Digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Sprite transforms in RandR
On Mon, 6 Dec 2010 15:20:01 +, Daniel Stone dan...@fooishbar.org wrote: Nope, we don't have any per-CRTC differences there, it's just that rotation is essentially another property of the mode that we need to know about in order to set up both the CRTC and the underlying surfaces, rather than an additional BlockHandler and a transform somewhere. If we don't have any existing hardware which requires per-CRTC scanout formats, I have to admit I'm tempted to leave the interface alone instead of making things more complicated for both applications and the server. This also required a patch to add a rotate hook to the RandR CRTC API which let the driver deal with rotation requests and skip the whole shadow + copy nightmare. I did have this on p.fd.o at one point, but it appears to have been lost; Tiago might know where it is. I'm hoping the new 'set' entry point will do what you want; it gets called before xf86CrtcRotate in every case now (unlike set_mode_major which doesn't get used when the server changes only the origin). Thanks. -- keith.pack...@intel.com pgprXDYROLfYo.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Sprite transforms in RandR
On Sun, Dec 05, 2010 at 08:47:15PM -0800, Keith Packard wrote: On Sun, 5 Dec 2010 16:38:52 -0800, Aaron Plattner aplatt...@nvidia.com wrote: The crtc shadow functions seem obsolete given the new scanout pixmap creation function, but they can be removed in a later ABI. So, I was thinking about what happens when your compositing manager creates a PCP and then promptly crashes. With the current spec (and implementation), you're left staring at a static image of whatever the compositing manager stuck into the scanout pixmap. Not very useful. Would it make sense to have the system revert to some sensible state when the scanout pixmap was destroyed by the client (either explicitly or through disconnecting from the server)? If so, what state should it revert to? I can envision a fairly simple option: 1) Resize the screen to be no smaller than the current crtc mode. 2) Configure the crtc to scanout from the screen pixmap at 0,0 I don't think it will be all that difficult to make this happen, does it seem like a better plan than leaving garbage on the screen? Yes, definitely. #2 seems easier. If you also turn on panning so the whole screen area is accessible, then it seems better than #1 too because the compositor is probably going to often be the window manager as well, so #1 may still leave you with windows that you can't get to. As annoying as some people find panning, I suspect not being able to recover from a crashed compositor because they can't get to the start button or whatever will be more annoying. Continuing to scan out the pixmap will just make users think their systems froze. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Sprite transforms in RandR
On Sun, Dec 05, 2010 at 06:17:12PM -0800, Keith Packard wrote: On Sun, 5 Dec 2010 16:42:43 -0800, Aaron Plattner aplatt...@nvidia.com wrote: Unless it's very generic or just a string to present to the user, I don't think trying to encode this in the protocol is going to be reasonable. We have a bazillion ways that modesets can fail, most of which are due to wacky internal limitations that are hard to describe. Ok, that was my assumption. We could ship a string back, if you like -- I've got an X reply heading that direction. Of course, getting that localized for the user to actually understand it will be nearly impossible, so it's tempting to just say 'go look at your Xorg.0.log file for details' or some such. Yes, I think a generic sorry, it didn't work boolean reply is the way to go. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Sprite transforms in RandR
On Mon, Dec 06, 2010 at 08:44:41AM -0800, Keith Packard wrote: On Mon, 6 Dec 2010 15:20:01 +, Daniel Stone dan...@fooishbar.org wrote: Nope, we don't have any per-CRTC differences there, it's just that rotation is essentially another property of the mode that we need to know about in order to set up both the CRTC and the underlying surfaces, rather than an additional BlockHandler and a transform somewhere. If we don't have any existing hardware which requires per-CRTC scanout formats, I have to admit I'm tempted to leave the interface alone instead of making things more complicated for both applications and the server. Are there really no dumb little phones or something that can rotate the internal screen but not external displays? I'd feel more comfortable if someone familiar with the various embedded graphics chips would chime in with an ack/nack. I guess outputs have a mask of allowable rotations provided to the clients. Maybe that's sufficient: you can only use hardware rotation if the scanoutpixmapinfo *and* the corresponding output rotation mask say you can, and otherwise you get to do the rotation yourself with the graphics hardware? One thing that reminded me of is how the requested rotation is going to be communicated to the compositor. Should we add something like a RRConfigRedirectMask, or will the clients be expected to invent their own new protocol for sending configuration requests to the compositor? ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Sprite transforms in RandR
On Mon, 6 Dec 2010 09:42:24 -0800, Aaron Plattner aplatt...@nvidia.com wrote: On Mon, Dec 06, 2010 at 08:44:41AM -0800, Keith Packard wrote: On Mon, 6 Dec 2010 15:20:01 +, Daniel Stone dan...@fooishbar.org wrote: Nope, we don't have any per-CRTC differences there, it's just that rotation is essentially another property of the mode that we need to know about in order to set up both the CRTC and the underlying surfaces, rather than an additional BlockHandler and a transform somewhere. If we don't have any existing hardware which requires per-CRTC scanout formats, I have to admit I'm tempted to leave the interface alone instead of making things more complicated for both applications and the server. Are there really no dumb little phones or something that can rotate the internal screen but not external displays? I'd feel more comfortable if someone familiar with the various embedded graphics chips would chime in with an ack/nack. That's why I asked Daniel -- he was dealing with a phone that had hardware rotation support (some OMAP thing), and he says that the hardware will rotate on any CRTC (it's got TV out). I guess outputs have a mask of allowable rotations provided to the clients. Maybe that's sufficient: you can only use hardware rotation if the scanoutpixmapinfo *and* the corresponding output rotation mask say you can, and otherwise you get to do the rotation yourself with the graphics hardware? Right. The question is only whether separate outputs need *different* scanout pixmap formats. One thing that reminded me of is how the requested rotation is going to be communicated to the compositor. Should we add something like a RRConfigRedirectMask, or will the clients be expected to invent their own new protocol for sending configuration requests to the compositor? I wonder how it works today; I've got a phone that appears to allow applications to rotate the screen, do they actually have applications doing the RandR calls? Sounds like we might want to consider adding a configuration redirection mechanism at some point... -- keith.pack...@intel.com pgpcWIHyXS3Fv.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Sprite transforms in RandR
Yes, definitely. #2 seems easier. If you also turn on panning so the whole screen area is accessible, then it seems better than #1 too because the compositor is probably going to often be the window manager as well, so #1 may still leave you with windows that you can't get to. As annoying as some people find panning, I suspect not being able to recover from a crashed compositor because they can't get to the start button or whatever will be more annoying. Oh, panning is a good addition. Continuing to scan out the pixmap will just make users think their systems froze. Even if they knew what happened, having a frozen screen doesn't make it any easier to recover from. -- keith.pack...@intel.com pgpFr9ctxJmXR.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Sprite transforms in RandR
On Sat, Dec 04, 2010 at 03:06:35PM -0800, Keith Packard wrote: To make per-crtc pixmaps actually useful for things like extended or rotated desktops, I've added a couple of matrices to each crtc to transform the sprite position and image. I suspect these will need documentation beyond the following: +┌─── +RRSetCrtcSpriteTransform + crtc: CRTC + position-transform: TRANSFORM + image-transform: TRANSFORM +└─── + Sets the sprite transforms for the specified crtc, any sprites + presented on this crtc will have their positions transformed + by the position-transform matrix. Sprite images displayed on the crtc + will be transformed by the image-transform matrix. + +┌─── +RRGetCrtcSpriteTransform + crtc: CRTC + ▶ + position-transform: TRANSFORM + image-transform: TRANSFORM +└─── + Gets the sprite transforms for the specified crtc. + In any case, the position piece of this is complete, and the image piece is done save the actual image transforms -- the matrix gets all the way From the client to the cursor code. Protocol changes: git://people.freedesktop.org/~keithp/randrproto master There are a few whitespace bugs, such as this: ┌─── RRQueryScanoutPixmaps \twindow: WINDOW ▶ infos: LISTofSCANOUTPIXMAPINFO └─── \tErrors: Window The actual text sounds reasonable to me, but it's not clear what the 'rotations' field of RRCreateScanoutPixmap is used for. Is it a set of hardware rotation modes that might be used for that crtc with that pixmap? Also, is the set of supported rotations screen-wide, or associated with the particular format passed in? Is it possible for a driver to list multiple SCANOUTPIXMAPINFO with matching formats? E.g. I wonder if there's hardware that has, say, hardware rotation for one crtc but not another. It sounds like RandR expects the crtcs to have matching capabilities. The whitespace for RRCrtcSetSpriteTransform has spaces followed by tabs. Can you clarify the distinction between the screen size and the screen pixmap size? Do you think it's worth making the sizes larger than CARD16 for future expansion? We're going to need to rev a lot of stuff if we want to move to larger sizes, but maybe it's better to start doing it piecemeal when we're already changing extensions. Can you clarify the distinction between crtc (x, y) and (pixmap_x, pixmap_y)? I guess the (x, y) position is used to produce the input sprite position for that crtc? It would be nice to have that be spelled out a little more in randrproto.txt. Library changes: git://people.freedesktop.org/~keithp/libXrandr master There are some unrelated whitespace changes, and a tab-space-tab pattern in the argument list for XRRSetCrtcConfigs. xrandr changes: git://people.freedesktop.org/~keithp/xrandr master I just skimmed this. It seemed okay. Acked-by: Aaron Plattner aplatt...@nvidia.com xserver changes: git://people.freedesktop.org/~keithp/xserver randr-1.4-subwork There's a scaout_pixmap in randrstr.h. The crtc shadow functions seem obsolete given the new scanout pixmap creation function, but they can be removed in a later ABI. Is the client-swapped code in the protocol handling ever used? It looks like the SProc versions are plugged into the dispatch vector and they just return BadImplementation. This also includes all of the protocol and library bits for the rest of the proposed RandR changes, but the server implementation hasn't been merged to this branch yet. On to the per-crtc pixmap and setcrtcconfigs pieces. Hoping to have this merged over today. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Sprite transforms in RandR
On Sat, Dec 04, 2010 at 08:34:40PM -0800, Keith Packard wrote: Would it be useful to be able to return more information from the server to the application? How would such information get encoded? Unless it's very generic or just a string to present to the user, I don't think trying to encode this in the protocol is going to be reasonable. We have a bazillion ways that modesets can fail, most of which are due to wacky internal limitations that are hard to describe. -- Aaron ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Sprite transforms in RandR
On Sun, 5 Dec 2010 16:38:52 -0800, Aaron Plattner aplatt...@nvidia.com wrote: Thanks for reviewing over the weekend. There are a few whitespace bugs, such as this: ┌─── RRQueryScanoutPixmaps \twindow: WINDOW ▶ infos: LISTofSCANOUTPIXMAPINFO └─── \tErrors: Window I'll clean up the whitespace. The actual text sounds reasonable to me, but it's not clear what the 'rotations' field of RRCreateScanoutPixmap is used for. Is it a set of hardware rotation modes that might be used for that crtc with that pixmap? Yes. Daniel Stone was working with some whacky omap hardware last year and if he wanted to have a scanout pixmap that *could* be rotated, he'd need to know in advance. Also, is the set of supported rotations screen-wide, or associated with the particular format passed in? Is it possible for a driver to list multiple SCANOUTPIXMAPINFO with matching formats? E.g. I wonder if there's hardware that has, say, hardware rotation for one crtc but not another. It sounds like RandR expects the crtcs to have matching capabilities. Good point. I hadn't considered the case where different crtcs would have different rotation support. Definitely seems possible though. The current design doesn't tie the scanout pixmaps to a specific crtc, so I didn't think of having per-crtc scanout pixmap formats. I don't want to design beyond the hardware, so perhaps Daniel will know if this was the case in the hardware he was dealing with. If so, I'd suggest that the whole scanout pixmap formats stuff should be per-crtc. And, if you want to use one scanout pixmap with multiple crtcs, you'd better make sure they both support the desired format. Seem reasonable? The whitespace for RRCrtcSetSpriteTransform has spaces followed by tabs. Yay, whitespace bugs. Can you clarify the distinction between the screen size and the screen pixmap size? The screen size is the size seen by applications. It is the size of the root window, and also the size which input coordinates will be clipped to. It forms the effective surface on which the desktop can be constructed. The screen pixmap size is the size of the backing store for any painting happening on the screen. In a non-composited environment, all output to all windows will be clipped to the screen pixmap. These used to be tied together; it didn't make sense to have a screen pixmap smaller than the root window; there wouldn't be any way to have content visible beyond the screen pixmap. With PCP and sprite transforms, you can now construct logical screen regions that are visible (via PCP) and can be manipulated (via ST) as a part of the screen environment. A simple example of this is the CRTC rotation case. With PCP and ST, the compositing manager will allocate a CRTC pixmap to match the desired mode. Window contents will be copied to the crtc pixmap through a rotation transform, resulting in a rotated presentation of the desktop. The screen pixmap, in this case, contains no useful content at all. So, we set the screen pixmap size to some tiny little value, and set the screen size to match the logical rotated dimensions. A larger example is if you want to provide an extended desktop across multiple monitors but your hardware can't scan out from a pixmap of that size. Create per-crtc pixmaps for each crtc, set the screen pixmap to 'tiny', and set the screen size to match the full dimension of the desktop. Do you think it's worth making the sizes larger than CARD16 for future expansion? We're going to need to rev a lot of stuff if we want to move to larger sizes, but maybe it's better to start doing it piecemeal when we're already changing extensions. I think that discussion needs to happen, but not in the context of minor updates to existing extensions. Can you clarify the distinction between crtc (x, y) and (pixmap_x, pixmap_y)? I guess the (x, y) position is used to produce the input sprite position for that crtc? It would be nice to have that be spelled out a little more in randrproto.txt. Sure. crtc x,y set the position of the crtc in screen space; the default input transformation uses these values to translate global sprite coordinates to crtc-specific coordinates. And, without a scanout pixmap, these coordinates also determine where in the screen pixmap the crtc scans out from. crtc xPixmap,yPixmap set the scanout location of the crtc within the specific scanout pixmap. These are only used if the crtc has a scanout pixmap separate from the screen pixmap. There are some unrelated whitespace changes, and a tab-space-tab pattern in the argument list for XRRSetCrtcConfigs. Perhaps emacs can fix my whitespace problems. xrandr changes: git://people.freedesktop.org/~keithp/xrandr master I just skimmed this. It seemed okay. Acked-by: Aaron Plattner aplatt...@nvidia.com Yeah, the PCP stuff here is just a hack to show that it works, it's not actually useful. xserver changes:
Re: Sprite transforms in RandR
On Sun, 5 Dec 2010 16:42:43 -0800, Aaron Plattner aplatt...@nvidia.com wrote: Unless it's very generic or just a string to present to the user, I don't think trying to encode this in the protocol is going to be reasonable. We have a bazillion ways that modesets can fail, most of which are due to wacky internal limitations that are hard to describe. Ok, that was my assumption. We could ship a string back, if you like -- I've got an X reply heading that direction. Of course, getting that localized for the user to actually understand it will be nearly impossible, so it's tempting to just say 'go look at your Xorg.0.log file for details' or some such. -- keith.pack...@intel.com pgpH4SsDxFmNN.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Sprite transforms in RandR
On Sun, Dec 05, 2010 at 06:15:04PM -0800, Keith Packard wrote: On Sun, 5 Dec 2010 16:38:52 -0800, Aaron Plattner aplatt...@nvidia.com wrote: Thanks for reviewing over the weekend. There are a few whitespace bugs, such as this: ┌─── RRQueryScanoutPixmaps \twindow: WINDOW ▶ infos: LISTofSCANOUTPIXMAPINFO └─── \tErrors: Window I'll clean up the whitespace. The actual text sounds reasonable to me, but it's not clear what the 'rotations' field of RRCreateScanoutPixmap is used for. Is it a set of hardware rotation modes that might be used for that crtc with that pixmap? Yes. Daniel Stone was working with some whacky omap hardware last year and if he wanted to have a scanout pixmap that *could* be rotated, he'd need to know in advance. Okay, I figured it was something like that. The actual hardware rotation is configured when setting the crtc config then, right? Also, is the set of supported rotations screen-wide, or associated with the particular format passed in? Is it possible for a driver to list multiple SCANOUTPIXMAPINFO with matching formats? E.g. I wonder if there's hardware that has, say, hardware rotation for one crtc but not another. It sounds like RandR expects the crtcs to have matching capabilities. Good point. I hadn't considered the case where different crtcs would have different rotation support. Definitely seems possible though. The current design doesn't tie the scanout pixmaps to a specific crtc, so I didn't think of having per-crtc scanout pixmap formats. I don't want to design beyond the hardware, so perhaps Daniel will know if this was the case in the hardware he was dealing with. If so, I'd suggest that the whole scanout pixmap formats stuff should be per-crtc. And, if you want to use one scanout pixmap with multiple crtcs, you'd better make sure they both support the desired format. Seem reasonable? Yes, that sounds reasonable. We don't actually have any hardware like that; after a lot of previous chips were huge pains in the butt, we've had homogeneous crtc capabilities for the last several chip generations, including Tegra. Still, that seems like the sort of limitation that hardware designers love to add so we should definitely make the protocol capable of expressing it. I'm less concerned about the ability to have multiple formats for different limitations, but it seems like somebody might want to make a scanout engine that can display rotated but only up to a certain size, and then display unrotated up to a larger size. I guess you can distinguish between those based on the scanout pixmap size, format, and possible rotations? The whitespace for RRCrtcSetSpriteTransform has spaces followed by tabs. Yay, whitespace bugs. Can you clarify the distinction between the screen size and the screen pixmap size? The screen size is the size seen by applications. It is the size of the root window, and also the size which input coordinates will be clipped to. It forms the effective surface on which the desktop can be constructed. The screen pixmap size is the size of the backing store for any painting happening on the screen. In a non-composited environment, all output to all windows will be clipped to the screen pixmap. These used to be tied together; it didn't make sense to have a screen pixmap smaller than the root window; there wouldn't be any way to have content visible beyond the screen pixmap. With PCP and sprite transforms, you can now construct logical screen regions that are visible (via PCP) and can be manipulated (via ST) as a part of the screen environment. A simple example of this is the CRTC rotation case. With PCP and ST, the compositing manager will allocate a CRTC pixmap to match the desired mode. Window contents will be copied to the crtc pixmap through a rotation transform, resulting in a rotated presentation of the desktop. The screen pixmap, in this case, contains no useful content at all. So, we set the screen pixmap size to some tiny little value, and set the screen size to match the logical rotated dimensions. A larger example is if you want to provide an extended desktop across multiple monitors but your hardware can't scan out from a pixmap of that size. Create per-crtc pixmaps for each crtc, set the screen pixmap to 'tiny', and set the screen size to match the full dimension of the desktop. Thanks, that makes sense. Could a condensed version of this please go into randrproto.txt? Do you think it's worth making the sizes larger than CARD16 for future expansion? We're going to need to rev a lot of stuff if we want to move to larger sizes, but maybe it's better to start doing it piecemeal when we're already changing extensions. I think that discussion needs to happen, but not in the context of minor updates to existing extensions. Fair enough. Can you clarify the distinction between crtc (x, y)
Re: Sprite transforms in RandR
On Sun, 5 Dec 2010 22:47:21 -0800, Aaron Plattner aplatt...@nvidia.com wrote: Okay, I figured it was something like that. The actual hardware rotation is configured when setting the crtc config then, right? Right. The goal is to just expose what the hardware does and not fake stuff in software in the server anymore I'm less concerned about the ability to have multiple formats for different limitations, but it seems like somebody might want to make a scanout engine that can display rotated but only up to a certain size, and then display unrotated up to a larger size. I guess you can distinguish between those based on the scanout pixmap size, format, and possible rotations? And here I spent some time clarifying that you only were supposed to have one SCANOUTPIXMAPINFO per format. Ok, so we get one list of SCANOUTPIXMAPINFO per crtc, and we allow multiple identical formats with other limitations. Works for me. Thanks, that makes sense. Could a condensed version of this please go into randrproto.txt? Yeah, I'll put some informative text in the spec at the top. Sorry this didn't get in tonight, I was on the road most of the day. It's getting late here so I'll need to look at these first thing tomorrow. Delayed review is better than tired review, hopefully. We live on west coast time, so there are still 25 hours to go before our self-imposed deadline for the merge window close. Thanks for your review; I'll get the Sync extension changes reviewed tomorrow. -- keith.pack...@intel.com pgpXVn5jSbeJS.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Sprite transforms in RandR
I can't remember whether it was Aaron or Andy, but a couple of years ago
they talked about not being able to move the nVidia driver to RandR 1.2
because it didn't want to get the mode setting instructions in pieces.
Memory allocation and various hardware limits meant that there were many
configurations which could be satisfied, but only if the whole
configuration could be reviewed by the driver.
As a part of the RandR 1.4 work, I've added a new request,
RRSetCrtcConfigs which sends all of the changes at one time:
Here's what you send for each CRTC to be configured:
+CRTCCONFIG { crtc: CRTC
+x, y: INT16
+mode: MODE
+rotation: ROTATION
+sprite_position_transform: TRANSFORM
+sprite_image_transform: TRANSFORM
+outputs: LISTofOUTPUT
+pixmap: PIXMAP
+pixmap_x, pixmap_y: INT16 }
And here's the new request.
+┌───
+RRSetCrtcConfigs
+ drawable: DRAWABLE
+ screen-pixmap-width: CARD16
+ screen-pixmap-height: CARD16
+ screen-width: CARD16
+ screen-height: CARD16
+ width-in-millimeters: CARD32
+ height-in-millimeters: CARD32
+ configs: LISTofCRTCCONFIG
+ ▶
+ status: RRCONFIGSTATUS
+└───
+ Errors: Value, Match
+
+ This works much like RRSetScreenSize followed by a sequence of
+ RRSetCrtcConfig, except that the entire configuration is set
+ in a single operation, either succeeding or failing without
+ any partial execution. In particular, the requested screen pixmap
+ size need only be large enough to hold the final
+ configuration, not the starting or any intermediate
+ configuration. Note that the sprite transforms are also included
+ in this request making for truely one-stop shopping.
This has some extra stuff for per-crtc pixmaps which isn't merged into
the server yet, otherwise it's just a complete list of all of the stuff
that you need to send to configure a screen.
One interesting change here is that it includes separate screen and
screen-pixmap size information. That allows you to create a larger
virtual space than is supported by the hardware, again for per-crtc
pixmap stuff. This also isn't implemented yet, although it won't be all
that difficult, just need to trim the root clip lists to the screen
pixmap as well as the root window size.
For drivers, very little has changed. Drivers are given the opportunity
to add a hook that will be called during operation of the new
request. This lives in the xf86CrtcConfigFuncsRec which is passed from
the driver when it calls xf86CrtcConfigInit:
xf86SetConfigResponse
(*set_config) (ScrnInfoPtr scrn,
RRScreenConfigPtrscreen_config,
xf86CrtcSetConfigPtr crtc_configs,
int num_configs);
This function can do one of four things:
1) Not exist at all. If set_config is NULL, the server
will just invoke the existing mode setting hooks in
sequence, recovering if any of them return an error
and restoring the previous configuration.
2) Return xf86SetConfigFailed. In this case, the server
abandons attempts to do the mode setting and returns
a failure indication back to the client.
3) Return xf86SetConfigDone. If the driver can handle
the whole mode setting operation internally, it may
return this value, at which point the server just tells
the client the happy news without doing anything to the
hardware itself.
4) Return xf86SetConfigChecked. This says that the driver has
validated the arguments, and things look fine, but it
hasn't done any mode setting. In this case, the server
will use the existing mode setting hooks and try to
configure the device, as in case 0) above.
Would it be useful to be able to return more information from the server
to the application? How would such information get encoded?
I've changed 'xrandr' to always use this new function if available.
As with the sprite transform changes, everything here is available from:
Protocol changes:
git://people.freedesktop.org/~keithp/randrproto master
Library changes:
git://people.freedesktop.org/~keithp/libXrandr master
xrandr changes:
git://people.freedesktop.org/~keithp/xrandr master
xserver changes:
git://people.freedesktop.org/~keithp/xserver randr-1.4-subwork
--
keith.pack...@intel.com
pgpN7VOqmk3LA.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
