Bug#446123: bugfix for endianness?

[Adam Bartley]

You're a genius. Gnome 2.20 had somehow switched out of the compositing
cursor, which was probaly why I had suddenly noticed the change. When I
changed to an argb compositing one - problem solved. I agere with what you
are saying about not holding back the RandR functionality. Sometimes there
is no elegant way forward in these situations.

With best wishes,

Adam

On Jan 12, 2008 11:53 AM, Michel Dänzer <daenzer at debian.org> wrote:

>
> On Fri, 2008-01-11 at 20:10 +0000, Adam Bartley wrote:
> > Ok, I can see why that is good coding practice on one level, but on
> > the other hand a piece of code has been out in January 2008 which had
> > been shown to be faulty months before in 2007. Maybe it should have
> > been held out of circulation until the authors can come up with a
> > solution?
>
> Ideally; the problem being that when RandR 1.2 support was added to
> xserver 1.3, only xf86-video-intel had the corresponding driver support,
> and that driver can physically only work on little endian platforms. The
> issue was only discovered when RandR 1.2 support was added to the
> xf86-video-ati radeon driver and working on PowerMacs, and now it would
> be harsh to rip out the server support again for a minority.
>
> Note that only legacy two-colour cursors are affected, not modern 32 bit
> ARGB cursors.
>
> Also, I think the old driver specific conversion code that was used
> before RandR 1.2 could still work now; reinstating that would be a
> relatively simple task for someone who is determined about fixing this
> issue.
>
>
> --
> Earthling Michel Dänzer           |          http://tungstengraphics.com
> Libre software enthusiast         |          Debian, X and DRI developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.x.org/archives/xorg-driver-ati/attachments/20080114/f3aba42a/attachment.html