[PATCH 02/13] randrproto: Panning protocol description
mhopf at suse.de
Thu Dec 4 03:31:57 PST 2008
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,
> > + 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.
> > + 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
> > + '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
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
> 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.
Matthias Hopf <mhopf at suse.de> __ __ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat at mshopf.de
Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de
More information about the xorg