I'm use dualhead(two separated desktops) desktop with: 01:00.0 VGA compatible controller: VIA Technologies, Inc. VT8378 [S3 UniChrome] Integrated Video (rev 01) 00:09.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) If I log off from desktop on VIA card, ATI ati screen is something mad. I attach screenshot, where you see what happends.
Created attachment 4890 [details] mad ATI desktop This is shown after log off from VIA desktop, probably if new login session is started
Note: It is nesesary use kernel 2.6.12 and older, because newest kernel have reworked PCI subsystem and therefore moust combination of cards(all what I test) does not work together, card No. 2 id blocket for several colision reasons...
Hrm. I'm currently running a mach64 CT in a VT7205 (which is the unichrome you're using too) box for rewriting ati/atimisc. The ati code is horrible. i'd first be pointing at the ati driver before anything else. But do attach a log or logs of a full run.
Created attachment 4946 [details] log of running ATI-VIA under certain kernel versions
Now I find that ATI want work vit VIA at new kernel, usign extra parameters: pci=nobios,rom and PCI card must be set as default in BIOS but VIA screen use resolution 640x480, change is not posibile...
The latter is because the Xorg VIA driver has no idea what memory timing the unichrome is at; because the relevant scratch registers aren't set up properly. My driver at unichrome.sf.net comes with an option which allows you to force that timing: Option "ForceMemClock" <integer>. The proper solution though is to poke the RAM controller directly again. And yes, ati/atimisc spends years poking all possible IO ranges everywhere to make sure that it certainly hasn't missed a device anywhere. And then just bails out later on when it's not primary and the BIOS image isn't available. So sick.
with Linux pinkyws 2.6.15-ck5-K7 #2 Mon Mar 13 13:30:20 CET 2006 i686 AMD Duron(tm) processor GNU/Linux and xf86-video-unichrome-0.2.3 work moust well, and kernel parameter are no longer needed, thanks
Great :) So what do we do with this bug?
I'm not sure, but is still nesesary use ATI(PCI) as primari display(set in BIOS) it may stay open until ati code will be clean. Everything what I may do is testing.... I'm something confused about VT8378 support in unichroma-0.2.x , previous version does not work for my and I expect that my card is not supported, because it is not listed in supported card list.... Is something diferrent betwen VT8378 and VT7205, except PCI ID?
VT7205 is the naming i've adopted for the different unichromes found on the nortbridges. VT8378 is a KM400 northbridge, which has a VT7205 for VGA, this VT7205 was originally and unmistakingly named "unichrome" initially. Then VIAs naming stopped making sense. xf86-video-mach64 will never be clean. I'm not planning on making it a new project. I'm just doing the following: - make its probing less insane (done) - drop the worst of the now made useless code (not done, but really, really looking forward to that bit *chainsaw murderer grin*). - drop the dotclock handling of older than mach64 cards so that the whole driver can be moved over to dynamic dotclocks (with a small workaround for when the DAC/clock isn't known). The latter is my reason to be involved in xf86-video-mach64. This so that i can make Xorgs mode handling more sane, and implement the last piece of the puzzle that is 5386. I will try to have the driver not fully depend on the BIOS code as it does now. This seems pretty straightforward.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.