Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Sat, Sep 23, 2006 at 10:53:56AM +0200, Attilio Fiandrotti wrote:
> Sven Luther wrote:
> >On Fri, Sep 22, 2006 at 10:40:34PM +0200, Frans Pop wrote:
> >>On Friday 22 September 2006 21:32, Sven Luther wrote:
> >>>We did never implement the thingy which disables the acceleration in
> >>>the directfbrc, right ?
> >>I've committed a patch now that always disables it for ppc.
> I belive disabling hw acceleration on PPC machines is a good choice, as
> we're interested in stability, not performance, and i also belive
> performance drop won't be even detectable in the case of a simple DFB
> application like our GTK frontend.
> By the way, i think disabling HW acceleration unconditionally for *every
> architecture* wouldn't be a bad idea, this could save us many a headache
> in the future.
I would enable a 'secret' debconf switch to enable hw accel, be it only for
> 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 ?
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 ?
> 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.