X Org server 1.7.99.2 is faulty

[Jeremy Huddleston]

The version in MacPorts is just 1.7.99.2 without any MP/Apple specific patches (since these have been going into master with fairly low latency).  My changes between 1.7.99.1 and 1.7.99.2(*) were mostly janitorial and didn't touch on the code-path where you're seeing a problem.

It may be some of the EXA related work.  Maybe Michael or Maarten might have an idea where to look.  That being said, it might be more worthwhile to just find the commit that introduced the bug using git-bisect.

# Checkout xserver from git:
git clone git://anongit.freedesktop.org/xorg/xserver
cd xserver

# Start bisecting the build:
# git bisect start <bad> <good>
git bisect start 3c30c5b6d321f34736c442c9cd982308d9b8b93a 9c48862ac1ac119b6cfb7e376533f53af6a857f4

# Then you just test it and then run either:
git bisect good
# or
git bisect bad
# depending on whether that checkout has the bug or not.

# To test each version, you'll want to just build it over your MacPorts:
export CPPFLAGS=-I/opt/local/include -I/path/to/macports/dports/x11/xorg-server-devel/files/dri
export PKG_CONFIG=/opt/local/bin/pkg-config
./autogen.sh --prefix=/opt/local --with-apple-applications-dir=/Applications/MacPorts --with-fontdir=/opt/local/share/fonts --with-launchd-id-prefix=org.macports --without-dtrace
make clean && make && sudo make install

# This will do a binary search to hone in on the change that introduced the problem.


*:
Jeremy Huddleston (17):
     XQuartz: Run xmodmap after programatically updating the keymap.
     dix: Properly detect if the other device is frozen
     XQuartz: Controller thread launches clients
     XQuartz: Don't weed out duplicates in generated keymap
     XQuartz: Use dixLookupResourceByType instead of LookupIDByType
     XQuartz: Cleanup X11Controller.m compilation warnings.
     SHA1: Add support for Common Crypto
     configure.ac: Notify user about which SHA1 implementation is being used
     XQuartz: Buildfix for Leopard and older
     XQuartz: pbproxy: Wait for the server to finish starting up, so display is valid.
     XQuartz: Explicitly pass a bellProc to make XBell() work again.
     XQuartz: Allow better compatability with older versions of xinit
     XQuartz: Drop calls to alloca
     Miscellaneous compilation warning fixes
     XQuartz: pbproxy: Fix building of standalone xpbproxy executable
     dtrace: Add Xserver-dtrace.h to CLEANFILES
     Xfake: Nuke -Wl,-undefined=InitExtensions from LDFLAGS


On Dec 29, 2009, at 07:57, Peter Dyballa wrote:

> Hello!
> 
> I am new to this list and I have a problem with the X Org server  
> version 1.7.99.2 – which is the name MacPorts gave it in its  
> (unstable) devel branch. The previous release, 1.7.99.1, was working  
> OK, the new one came around Christmas.
> 
> The faults show up with self-compiled GNU Emacsen 23.1.50 and 23.1.90.  
> When the tool frames are opened too much on the (preferred, because  
> brighter) right side of my display (1440 x 900, 32 bit, ATY,RV360M11  
> on AGP with 64 MB VRAM) text is cut around x-pixel coordinate 800  
> (graphics, like window decoration or pop-up or pull-down menus or the  
> cursor or background high-lighting of selected text, are always OK and  
> fully visible). A refresh of the X client's windows does not change  
> anything, also close/open. When moving the window towards the left  
> edge more text becomes visible upon a refresh, but the most right  
> approximately one inch is cut away and turned invisible. When the tool  
> frame is opened near the display's left edge, then GNU Emacs 23.1.50  
> works (almost) OK – except for the last column of text which is  
> invisible. I can stretch it to span the whole screen and no other or  
> more text gets swallowed, it's different from the situation when  
> launched on the right side with its closer barrier. GNU Emacs 23.1.90  
> still shows this failure clearly at the far right corner of the text  
> pane: a few mm, a few character columns, stay invisible – and it can  
> become worse when I move the window and/or change its size and shape.
> 
> Both Emacsen show another failure at the bottom, where the echo area/ 
> mini-buffer reside: all text invisible. And this zone stretches under  
> the completely functional mode-line into the bottom of the lowest  
> buffer and eat pixel-wise text. When launched on the right side this  
> phenomenon is clearly restricted to 80 or 90 % of the mini-buffer's  
> height.
> 
> 
> The previous version of the X Org server did not show this behaviour.  
> Maybe it plays a role that I am working with a PowerPC G4 processor  
> 7447A, only big endian.
> 
> --
> Greetings
> 
>   Pete
> 
> The human brain operates at only 10% of its capacity. The rest is  
> overhead for the operating system.
> 
> _______________________________________________
> xorg-devel mailing list
> xorg-devel at lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5820 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20091230/bfde9a5b/attachment.bin