On Thu, 10 Jun 2010 13:49:52 -0400, Chase Douglas <[email protected]> wrote: > On Thu, 2010-06-10 at 07:38 -0700, Keith Packard wrote: > > Checking timestamps in post 1.1 randr requests was never a good idea, > > let's ignore them and just make the configuration changes. > > > > Signed-off-by: Keith Packard <[email protected]> > > --- > > > > Because the new randr code uses persistent resource ids for all of the > > objects in question, there's no concern that the configuration will do > > something weird if done with stale information. As such, we really don't > > need to check these timestamps, they serve only to cause random failures > > when applications get them wrong somehow. > > > > randr/rrcrtc.c | 33 --------------------------------- > > 1 files changed, 0 insertions(+), 33 deletions(-) > > I believe this is what I was working around with the following patch: > > http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=c114f0ca3da756725996bfa2111b2cc4e1982d92 > > I didn't know the rationale for checking timestamps, so I didn't propose > fixing the issue in X. However, dropping the check seems right in my > mind.
There were two original rationales -- the first was that the original RandR protocol didn't have XIDs for the exposed objects, just indices in various arrays. Using stale indices could lead to weird results. That's obviously fixed now that we use stable server-allocated XIDs. The second was just a fuzzy desire to avoid the colormap install bug where the lack of timestamps could easily lead to the wrong colormap getting installed as clients sent requests asynchronously. Given that screen configuration isn't likely to be managed by more than one client, or set rapidly, I don't see this as an issue either. -- [email protected]
pgpfvpyRzvjij.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
