Sven Luther wrote:
</snip>
That's a good idea.
I also wonder if kernels shipped in d-i include or not modules for
hardware specific framebuffer devices, or generic drivers (like vesafb
on i386) only.
CONFIG_FB_CIRRUS=m
CONFIG_FB_OF=y
CONFIG_FB_CONTROL=y
CONFIG_FB_PLATINUM=y
CONFIG_FB_VALKYRIE=y
CONFIG_FB_CT65550=y
CONFIG_FB_IMSTT=y
CONFIG_FB_S1D13XXX=m
CONFIG_FB_NVIDIA=y
CONFIG_FB_MATROX=y
CONFIG_FB_MATROX_MILLENIUM=y
CONFIG_FB_MATROX_MYSTIQUE=y
CONFIG_FB_MATROX_G=y
CONFIG_FB_RADEON=y
CONFIG_FB_ATY128=y
CONFIG_FB_ATY=y
CONFIG_FB_SAVAGE=m
CONFIG_FB_SIS=y
CONFIG_FB_SIS_300=y
CONFIG_FB_SIS_315=y
CONFIG_FB_NEOMAGIC=m
CONFIG_FB_KYRO=m
CONFIG_FB_3DFX=y
CONFIG_FB_TRIDENT=m
So, on powerpc, we have : offb, controlfb, platinumfb, valkyriefb, imsttfb,
nvidiafb, matroxfb, radeonfb, aty128fb, atyfb, sisfb and 3dfxfb builtin.
cirrusfb, s1d13xxxfb (no idea what this one is), savagefb, neomagixfb, kyrofb
and tridentfb as modules.
looking at DFB's supported-hardware page
http://www.directfb.org/index.php?path=Main%2FSupport%2FGraphics
i can see some of those fb modules may allow DFB to run in hw
accelerated mode, but for many of them no functionality tests on PPC
hardware were ever peformed, so i guess disabling HW acceleration tout
court for PPC was indeed the right choice for safeness.
Speaking generically, i don't know how much is safe having DFB running
in accelerated mode using fb module "X" on architecture "Y".
An extensive set of tests to detect bad X,Y couples looks dificlut to be
performed, so to be sure the end-user never runs in a bad X,Y situation,
a safe choice would be disabling hw acceleration by defalut, for all
architectures.
Sven, looking at the PNG you posted it looks like the trashed banner
colours issue we experienced at extremadura is gone, does also the
cursor is displayed correctly (to grab both screen and pointer at DFB's
level, you can press the "PrtSc" key in the case your PPC has one) ?
The pegasos uses a normal PC keyboard, so i should have this key, but in
any
case, indeed both these issues are gone, and the two new ones i mentioned
are
there (the list selection dissapearance thingy). Do you see that on x86
also ?
Yes, i saw the vanished lines in your screenshots and i belive this may
be #385026, which is GTKDFB 2.8.x related and affects all HW platforms.
As Frans said, this is a quite annoying bug and i'll try to see if i can
fix it in GTKDFB 2.8.20 with a small patch (but i'm not sure it's going
to be an easy fix).
Is it fixed in 2.10.x ?
Basing on my past tests with different GTK+ 2.10 versions, it is.
Also, about the console font corruption with radeonfb, i would be
interested
in feedback of if it is a powerpc only issue, or ppc stuff ?
No idea, i on no radeon boards :(
Someone else ?
Any chanche to test if disabling HW acceleration also makes the g-i
usable on machines equippped with ATI or NVIDIA graphic boards ( where
atyfb and nvidiafb modules would be used in the case HW acceleration was
not forced off ) ?
Nope, but as soon as the fixed rootskel-gtk is uploaded, we can issue a
call
for testers on debian-powerpc, using the daily builds.
A round of PPC tests would be useful, especially it happens to find
owners of ATI or NVIDIA boards.
ati being mach64 (rage) and aty (rage 128) here.
Not sure if we ever had a success with g-i on oldworld, so it is less
important, and my prep box has a sis and a matrox, but g-i is too big to boot
on it. I do have a spare matox millenium i could plug in the pegasos, and just
got a xgi volari v3xt. Will test with them. nvidia is evil and should be
boycotted anyway :)
On my PReP 7043/140 box i experienced success in running unaccelerated
DFB applications with a Matrox card some times ago, but i never managed
to test GTKDFB applications.
cheers
Attilio
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
