Xv: colour ordering off after suspend/resume
Brought to you by:
dwdeath
I'm use suspend to disk kernel feature.
After resume is in video exchanget color ordering. from
RGB to BRG -> I see blue instead of red, red instead of
green and greeninstead of blue.
This does not happend if I restart X (to show right
colors) and try switch into colsole, may be because
text console does no show it self, I still see
"screenshot" of X.
If I suspend/resume and try switch into text colsole I
can see them.
some verbole X.org log
Logged In: YES
user_id=1206973
This is only fo Xv video output x11 work wll in every case.
Logged In: YES
user_id=220099
Ooh, smashing, your KM400As BIOS does accept DDR400 timing.
Neither of my KM400As (main box and shuttle FX43) do.
So, the hardware overlay has the colours ordering broken
after resume. I'll have a look round, but this will probably
mean dumping some registers.
Logged In: YES
user_id=1206973
I connot now reproduce "X screen shot" after switch into
console... but RGB bug still present (and unhandled RAM bug
is reproduced as you see in log)
Logged In: YES
user_id=220099
The HQV (scaler/filter) is set for YV12, and the data being
pushed between HQV and V3 overlay is in YUY2 format, so the
RGB re-ordering seems weird. Are you certain that it's not the
Logged In: YES
user_id=220099
... U and the V components that are being swapped?
Anyway, try the attached patch, should work on any recent
unichrome.sf.net code. Try to run an Xv overlay before the
suspend/resume and the same one after the suspend resume.
Logged In: YES
user_id=1206973
You does not attach patch?
Logged In: YES
user_id=220099
Bleh, forgot checkbox.
log file - patch Xv_colour_ordering_debug.diff applied
Logged In: YES
user_id=1206973
I add for my self one or two messages (mesage parameters)
(EE) VIA(0): ViaSwovBandwidth: pVia->Chipset: 2.
(EE) VIA(0): ViaSwovBandwidth: Handled RAM type: 3.
(EE) VIA(0): ViaSwovBandwidth: Unhandled RAM type: 3.
and set up log level 9, it si not too high?
result and description for previous sended log file
Logged In: YES
user_id=1206973
You patch broke my browser(mozilla-ff)!, it does not redraw
web page window, or redraw with mad lines (fragments of
screen). I must now swap betwen desktops to redraw them!
Logged In: YES
user_id=220099
My recent commit, nor my patch shouldn't have broken
anything. One was noise reduction, silenced the
unneccessary: (EE) VIA(0): ViaSwovBandwidth: Unhandled RAM
type: 3. Other was a lot of crap getting dumped to the log
whenever you start a new Xv overlay, shouldn't be much
overhead.
Please do use a clean git checkout.
Logged In: YES
user_id=1206973
You are right, I copy my old corg.conf (with disabled
Option "EnableAGPDMA" "True"
Option "UseDMACopy" "True"
)
After switch into console and back is may browser broken.
I attach new log aplied to 0.2.5-unichrome
is posobile use git trought http proxy?(In other case I can
not (simpli) use due tue network restriction...)
Xv_patch applied to unichrome-0.2.5
Logged In: YES
user_id=1206973
ViaSwovBandwidth: Unhandled RAM type ---
1. restarted X sever
2. set to console and back
3. swsusp and resume
"console screenshot" is now here, as is described below.
(WW) VIA(0): [drm] Not using DMA for copying to FB (drm
driver older than 2.7.5)
-- May upgrade help??
Logged In: YES
user_id=1206973
I found something interest,
if I use
-march=athlon-xp -O0 -pipe -fomit-frame-pointer
in CFLAGS I get moust black screen with minor blue compund
(brightness??)
if I use
-march=athlon-xp -Os -falign-loops -freorder-blocks -pipe
-fomit-frame-pointer -finline-functions --param
max-inline-insns-auto=24
There are present more compunds and it look like complete
decoded mpeg picture with Xchg colors
gcc (GCC) 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)
Logged In: YES
user_id=220099
Hrm, you gentoo users always know how to break perfectly
working stuff.
About the suspend/resume problem: i've been looking at the
log, but i would prefer a more transparant log. I'll get you
a better patch tomorrow, which will show me a fully
initialised and running overlay.
About the black screen, are you talking actual mode or are
you talk black overlay?
Nothing here has anything to do with the "unhandled ram
type" error message.
Logged In: YES
user_id=1206973
Yes we know how,
I mean, if I change -O flags the RGB bug see different.
Black does not mean true black, but extramely dark (show
less "colors"(for example only Y from YUV).
I try find where and why the flags effect.
Logged In: YES
user_id=220099
So, this all seems to be a gcc optimisation issue then.
So it's ok after suspend/resume without funky optimisation
or is it still broken then, but in a slightly different manner?
If broken in different ways, i'd prefer taking on the
normally optimised breakage first.
Print Xv registers after a client first runs PutImage