[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#446123: bugfix for endianness?



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@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


Reply to: