Hide Forgot
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.
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.