Mass migration: via -> openchrome.

(In reply to comment #0)
> The VIA P4M890 chipset was released almost two years ago; is there any reason
> why there's no supported driver for it yet?  System-config-display detects that
> that's what chipset I've got, but then it uses the generic vesa driver rather
> than an accelerated driver.

Please try with xorg-x11-drv-openchrome, it should support your chipset. It is
currently available for F7, F8 and Rawhide, but it probably doesn't work with
the latest rawhide X bits, as it's not yet ported to libpciaccess.

Please let me know if it worked.

Regards,
Xavier

Not so good.  I've got current rawhide, including
xorg-x11-drv-openchrome-0.2.900-9.fc9 and
xorg-x11-server-Xorg-1.4.99.1-0.13.fc9.  I tried changing "Driver "vesa"" to
"Driver "openchrome"", and it wouldn't use most of the available modes because
of some sort of complaint about bandwidth ("Required bandwidth is not available.
(423037190 > 74000000)".  I had no idea what that meant, but I found something
in the man page about "Option "VBEModes" "true"", so I added that option.  With
that option, it started with the resolution I wanted, but it performed poorly,
had all sorts of weird problems drawing windows, and eventually locked up my
system (i.e., ctrl-alt-backspace didn't work, system stopped pinging, had to do
a hard reset).

Any suggestions?

Rawhide is probably not the best test bed for openchrome at the moment, because
the libpciaccess support is rather new and not properly tested. Anyway, could
you please provide the xorg logs, both without and with VBEModes enabled ? Also,
please provide the xorg conf. I assume the only option you changed is VBEModes,
so just one conf will do, if not please provide both.

Regards,
Xavier

Created attachment 290021 [details]
output of xinit when using openchrome without vbemodes

Created attachment 290022 [details]
Xorg.1.log when using openchrome without vbemodes

Created attachment 290023 [details]
xinit output when using openchrome WITH vbemodes

Created attachment 290024 [details]
Xorg.1.log when using openchrome WITH vbemodes

Created attachment 290025 [details]
xorg.conf file

I know rawhide isn't completely stable right now, but it's what I've got, and I
can't easily downgrade.

Could you please post the output of 'cat /proc/mtrr' too ?

reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x7c000000 (1984MB), size=  64MB: uncachable, count=1
reg02: base=0xa0000000 (2560MB), size=  64MB: write-combining, count=1
reg04: base=0xf0000000 (3840MB), size= 128MB: write-combining, count=1

New release in rawhide with an updated libpciaccess patch. Please test again
(w/o VBEModes) and post the xorg log.

With:

libpciaccess-0.9.1-2.20071031.fc9
xorg-x11-drv-openchrome-0.2.901-1.fc9

I get this from xinit when I try to start up the X server:

X: symbol lookup error: /usr/lib/xorg/modules/drivers//openchrome_drv.so:
undefined symbol: pciReadByte

Sorry, my fault. I've just made a new build that should fix this :
http://koji.fedoraproject.org/koji/buildinfo?buildID=30544

Could you please test again ?

Created attachment 291109 [details]
log of segfaulting X server

It's no good.  Now the X server is segfaulting.  See attached Xorg.1.log.

Yet another update. I hope it'll be better this time. I'm sorry but I don't have
a rawhide machine with a VIA IGP to test with...
http://koji.fedoraproject.org/koji/taskinfo?taskID=340181

Still no good.  With xorg-x11-drv-openchrome-0.2.901-4.fc9, I get: "X: symbol
lookup error: /usr/lib/xorg/modules/drivers//openchrome_drv.so: undefined
symbol: xf86memcpy"

ah, not my fault this time :-) This comes froma change in xorg-xserver.
New package with a fix for that here, if you wanna test before it hits Rawhide :
http://koji.fedoraproject.org/koji/buildinfo?buildID=32082

Works, finally.  But then I ran tvtime and it wedged my X server.  When I killed
gdm-binary and Xorg and restarted it, the green rectangle that tvtime had left
on the screen when it wedged was still there.  The only way I was able to clear
the screen was to reboot my machine.  Doesn't seem like it should do that. 
Should I file a separate bug about that?

This is probably an Xv bug. Can you please attach the xorg log and conf, I'd
like to see if everything is OK and possibly try to diagnose the tvtime issue.
Does it do the same, with, say, a video player or anything else using Xv ?

mencoder seems to provoke the bug sometimes too, not just tvtime.  I'll attach
my current conf and xorg log.

Created attachment 292576 [details]
xorg.conf using openchrome which provokes xv problem

Created attachment 292577 [details]
Xorg log file with openchrome driver that has Xv problem

*** Bug 429894 has been marked as a duplicate of this bug. ***

I've just built a new version (0.2.901-15) with much better libpciaccess
support, please give it a try.

With xorg-x11-drv-openchrome-0.2.901-16.fc9.i386, and all other current packages
from Rawhide (except FC8 kernel), tvtime still produces a bright green window
and hangs my X server, and then after I kill -9 the X server and it restarts,
there's still a green rectangle on the screen where the tvtime window was, and I
have to reboot my computer to clear it.

So it would seem that XVideo is still broken.  I don't know whether this
breakage is unique to the openchrome driver or more generalized.

With today's updates from Rawhide, including a Rawhide kernel, I still can't use
XVideo with my P4M890 chipset.  Symptoms continue to be as described above.  Are
we really going to ship F9 with XVideo not working for this chipset (and, I
suspect, for others as well)?

Xv is definitely not broken on all chipset. I know it is working on CLE266,
KM400 and VM800. None of them are Chrome9 though. An upstream dev suggested it
might be something specific to both tvtime and Chrome9, and that removing some
function call from tvtime could help. I'll look at my log to find which specific
call. Meanwhile, could you please give xine a try ?

Created attachment 303774 [details]
f9 and totem-xine Xv window on P4M890. The same with xine-ui

mplayer and xine using the xvideo driver have the same problem as tvtime.  This 
is not just a tvtime problem.

Yup, Leon confirmed that too. Can you and Leon please try to switch to only 64
MB of shared video ram ? And please attach the xorg conf and xorg log, so I'm
sure I'm working with uptodate datas. 

Created attachment 304802 [details]
Xorg log

Sorry for delay, but my access to VIA box is limited. Attaching the logs. Please
take a look at the last lines. I think this problem is DRI-related, because
openchrome driver works fine in FC7 on the same box (without DRI suport).

Created attachment 304803 [details]
xorg.conf

Created attachment 304804 [details]
Screenshot with latest driver

xorg-x11-drv-openchrome-0.2.902-3.fc9.i386

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Jonathan, Leon, I'd like you to try various things and see if it helps or not.
First, please try to add in the device section of your xorg conf, one at a time : 
Option "NoXVDMA"
Option "NoAGPFor2D"
If none of this helps, please dry to disable dri by commenting the Load "dri"
line in the Module section.
 

I've just tested proposed module options.
With "NoXVDMA" Xv works perfectly.
With "NoAGPFor2D" bug was reproduced.

Please disable XV DMA by default for this chipset, if possible.

I am seeing really, really weird behavior, and I just don't know what to do 
about it.

I updated everything from Rawhide, including the current Rawhide kernel, and 
rebooted.

Then I tried "mplayer -vo xv" with Option "NoXVDMA" "true", and it worked.  
Then I tried "mplayer -vo xv" with Option "NoAGPFor2D" "true", and it worked as 
well.  Then I tried "mplayer vo -xv" with *neither* option, and it worked as 
well!  (Yes, I killed and restarted the X server for each attempt and confirmed 
from looking at the server log that the relevant option was in place.)

Then I rebooted and once again tried "mplayer -vo xv" with none of the options 
you mentioned, and it *didn't* work -- the old green window problem was back.  
Even though it had worked right before the reboot (is it possible that running 
the X server with "NoXVDMA" or "NoAgPFor2D" before I rebooted, set something 
persistently in the video subsystem that was cleared by the reboot?).

It gets even weirder.  Immediately after "mplayer -vo xv" failed in a GNOME 
session, I switched to a text console, logged in, and started X with xinit 
(i.e., not through GNOME), and then ran "mplayer -vo xv" in that X session, and 
it worked.  So I had two X sessions running, both supposedly using the same 
exact config file, and xvideo was working in one and not in the other.

Throughout all of this, tvtime was still failing, even when mplayer was 
working -- as soon as I started tvtime, my X server hung, and after I killed 
and restarted it, a black rectangle remained on the screen where tvtime had 
been running.

Obviously the same XV problem exists also on K8M890. Activating NoXVDMA=true
avoids all problems (mplayer). 
Occasionally I have also seen following on Xorg.log, but I'm not sure if it is
related;
(EE) CHROME(0): [drm] Failed to initialize DMA ring-buffer: 22

XvDMA is deactivated by default for P4M890, K8M890 and P4M900 in the openchrome
packages currently available in updates-testing for F7, F8 and F9. Packages
versions are respectively : 
xorg-x11-drv-openchrome-0.2.902-2.fc7
xorg-x11-drv-openchrome-0.2.902-2.fc8
xorg-x11-drv-openchrome-0.2.902-6.fc9

I can confirm now that DVD playback works perfectly with default xorg.conf. 

Xv is still broken on K8M890 on Amilo 1703la.
Using xorg-x11-drv-openchrome-0.2.902-6.fc9.x86_64 with NoXVDMA in xorg.conf on
2.6.25.4-30.fc9.x96_64.
I'm attaching xorg.conf and xorg log

Created attachment 308592 [details]
K8M890

Created attachment 308594 [details]
K8M890 xorg.conf

(In reply to comment #44)
> Xv is still broken on K8M890 on Amilo 1703la.
Is the Xv window black or green ?
If you have a VGA port, does Xv work on an external monitor ?

(In reply to comment #47)
> (In reply to comment #44)
> > Xv is still broken on K8M890 on Amilo 1703la.
> Is the Xv window black or green ?
> If you have a VGA port, does Xv work on an external monitor ?
 
The window is black. I have no monitor at hand to test if it works. 

(In reply to comment #48)
> > > Xv is still broken on K8M890 on Amilo 1703la.
> > Is the Xv window black or green ?
> > If you have a VGA port, does Xv work on an external monitor ?
>  
> The window is black. I have no monitor at hand to test if it works. 
> 
Ok, this is a different bug. I'll build a fixed version later today.

Here's the koji build to grab before it goes into updates-testing :
http://koji.fedoraproject.org/koji/taskinfo?taskID=652639

I grabbed the Xv_LCD patch from the f8 rpm and replaced the Xv_LCD patch in the
f9 rpm. I built it and it works just fine. Thanks for the quick response. 

oops, sorry the latest link was for F8. This one is for F-9 :
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=652652

xorg-x11-drv-openchrome-0.2.902-7.fc9 has been submitted as an update for Fedora 9

xorg-x11-drv-openchrome-0.2.902-7.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.