problems with via and multiple screens

[Paulo Zanoni]

Hi!

I have video cards that are VIA chipset 0x3344 (xorg.conf says it is
P4M800Pro/VN800/CN700, lspci says it is VIA Technologies, Inc. UniChrome Pro
IGP rev 01). They are onboard video cards.

In computers with multiple X screens (this VIA + other PCI cards in ONE Xserver)
some of the non-via screens get incorrectly drawn. This only happens if the
computer has this VIA card, but only some non-VIA screens get incorrectly
drawn.

For example, in one setup, I have this via card and 3 ATI Rage XL. If I open the
multi-screen Xserver and then run an Xephyr in an ATI screen, if I start
quickly dragging one window some points of the screen will NOT be redrawn. That
means after some seconds I'll see pieces of the window all over the screen.

Screenshots: http://www.inf.ufpr.br/prz05/via.html

I've tried using both the VESA and the OPENCHROME drivers, but both gave me the
same behavior (and these are the only ones that support the 0x3344 card)

What I observed while trying to discover the reason of the bug:

- If I mouse-over the incorrectly-drawn region, it will draw itself again, and
  correctly (you can see this on the pictures).

- When I send SIGUSR1 to Xephyr, it paints a red square before anything it
  draws. If I try to reproduce the bug with this feature, I'll see lots of red
  squares on the screen (Xephyr draws a red square on the region because it
  knows it should be redrawn, then it calls the X{Shm,}PutImage to actually draw
  the content but it is NOT drawn).

  Pictures: http://www.inf.ufpr.br/prz05/via.html#sigusr1

- Another thing that I noticed is that if, while the bug is "happening", I open
  a full-screen window (like another Xephyr or "xterm -geometry 1024x768+0+0")
  on the VIA screen, the bug will STOP happening (until some other strange
  condition triggers it again). If I kill this window, it starts happening
  again.

- Another fact is that if I take a screenshot of the screen (pressing the
  screenshot key), it won't show the bug! (so I had to take real pictures of the
  screen instead of screenshots to show you...)

- I have a LOT of machines with this VIA card, and in some of them (mostly
  dual-heads) the bug does not happen. Looking at xorg.conf, I see that
  every time I have a VIA card where the bug IS happening, it writes something
  like this:

(II) Setting vga for screen 0.
Screen 0 is using RAC for mem
Screen 0 is using RAC for io
Screen 1 is using RAC for mem
Screen 1 is using RAC for io
Screen 2 is using RAC for mem
Screen 2 is using RAC for io
Screen 3 is using RAC for mem
Screen 3 is using RAC for io
(II) Screen 0 shares mem & io resources
(II) Screen 1 shares mem & io resources
(II) Screen 2 shares mem & io resources
(II) Screen 3 shares mem & io resources
(taken from via + 3 * ati rage xl 8mb rev 65)

And every time the bug is NOT happening, it writes things like this:

(II) Setting vga for screen 1.
(II) Entity 0 shares no resources
(II) Entity 1 shares no resources
(taken from via + s3 savage 4 rev 04)

Or:

(II) Entity 0 shares no resources
(II) Entity 1 shares no resources
(II) Entity 2 shares no resources
(taken from via + 2 * riva tnt2 64pro rev 15 + sis 315 pro)

- Another thing that I noticed is that Xephyr uses X{Shm,}PutImage to draw its
  contents. It always redraws little pieces of the big image. If I tell Xephyr
  to draw the whole image, it WILL draw it correctly. Changing Xephyr to always
  draw the whole image is not an option because it is too slow. Other thing that
  I noticed is that it uses XFillRectangle to draw the red squares (for the
  debugging SIGUSR1 mode), and this call always works.

- It makes no difference if Xephyr is using Shm or not.

- If I have four displays, for example, :0.0 being the via display and :0.1,
  :0.2 and :0.3 being the ati displays, I can only reproduce the bug on displays
  :0.2 and :0.3.

- I know there are other ways to reproduce the bug and other events that trigger
  it, but this is the only one I can reproduce 100% of the time.

So, where do you guys think the bug must be? Resource access control?
Framebuffer codes? Xephyr? Hardware bug? Any hint?

Considering the problem and the behavior I observed, what can you conclude?

Thank you very much!
(and sorry for the huge e-mail).

Paulo.


-- 
Paulo R. Zanoni