[PATCH 02/13] randrproto: Panning protocol description

[Matthias Hopf]

On Dec 04, 08 09:29:24 -0800, Keith Packard wrote:
> On Thu, 2008-12-04 at 12:31 +0100, Matthias Hopf wrote:
> What happens with timestamps is that an application queries the system,
> then something unrelated changes, then the application tries to set some
> parameters. The result is that the settings fail and if the application
> has no recovery mechanism (which is likely), the user is left confused.

IMHO that points to broken applications. With xrandr that's acceptable,
because xrandr is rather a showcase (and a power-user's tool) than a
really user friendly display change application.

> It's been a serious problem in the past, and the timestamps don't
> eliminate inter-application races, they just narrow the window.

I'm not exactly sure why they don't eliminate them.

> The random failures caused by timestamps have been far worse than any
> race conditions we've found. If any thing "important" changes, the
> request will fail anyway, due to match errors or resources disappearing.

The issue is that all requests still do timestamping, and when adding
new functionality it should be consistent. If it's general consensus
that timestamp checks should be removed, it should be done consistently
as well.

> > 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.
> 
> Sorry, I just now realized that this rectangle can't be 'absolute' in
> the same way the other rectangles can -- it moves with the panning

Exactly. That, and other potential issues.
I think we're really missing some ASCII art here ;-)

> I think using an offset rectangle would be less confusing than your
> border regions, as there wouldn't be any ambiguity over whether positive
> values were inside the crtc rectangle or outside. Having positive values
> make the box smaller is counter-intuitive to me, but I wouldn't want the
> 'normal' values to be negative.

Understood. I thought about several possibilities, but the borders I
came up with were the least confusing of all. For me, that is.

> > I assume so. I guess they can be added later. Will do that, but will
> > take some time.
> 
> I think we just need a picture of the four boxes here (screen, crtc,
> border and tracking) so we can see how they nest or not).

Yes.

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