Description of problem: When using Xv and the new via driver, the colors are completely off (e.g. black becomes light gray as if the brightness was way too big, except the brightness setting in applications doesn't do anything). Normal use is just fine, as is DRI. A workaround is to start up X once with the driver from http://www.shipmail.org/%7Ethomas/via/xfree43/epia7.2/, after which the -57 driver works as expected as well. This is until the machine is powered down, e.g. booting to a new kernel doesn't break things. This would suggest there's a "Make Xv work" register that isn't being set somewhere... Adapter in questions (EPIA MII-10000 embedded thing using TV-out) 0000:01:00.0 VGA compatible controller: VIA Technologies, Inc. VT8623 [Apollo CLE266] integrated CastleRock graphics (rev 03) (prog-if 00 [VGA]) Subsystem: VIA Technologies, Inc. VT8623 [Apollo CLE266] integrated CastleRock graphics Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Version-Release number of selected component (if applicable): 4.3.0-57
Thanks for testing PP. I've cc'd _A_, however I believe he's busy for another week or so, so it might be a few weeks before we can poke at this. Thanks for reporting the issue.
Could you attach your X server log and config file as well, in case that comes in handy? Alan: Have you seen similar reports of this nature with the via driver?
Created attachment 98335 [details] XFree86 log of "doesnt work"
Created attachment 98336 [details] diff of "doesnt work" and "works" log This is after starting up X once with the other driver and then going back to the -62 via_drv.o
Created attachment 98337 [details] XF86Config
Despite claims to the contrary (about shipping Alan instead of the stock XFree86 via_drv.o), everything works perfectly with xorg-x11 even after a poweroff. Well, except glxinfo, which blows up just like it does with "nv" on my other box, but you already knew that :-)
We are currently shipping the stock via driver in xorg-x11 temporarily, as I haven't updated the build to use Alan's driver yet. %ifarch %{ix86} %define with_via_driver 0 %else %define with_via_driver 0 %endif Once we've got Alan's driver back though, the problem might possibly recur. If it does, just reopen the report at that time, and we'll have a look. Thanks Pekka for the update.
Keep the xorg one, its my driver with later fixes FC1 XF4.3 hasnt got 8)
There does not appear to be a via DRI driver in the xorg tree however, so we've lost DRI support. If someone can confirm that your last via-dri snapshot works with Mesa 5 that is included in Xorg X11, I can reinclude it though. For now, I'll just keep the Xorg via 2D driver as per your recommendation. Thanks for the update Alan.
Ok right the 2D driver in Xorg has all the DRI hooks, and is better than the 2D driver block you have. The DRI driver I thought had been merged but if not then the current via driver is on unichrome.sourceforge.net (and those are its definitive maintainers nowdays), so it would be a good idea to use that and for Xorg to adopt that code (or persuade them to become Xorg maintainer for via 8)) 3Dwise I'm hoping Test2 will boot on EPIA-M (test1 failed completely), so that I can merge the kernel dri module for 2.6 from unichrome.sf.net and check that is also working fine. Alan