On Nov 28, 08 11:04:48 -0800, Keith Packard wrote: > > + Note that changes to the screen size might invalidate panning > > + parameters. In these cases panning might be silently disabled, or the > > + panning parameters are updated automatically as necessary. The exact > > + behavior of the implementation is undefined. If the panning parameters > > + do not conflict with new screen size, panning remains enabled > > + unchanged. > > I don't see a need to leave this undefined; let's specify what screen > size changes do to panning and then implement it. Or vice-versa. And,
Ok. > > + If 'config-timestamp' does not match the current configuration > > + timestamp (as returned by RRGetScreenResources), 'status' is set to > > + InvalidConfigTime and the remaining reply data is empty. Otherwise, > > + 'status' is set to Success. > > just eliminate the config-timestamp stuff, it isn't useful now that we > have stable resource IDs etc. Note that the rest of the RandR protocol > doesn't look at config-timestamp anymore as it only causes trouble. Ok. > > + If 'timestamp' is less than the time when the configuration was last > > + successfully set, the request is ignored and InvalidTime returned in > > + status. > I'd say all of this timestamp stuff can be eliminated. I'm unsure - this just calls for races. > > + 'left', 'top', 'width', and 'height' contain the total panning area > > + for this CRTC. 'width' has to be larger than the CRTC's width, and > > + 'left'+'width' must be within the screen size, else a Match error > > + results. Equivalent restrictions for the height exist. The exception > > + is 'width' == 'height' == 0 which indicates that panning should be > > + disabled. > > I'd say that width >= crtc_width, the same for height. That way, you can It's actually implemented that way, the description is wrong. > You could make width == 0 mean to set width to the crtc_width (like > ClearArea does). Not setting, but using crtc_width. Setting would have different side effects (on mode changes to smaller modes, etc.) > > + 'track_left', 'track_top', 'track_width', and 'track_height' contain > > + the pointer area for which the panning region is updated. For normal > > + use cases it should enclose the panning area minus borders, and is > > + typically set to either the panning area minus borders, or to the > > + total screen size. If set to the total screen size, the CRTC will pan > > + in the remaining axis even if the pointer is outside the panning area > > + on a different CRTC. > > So, if the pointer is within this space, then the crtc is moved as far > as possible within the panning region to try and make the cursor > visible? Exactly. > > + 'border_left', 'border_top', 'border_right', and 'border_bottom' > > + define the distances from the CRTC borders that will activate panning > > + if the pointer hits them. If the borders are 0, the screen will pan > > + when the pointer hits the CRTC borders (behavior of pre-RandR Xserver > > + panning). If the borders are positive, the screen will pan when the > > + pointer gets close to the CRTC borders, if they are negative, the > > + screen will only pan when the pointer is already way past the CRTC > > + borders. Negative values might confuse users and are discouraged. > > + border_left + border_right has to be lower or equal than the CRTC's > > + width, else a Match error results. An equivalent restriction for the > > + height exists. > > Is there some reason to use borders instead of a separate rectangle > here? It turned out to be easier to understand, both in the spec and in code. Borders don't change if crtc dimensions change, while a separate box would. > Also, a couple of ascii-art pictures here would help a huge amount. I > had to read these several times to get any idea of what they all do, and > I'm still not sure I understand. I assume so. I guess they can be added later. Will do that, but will take some time. CU Matthias -- Matthias Hopf <[EMAIL PROTECTED]> __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
