problems with via and multiple screens
Paulo Zanoni
przanoni at gmail.com
Wed May 28 11:00:33 PDT 2008
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
More information about the xorg
mailing list