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
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):
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
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]
Despite claims to the contrary (about shipping Alan instead of the
stock XFree86 via_drv.o), everything works perfectly with xorg-x11
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
%define with_via_driver 0
%define with_via_driver 0
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
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.