Problems with two ATI cards, in recent X versions

[Theodore Kilgore]

On Fri, 24 Aug 2012, Michel Dänzer wrote:

> On Don, 2012-08-23 at 18:27 -0500, Theodore Kilgore wrote: 
> > 
> > As you can see, it is intended that the "panning" dimensions ought to 
> > remain at 1920x1080 so that by moving the mouse here or there it is 
> > possible to see any part of the desktop which is outside of the 800x600 
> > window, or, one might say, to be able to move the 800x600 "magnified" 
> > window to any part of the 1920x1080 desktop.
> > 
> > Several X versions ago, this used to work. But then it quit working. What 
> > happens instead is that, if the script is run while the mouse cursor is 
> > near the bottom right of the screen all is OK. One can move to the left 
> > and or move up, and the 800x600 window follows the mouse. But once one has 
> > done that, the 800x600 window is frozen in place and cannot be moved back 
> > downward, or back to the right.
> > 
> > Experimentation has caused me to suspect that the problem is in the ATI 
> > driver code somewhere, or in the radeon driver code.
> 
> That's rather unlikely, as the video driver doesn't deal directly with
> mouse input at all but just sets the display viewport as requested by
> the X server.
> 
> It sounds like this problem could be fixed by this xserver patch:
> http://patchwork.freedesktop.org/patch/11524/

The two machines are, respectively, at home and at the office. The one at 
home is the one on which this needs to be tested. Right now I am at work, 
sitting in front of the other machine.

I can certainly try the above-mentioned patch. Where am I supposed to get 
the code which is to be patched, though? Should I use recent 
distro-distributed code, or should I use code from a repository somewhere? 
Please let me know. Also, assuming that this patch works, is this patch 
something which is "coming soon"? Just curious.


> 
> 
> > Meanwhile, I am forced to run an older version of
> > X-practically-everything in order to try to work around this problem. 
> > This becomes increasingly difficult, as new versions of various kinds
> > of software (the latest Firefox, for example) seem to have
> > dependencies on newer versions of X-related libraries.
> 
> FWIW, the X server-side components and client-side libraries are mostly
> independent, you should be able to use newer versions of the latter with
> older versions of the former.

Yes. That is exacytly what I am doing right now. But you might imagine 
that with X-related stuff being split up into several hundred packages it 
takes a while to get this right. So, understandably, I would feel relieved 
if I did not have to do that any more.

> 
> 
> > With this machine, the problem is that it is impossible to stop X once it 
> > is started. At worst, the machine can be frozen with a blank screen and an 
> > apparent kernel panic, causing the machine to be totally unresponsive to 
> > any action except to hit the power button. 
> 
> Is it still accessible via network? 

Excellent question. The problem is, how do I access it over the network? I 
could of course go home and access it over the network, but it is 
difficult to go next door, when most others are using machines with that 
other, crippled OS on them, which cannot do ssh. Otherwise, I do not like 
to go away and leave the machine jammed up because it is my mail server 
among other things.

If so, can you log in via ssh and
> get the Xorg.0.log file and dmesg output?

Will try to figure out how this is feasible. See aove.

> 
> 
> > Unfortunately, I did not keep records of exactly at what point or at which 
> > versions of what related packages these problems started to occur with 
> > either machine, but I could, of course, report the versions which are 
> > known to work and which I am currently using.
> 
> It's certainly useful to isolate which version of which package
> introduced a problem as much as possible.

No joke. But have you ever noticed how one typically gets reminded of this 
truth _after_ the problem occurs?

Got to go and teach a class. Get back later.

Theodore Kilgore