[PATCH 02/13] randrproto: Panning protocol description

[Matthias Hopf]

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 <mhopf at suse.de>      __        __   __
Maxfeldstr. 5 / 90409 Nuernberg   (_   | |  (_   |__          mat at mshopf.de
Phone +49-911-74053-715           __)  |_|  __)  |__  R & D   www.mshopf.de