Re: [Solved] X11 slowness, command line hesitations, and pixel fuzz (blit leakage?) in xfce4-terminal

I know I'm going to get flack for top-posting, but I'm not sure what to trim (since many mail agents will break the thread on the subject-line change).

The shift from Xaa to Exa is definitely a bit early for a lot of the video hardware people have.

How it tends to bite is like this:

X11 is slow to respond, has update issues where it may trash parts of the screen, has issues updating desktop icons in gnome failback (and others), etc. This may be relevant to other recent threads.)

This work-around seems to be useful in my case and Selim's case:

Look for your xorg.conf and check the device section for the display card.

If you can find xorg.conf (say, in /etc/X11 or some such, "man xorg.conf" and "whereis xorg", etc.) find the section for your video display card. There may be more than one section, even if you only have the on-the-mother-board graphics. It looks like this:

-----------------------

Section "Device"

### Availiable Driver options are:-
[...]

#Option "PrintVGARegs" # [<bool>]
[...]

#Option "AccelMethod" # <str>
[...]

Identifier "Card0"

Driver "openchrome"

[or other driver for your video hardware]

BusID "PCI:1:0:0"

[or whatever the PCI bus address for the graphics hardware is]

EndSection
------------------------

Change the commented-out

#Option "AccelMethod" # <str>

to

Option "AccelMethod" "Xaa"

and log out and back in (or othewise re-start xorg). If you mess up the syntax (like I did), you can log in on a virtual console (ctl-alt-Fn) to fix things from the command line, and you may be able to test it like I did with startx.

If you can't find xorg.conf (with "whereis" or such), you may not have one. In which case you can do this:

sudo Xorg :1 -configure

and it will leave a new xorg.conf.new in your /root directory. It may complain about odd things like not being able to find all the screens specified, but that's okay.

Edit the generated xorg.conf, removing all the stuff except the device section for the video card that has the problems. (Yes, that's most of the generated file. If you didn't have the xorg.conf file before, you don't need anything but that device section.

I made a "/etc/X11/xorg.conf.d" directory and saved the generated, edited file as

/etc/X11/xorg.conf.d/10-disp-openchrome.conf

to keep with the current structure of things.

Of course, when the get the "Exa" acceleration problems ironed out, you'll want to remember to revert the configuration.

(I copied the line and edited the copy, so I have the original line commented out as a reference point.)

(Leaving the end-point of the thread for reference:)

On Fri, Jul 19, 2013 at 10:17 AM, Joel Rees <joel.rees@gmail.com> wrote:

On Wed, Jul 17, 2013 at 3:18 AM, Selim T. Erdogan <selim@alumni.cs.utexas.edu> wrote:

Joel Rees, 16.07.2013:

> On Mon, Jul 15, 2013 at 4:52 PM, Joel Rees <joel.rees@gmail.com> wrote:
>
> > On Mon, Jul 15, 2013 at 6:36 AM, Mike Kupfer <m.kupfer@acm.org> wrote:
> >
> >> Joel Rees wrote:
> >>
> >> > > Anybody else seen this? Have an idea what's going on?
> >>
> >> I haven't seen this, nor do I know what's going on, but here are some
> >> things I would check if I were seeing that sort of video breakage:
> >>
> >
> > Thanks for responding. I was wondering if everyone had kill-filed me.
> >
> >
> >> Do you have compositing enabled (under Window Manager Tweaks)? If you
> >> do, does the problem go away if you disable compositing?
> >>
> >
> > Compositing is not enabled, according to the GUI. Maybe I should try
> > enabling it. (My son's monopolizing the box right now.)
> >
>
> Hmm. I enabled compositing and, while the blit leftovers don't immediately
> go away, sometimes, but not always, several seconds after they appear, they
> go away.
>
>
> > I'm assuming that you're using more or less standard Xfce.
> >
> >
> > Haven't been ambitious enough to do a lot of modding, so it should be. But
> > I'm not confident I got all the implicit dependencies taken care of when I
> > upgraded from squeeze to wheezy.
> >
> >
> >> If that's
> >> incorrect, a more detailed description of your desktop setup would be
> >> helpful.
> >>
> >> And do you know what video card you're using and what driver?
> >>
> >
> > On-board graphics on a cheap AMD (Sempron) motherboard -- VIA KM266pro, I
> > think, maybe KM400, + VT8237 -- from about eight or nine years ago.
> >
>
> >From "lspci -nn | grep VGA" :
>
> 01:00.0 VGA compatible controller [0300]: VIA Technologies, Inc.
> KM400/KN400/P4M800 [S3 UniChrome] [1106:7205] (rev 01)

I actually have the same card (in an Averatec 3200 series laptop from
2004, with an AMD Athlon processor) and I might have a solution for you.
For several months now, I've had some minor problems where I suspected
the video driver was the issue and finally this weekend I dove into the
code to check things out. So your timing is good. :)

Great!

The "leftover stuff" problem isn't actually one that I'm having directly
but it is similar to something I've seen. For a long time, when I
turned the computer on after hibernating, sometimes my graphics would be
messed up and I would have to log out and back in to fix it. I haven't
had it happen very much recently but I'm not sure it was fixed directly
because it seems related to my next problem...

I use gnome-3 in fallback mode and the icons at the top right ---
battery, sound, network --- wouldn' get updated to reflect the
current state, though the hovering-clicking functions worked correctly.
They would only get refreshed when I went to a virtual terminal with
ctrl-alt-f1 and came back with alt-f7.

Yeah, the delayed refresh aspect does sound similar.

This weekend I figured out that this not-refreshing is due to the driver
switching its default to Exa, from Xaa. When I put

Option "AccelMethod" "Xaa"

in the Device section of my xorg.conf, the icons are refreshed
properly.

And I have no xor.cong. Running pure default. Last time I generated an xorg.conf, I decided I didn't want to do that any more. But I guess it has to be. So I just ran

Xorg :1 -configure

and it tells me that the number of created screens does not match the number of detected devices. Heh. But it gave me an xorg.conf.new in the /root directory with enough device lines to try mucking with it. Lots of stuff to mess with if I had time, various buffer sizes, BIOS settings (although, with only 3/4G of system RAM, trying to tune the buffer sizes could turn into a great thumb-twiddling exercise.

Setting "DisableIRQ" to "False" doesn't change things, at any rate. Forgetting the quotes makes X11 not want to work, but the trusty old startx works well enough to keep me in business testing without rebooting.

And ... setting "AccelMethod" to "Xaa" as you suggest ...

... does seem to cure the hesitation and the trash on the screen leftover from botched blits.

This will definitely make it easier to use git and svn.

Maybe this could fix your problem too. (This is just a
workaround at the moment but I'm going to look into this some more.)

The other problem I've noticed was that colors were cockeyed --- like
the blue and the red were flipped or something --- when I played videos
in vlc. I now have a patch that fixes this.

Playing videos in totem also has problems, which I thought I'd noticed
around the time I noticed it in vlc, but checking it again, it's a
different problem --- videos show as a single garbled image --- and I
haven't investigated that yet.

I will be filing bugs for the exa-not-refreshing and flipped-colors
issues this week but I wanted to test things one last time. I'll let
the list know when I file the bugs.

> I guess this is the appropriate comment on the state of the driver:
>
> http://packages.debian.org/wheezy/xserver-xorg-video-openchrome
> --- hardware acceleration has been ripped out of the sourceforge code.
>
> Which sounds like some NPE went after the project.

I looked up NPE and got Non-Practicing Entity. Is that what you
meant? That wasn't what happened for this driver, as far as I know.
In fact, at the url you gave above:
---
Support for hardware acceleration (XvMC) for all chipsets has
subsequently been ripped out of the unichrome.sf.net driver. Therefore
your only option if you wish to make use of the acceleration features of
your VIA chip with free and open-source drivers is to use this version
of the driver.
---
Meaning XvMC acceleration support is in the openchrome driver in debian.

Here's the story: there was/is a driver called unichrome for these via
cards that had both video acceleration and 3d.
(The debian package description even has a URL for it:
http://unichrome.sourceforge.net/) But the main developer of unichrome
thought the code quality of the people working on the XvMC stuff was not
good enough and there were disagreements. Eventually, he ripped
that stuff out and openchrome was forked.

(I've used unichrome in the past but I haven't tried it out in a
couple of years. It doesn't get developed anymore, as far as I know,
but I ran across a message on its list recently from somebody saying he
managed to install it. I think its 3d support was better than
openchrome's at the times when they first forked but they might
have caught up. I don't know.)

The bugs we're experiencing are probably due to there not being too much
development activity around the openchrome driver and also regressions
affecting older cards going unnoticed since there aren't too many users
anymore.

Selim

Thanks for the background on the unichrome versus openchrome projects.

--
Joel Rees