[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used



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



Reply to: