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.r...@gmail.com> wrote:
> On Wed, Jul 17, 2013 at 3:18 AM, Selim T. Erdogan <
> se...@alumni.cs.utexas.edu> wrote:
>
>> Joel Rees, 16.07.2013:
>> > On Mon, Jul 15, 2013 at 4:52 PM, Joel Rees <joel.r...@gmail.com> wrote:
>> >
>> > > On Mon, Jul 15, 2013 at 6:36 AM, Mike Kupfer <m.kup...@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
