[PATCH] Ignore RandR timestamps harder

Keith Packard keithp at keithp.com
Thu Jun 10 13:45:17 PDT 2010


On Thu, 10 Jun 2010 13:49:52 -0400, Chase Douglas <chase.douglas at canonical.com> 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 <keithp at keithp.com>
> > ---
> > 
> > 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.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100610/334474f4/attachment.pgp>


More information about the xorg-devel mailing list