Bug#342053: [directfb-users] Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
Denis Oliver Kropp wrote: Attilio Fiandrotti schrieb: Rick Thomas wrote: (*) Direct/Modules: suppress module 'linux_input' (*) Direct/Thread: Running 'Keyboard Input' (INPUT, 1104) () *** UNIMPLEMENTED [fusion_reactor_set_lock] *** [../../../ lib/fusion/reactor.c:853] (*) DirectFB/Input: Keyboard 0.9 (convergence integrated media GmBH) (*) Direct/Thread: Running 'PS/2 Input' (INPUT, 1105) (*) DirectFB/Input: IMPS/2 Mouse 1.0 (Convergence GmBH) (*) DirectFB/Graphics: ATI Radeon 7500 (5157) 1.0 (Claudio Ciccani) (*) DirectFB/Graphics: Acceleration disabled (by 'no-hardware') (!) DirectFB/FBDev: No supported modes found in /etc/fb.modes and current mode not supported! (!) DirectFB/FBDev: Current mode's pixelformat: rgba 8/0, 8/0, 8/0, 0/0 (8bit) (!) DirectFB/Core/layers: Failed to initialize layer 0! -- Initialization error! (!) DirectFB/Core: Could not initialize 'layers' core! -- Initialization error! (#) DirectFBError [gdk_display_open: DirectFBCreate]: Initialization error! (debconf:1099): Gtk-Warning **: cannot open display: thanks for the detailed report, this is not a crash, but an error message from DFB because of unsupported pixelformat: directfb people, is there a way to fix this ? I wonder why the 8bit indexed format above is not accepted. Maybe because of other mismatching values. The output of fbset -i would help. fbset exixsts as an udeb [1]: rick, you could boot textual, pull the ppc version in the d-i using wget, unpack it with anna and run it. Maybe fbset should become part of the g-i ? Attilio [1] http://packages.debian.org/unstable/debian-installer/fbset-udeb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: [directfb-users] Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
Attilio Fiandrotti schrieb: Rick Thomas wrote: (*) Direct/Modules: suppress module 'linux_input' (*) Direct/Thread: Running 'Keyboard Input' (INPUT, 1104) () *** UNIMPLEMENTED [fusion_reactor_set_lock] *** [../../../ lib/fusion/reactor.c:853] (*) DirectFB/Input: Keyboard 0.9 (convergence integrated media GmBH) (*) Direct/Thread: Running 'PS/2 Input' (INPUT, 1105) (*) DirectFB/Input: IMPS/2 Mouse 1.0 (Convergence GmBH) (*) DirectFB/Graphics: ATI Radeon 7500 (5157) 1.0 (Claudio Ciccani) (*) DirectFB/Graphics: Acceleration disabled (by 'no-hardware') (!) DirectFB/FBDev: No supported modes found in /etc/fb.modes and current mode not supported! (!) DirectFB/FBDev: Current mode's pixelformat: rgba 8/0, 8/0, 8/0, 0/0 (8bit) (!) DirectFB/Core/layers: Failed to initialize layer 0! -- Initialization error! (!) DirectFB/Core: Could not initialize 'layers' core! -- Initialization error! (#) DirectFBError [gdk_display_open: DirectFBCreate]: Initialization error! (debconf:1099): Gtk-Warning **: cannot open display: thanks for the detailed report, this is not a crash, but an error message from DFB because of unsupported pixelformat: directfb people, is there a way to fix this ? I wonder why the 8bit indexed format above is not accepted. Maybe because of other mismatching values. The output of fbset -i would help. -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: [directfb-users] Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Oct 3, 2006, at 9:25 AM, Attilio Fiandrotti wrote: fbset exists as an udeb [1]: rick, you could boot textual, pull the ppc version in the d-i using wget, unpack it with anna and run it. Maybe fbset should become part of the g-i ? Attilio [1] http://packages.debian.org/unstable/debian-installer/fbset-udeb I'm with you up through wget. But I've never met anna, though I'm sure she's a very nice person! (-; Either detailed instructions on how to do unpack a udeb with anna or a pointer to a manual that I can read will be necessary. Enjoy! Rick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Luther wrote: On Sat, Sep 23, 2006 at 11:35:28PM +0300, Eddy Petrişor wrote: On 23/09/06, Attilio Fiandrotti [EMAIL PROTECTED] wrote: 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 :( $ lspci | grep ATI :00:10.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] So, do you see the garbage in the console too ? Ah, but i suppose you don't use radeonfb, but vesafb, right ? I don't get to that point by default. - -- Regards, EddyP = Imagination is more important than knowledge A.Einstein -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFHBueY8Chqv3NRNoRAuD7AJ97xZURrSS6q+vDAcXGM+yTeKNCYQCfbR6Z gGf4cNkyZRTJjMdap15sxNQ= =DuFv -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Attilio Fiandrotti wrote: Eddy Petrişor wrote: On 25/09/06, Eddy Petrişor [EMAIL PROTECTED] wrote: Eddy, do you have the chance to test if forcing off DFB's HW acceleration makes g-i run on your Mac? At Sven's suggestion, I have ran the installer with disable-module=radeon in directfbrc. This worked (well, only if the linux_input module is deactivated, too). what if you delete the ll /usr/lib/directfb-0.9.25/gfxdrivers/ directory, remove disable-module=radeon from directfbrc and A) disable linux_input in directfbrc works (no-hardware is there, no USB mouse attached) B) leave linux_input enabled in directfbrc crashes (no-hardware is there, no USB mouse attached) - -- Regards, EddyP = Imagination is more important than knowledge A.Einstein -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFHBv8Y8Chqv3NRNoRAnSYAKCZHizwn+VZG83VqHMBpZrGnmtUegCgzkl9 64XxnI0Xaqjitj8f81R+cUI= =zOg8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
OK, I booted from the CD with install DEBIAN_FRONTEND=newt switched to the F2 console when the choose language screen came up. The hardware info you wanted is: ~# cat /proc/cpuinfo | grep motherboard Motherboard: PowerMac3,5 MacRISC2 MacRISC Power Macintosh ~# cat /proc/fb 0 ATI Radeon QW Then I did: ~# echo disable-module=linux_input /etc/directfbrc ~# export DEBIAN_FRONTEND=gtk ~# debian-installer It crashed when it tried to initialize the graphical installer messages read in part (manually typed in -- I don't have any way to cut-and-paste from the crashed machine...) (process:1076): INFO kbd-mode: setting console mode to Unicode (UTF-8) (*) DirectFB/Config: Parsing file '/etc/directfbrc' - DirectFB v0.9.25 - ... [ stuff snipped to save typing -- let me know if it's important - Rick] (*) Direct/Modules: suppress module 'linux_input' (*) Direct/Thread: Running 'Keyboard Input' (INPUT, 1104) () *** UNIMPLEMENTED [fusion_reactor_set_lock] *** [../../../ lib/fusion/reactor.c:853] (*) DirectFB/Input: Keyboard 0.9 (convergence integrated media GmBH) (*) Direct/Thread: Running 'PS/2 Input' (INPUT, 1105) (*) DirectFB/Input: IMPS/2 Mouse 1.0 (Convergence GmBH) (*) DirectFB/Graphics: ATI Radeon 7500 (5157) 1.0 (Claudio Ciccani) (*) DirectFB/Graphics: Acceleration disabled (by 'no-hardware') (!) DirectFB/FBDev: No supported modes found in /etc/fb.modes and current mode not supported! (!) DirectFB/FBDev: Current mode's pixelformat: rgba 8/0, 8/0, 8/0, 0/0 (8bit) (!) DirectFB/Core/layers: Failed to initialize layer 0! -- Initialization error! (!) DirectFB/Core: Could not initialize 'layers' core! -- Initialization error! (#) DirectFBError [gdk_display_open: DirectFBCreate]: Initialization error! (debconf:1099): Gtk-Warning **: cannot open display: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
OK, I booted from the CD with install DEBIAN_FRONTEND=newt switched to the F2 console when the choose language screen came up. Then I did: ~# echo disable-module=radeon /etc/directfbrc ~# echo no-hardware /etc/directfbrc ~# export DEBIAN_FRONTEND=gtk ~# debian-installer It crashed when it tried to initialize the graphical installer messages read in part (manually typed in -- I don't have any way to cut-and-paste from the crashed machine...) (process:1074): INFO kbd-mode: setting console mode to Unicode (UTF-8) (*) DirectFB/Config: Parsing file '/etc/directfbrc' - DirectFB v0.9.25 - ... [ stuff snipped to save typing -- let me know if it's important - Rick] (*) Direct/Thread: Running 'VT Switcher' (CRITICAL, 1101) (*) Direct/Thread: Running 'Linux Input' (INPUT, 1102) () *** UNIMPLEMENTED [fusion_reactor_set_lock] *** [../../../ lib/fusion/reactor.c:853] ... [more stuff snipped -Rick] (*) Direct/Modules: supress module 'radeon' (*) DirectFB/Graphics: Generic Software Rasterizer 0.6 (convergence integrated media GmBH) (!) DirectFB/FBDev: No supported modes found in /etc/fb.modes and current mode not supported! (!) DirectFB/FBDev: Current mode's pixelformat: rgba 8/0, 8/0, 8/0, 0/0 (8bit) (!) DirectFB/Core/layers: Failed to initialize layer 0! -- Initialization error! (!) DirectFB/Core: Could not initialize 'layers' core! -- Initialization error! (#) DirectFBError [gdk_display_open: DirectFBCreate]: Initialization error! (debconf:1097): Gtk-Warning **: cannot open display: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Sep 27, 2006, at 7:03 PM, Rick Thomas wrote: (!) DirectFB/FBDev: No supported modes found in /etc/fb.modes and current mode not supported! (!) DirectFB/FBDev: Current mode's pixelformat: rgba 8/0, 8/0, 8/0, 0/0 (8bit) For what it's worth, there is no file /etc/fb.modes in the initrc... Does that matter? Enjoy! Rick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
Rick Thomas wrote: OK, I booted from the CD with install DEBIAN_FRONTEND=newt switched to the F2 console when the choose language screen came up. The hardware info you wanted is: ~# cat /proc/cpuinfo | grep motherboard Motherboard: PowerMac3,5 MacRISC2 MacRISC Power Macintosh ~# cat /proc/fb 0 ATI Radeon QW Then I did: ~# echo disable-module=linux_input /etc/directfbrc ~# export DEBIAN_FRONTEND=gtk ~# debian-installer It crashed when it tried to initialize the graphical installer messages read in part (manually typed in -- I don't have any way to cut-and-paste from the crashed machine...) (process:1076): INFO kbd-mode: setting console mode to Unicode (UTF-8) (*) DirectFB/Config: Parsing file '/etc/directfbrc' - DirectFB v0.9.25 - ... [ stuff snipped to save typing -- let me know if it's important - Rick] (*) Direct/Modules: suppress module 'linux_input' (*) Direct/Thread: Running 'Keyboard Input' (INPUT, 1104) () *** UNIMPLEMENTED [fusion_reactor_set_lock] *** [../../../ lib/fusion/reactor.c:853] (*) DirectFB/Input: Keyboard 0.9 (convergence integrated media GmBH) (*) Direct/Thread: Running 'PS/2 Input' (INPUT, 1105) (*) DirectFB/Input: IMPS/2 Mouse 1.0 (Convergence GmBH) (*) DirectFB/Graphics: ATI Radeon 7500 (5157) 1.0 (Claudio Ciccani) (*) DirectFB/Graphics: Acceleration disabled (by 'no-hardware') (!) DirectFB/FBDev: No supported modes found in /etc/fb.modes and current mode not supported! (!) DirectFB/FBDev: Current mode's pixelformat: rgba 8/0, 8/0, 8/0, 0/0 (8bit) (!) DirectFB/Core/layers: Failed to initialize layer 0! -- Initialization error! (!) DirectFB/Core: Could not initialize 'layers' core! -- Initialization error! (#) DirectFBError [gdk_display_open: DirectFBCreate]: Initialization error! (debconf:1099): Gtk-Warning **: cannot open display: thanks for the detailed report, this is not a crash, but an error message from DFB because of unsupported pixelformat: directfb people, is there a way to fix this ? thanks Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On 25/09/06, Eddy Petrişor [EMAIL PROTECTED] wrote: A round of PPC tests would be useful, especially it happens to find owners of ATI or NVIDIA boards. Got one. Eddy, do you have the chance to test if forcing off DFB's HW acceleration makes g-i run on your Mac? I did, (Sven knows), it didn't work for me. I added by hand in the directfbrc file the option. Neither did video=ofonly At Sven's suggestion, I have ran the installer with disable-module=radeon in directfbrc. This worked (well, only if the linux_input module is deactivated, too). -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
Eddy Petrişor wrote: On 25/09/06, Eddy Petrişor [EMAIL PROTECTED] wrote: A round of PPC tests would be useful, especially it happens to find owners of ATI or NVIDIA boards. Got one. Eddy, do you have the chance to test if forcing off DFB's HW acceleration makes g-i run on your Mac? I did, (Sven knows), it didn't work for me. I added by hand in the directfbrc file the option. Neither did video=ofonly At Sven's suggestion, I have ran the installer with disable-module=radeon in directfbrc. This worked (well, only if the linux_input module is deactivated, too). what if you delete the ll /usr/lib/directfb-0.9.25/gfxdrivers/ directory, remove disable-module=radeon from directfbrc and A) disable linux_input in directfbrc B) leave linux_input enabled in directfbrc thanks Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Sep 24, 2006, at 5:52 AM, Sven Luther wrote: On Sun, Sep 24, 2006 at 04:17:58AM -0400, Rick Thomas wrote: On Sep 23, 2006, at 6:13 AM, Sven Luther wrote: 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 ? I might have a NewWorld Mac with a radeon board... If so, it's at work, so checking will have to wait til Monday. I'll let you know. Yes, please. Do you remember the model exactly ? OK. I have a G4 PowerMac with :00:10.0 VGA compatible controller: ATI Technologies Inc Radeon RV200 QW [Radeon 7500] Will that be useful? [EMAIL PROTECTED]:~$ cat /proc/cpuinfo processor : 0 cpu : 7450, altivec supported clock : 733.31MHz revision: 0.1 (pvr 8000 0201) bogomips: 66.30 timebase: 33217233 platform: PowerMac machine : PowerMac3,5 motherboard : PowerMac3,5 MacRISC2 MacRISC Power Macintosh detected as : 69 (PowerMac G4 Silver) pmac flags : 0010 L2 cache: 256K unified pmac-generation : NewWorld Enjoy! Rick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Tue, Sep 26, 2006 at 04:01:15PM -0400, Rick Thomas wrote: On Sep 24, 2006, at 5:52 AM, Sven Luther wrote: On Sun, Sep 24, 2006 at 04:17:58AM -0400, Rick Thomas wrote: On Sep 23, 2006, at 6:13 AM, Sven Luther wrote: 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 ? I might have a NewWorld Mac with a radeon board... If so, it's at work, so checking will have to wait til Monday. I'll let you know. Yes, please. Do you remember the model exactly ? OK. I have a G4 PowerMac with :00:10.0 VGA compatible controller: ATI Technologies Inc Radeon RV200 QW [Radeon 7500] Should work flawlessly with the current daily-builds. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Tue, Sep 26, 2006 at 04:48:51PM -0400, Rick Thomas wrote: On Sep 26, 2006, at 4:04 PM, Sven Luther wrote: On Tue, Sep 26, 2006 at 04:01:15PM -0400, Rick Thomas wrote: OK. I have a G4 PowerMac with :00:10.0 VGA compatible controller: ATI Technologies Inc Radeon RV200 QW [Radeon 7500] Should work flawlessly with the current daily-builds. Friendly, Sven Luther Hmmm Maybe I'm not getting the current daily-build? On Sep 24, 2006, at 5:34 AM, Frans Pop wrote: On Sunday 24 September 2006 10:17, Rick Thomas wrote: Is there an iso I can burn with the necessary stuff on it? I'm not set up to do netbooting at this moment. There is only an iso. Look for gtk-miniiso under powerpc/powerpc64: http://people.debian.org/~wouter/d-i/powerpc/daily/ So I went there and found Index of /~wouter/d-i/powerpc/daily/powerpc/gtk-miniiso NameLast modified Size Description Parent Directory18-Sep-2006 22:16 - initrd.gz 25-Sep-2006 22:34 9.7M mini.iso25-Sep-2006 22:45 15.3M vmlinux 25-Sep-2006 22:45 3.8M vmlinuz-chrp.initrd 25-Sep-2006 22:56 11.1M Apache/1.3.33 Server at people.debian.org Port 80 and from which I downloaded and burned the mini.iso I booted from the CD and got repeating crashes when it tried to initialize the graphical installer messages read in part (manually typed in -- I don't have any way to cut-and-paste from the crashed machine...) - DirectFB v0.9.25 - ... () *** UNIMPLEMENTED [fusion_reactor_set_lock] *** [../../../ lib/fusion/reactor.c:853] ... (*) DirectFB/Graphics: ATI Radeon 7500 (5157) 1.0 (Claudio Ciccani) (*) DirectFB/Graphics: Acceleration disabled (by 'no-hardware') (!) DirectFB/FBDev: No supported modes found in /etc/fb.modes and current mode not supported! (!) DirectFB/FBDev: Current mode's pixelformat: rgba 8/0, 8/0, 8/0, 0/0 (8bit) (!) DirectFB/Core/layers: Failed to initialize layer 0! -- Initialization error! (!) DirectFB/Core: Could not initialize 'layers' core! -- Initialization error! (#) DirectFBError [gdk_display_open: DirectFBCreate]: Initialization error! (debconf:1609): Gtk-Warning **: cannot open display: (process:1641): INFO: kbd-mode: setting console mode to Unicode (UTF-8) (*) DirectFB/Config: Parsing config file '/etc/directfbrc' Is there a different mini.iso ? Oh, well. I said should, but i guess i am wrong on this one. Attilio, this is another data point for this, can you try the tricks eddy tried, and reported success for ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Sep 26, 2006, at 4:04 PM, Sven Luther wrote: On Tue, Sep 26, 2006 at 04:01:15PM -0400, Rick Thomas wrote: OK. I have a G4 PowerMac with :00:10.0 VGA compatible controller: ATI Technologies Inc Radeon RV200 QW [Radeon 7500] Should work flawlessly with the current daily-builds. Friendly, Sven Luther Hmmm Maybe I'm not getting the current daily-build? On Sep 24, 2006, at 5:34 AM, Frans Pop wrote: On Sunday 24 September 2006 10:17, Rick Thomas wrote: Is there an iso I can burn with the necessary stuff on it? I'm not set up to do netbooting at this moment. There is only an iso. Look for gtk-miniiso under powerpc/powerpc64: http://people.debian.org/~wouter/d-i/powerpc/daily/ So I went there and found Index of /~wouter/d-i/powerpc/daily/powerpc/gtk-miniiso NameLast modified Size Description Parent Directory18-Sep-2006 22:16 - initrd.gz 25-Sep-2006 22:34 9.7M mini.iso25-Sep-2006 22:45 15.3M vmlinux 25-Sep-2006 22:45 3.8M vmlinuz-chrp.initrd 25-Sep-2006 22:56 11.1M Apache/1.3.33 Server at people.debian.org Port 80 and from which I downloaded and burned the mini.iso I booted from the CD and got repeating crashes when it tried to initialize the graphical installer messages read in part (manually typed in -- I don't have any way to cut-and-paste from the crashed machine...) - DirectFB v0.9.25 - ... () *** UNIMPLEMENTED [fusion_reactor_set_lock] *** [../../../ lib/fusion/reactor.c:853] ... (*) DirectFB/Graphics: ATI Radeon 7500 (5157) 1.0 (Claudio Ciccani) (*) DirectFB/Graphics: Acceleration disabled (by 'no-hardware') (!) DirectFB/FBDev: No supported modes found in /etc/fb.modes and current mode not supported! (!) DirectFB/FBDev: Current mode's pixelformat: rgba 8/0, 8/0, 8/0, 0/0 (8bit) (!) DirectFB/Core/layers: Failed to initialize layer 0! -- Initialization error! (!) DirectFB/Core: Could not initialize 'layers' core! -- Initialization error! (#) DirectFBError [gdk_display_open: DirectFBCreate]: Initialization error! (debconf:1609): Gtk-Warning **: cannot open display: (process:1641): INFO: kbd-mode: setting console mode to Unicode (UTF-8) (*) DirectFB/Config: Parsing config file '/etc/directfbrc' Is there a different mini.iso ? Rick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On 23/09/06, Attilio Fiandrotti [EMAIL PROTECTED] wrote: Eddy Petrişor wrote: snip/ A round of PPC tests would be useful, especially it happens to find owners of ATI or NVIDIA boards. Got one. Eddy, do you have the chance to test if forcing off DFB's HW acceleration makes g-i run on your Mac? I did, (Sven knows), it didn't work for me. I added by hand in the directfbrc file the option. Neither did video=ofonly -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Sep 23, 2006, at 6:13 AM, Sven Luther wrote: 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 ? I might have a NewWorld Mac with a radeon board... If so, it's at work, so checking will have to wait til Monday. I'll let you know. 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 :) If you have a kernel that will boot using BootX on an OldWorld beige G3 PowerMac, I can give it a try. Is there an iso I can burn with the necessary stuff on it? I'm not set up to do netbooting at this moment. Enjoy! Rick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Sunday 24 September 2006 10:17, Rick Thomas wrote: Is there an iso I can burn with the necessary stuff on it? I'm not set up to do netbooting at this moment. There is only an iso. Look for gtk-miniiso under powerpc/powerpc64: http://people.debian.org/~wouter/d-i/powerpc/daily/ pgpcrSyEwwznB.pgp Description: PGP signature
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Sun, Sep 24, 2006 at 04:17:58AM -0400, Rick Thomas wrote: On Sep 23, 2006, at 6:13 AM, Sven Luther wrote: 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 ? I might have a NewWorld Mac with a radeon board... If so, it's at work, so checking will have to wait til Monday. I'll let you know. Yes, please. Do you remember the model exactly ? Also, i am interested in a x86 test using radeonfb and not vesafb. 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 :) If you have a kernel that will boot using BootX on an OldWorld beige G3 PowerMac, I can give it a try. The same should work, but not sure. Is there an iso I can burn with the necessary stuff on it? I'm not set up to do netbooting at this moment. The daily-builds produce a mini-iso, which should do just fine. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
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. Thanks, 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. 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) ? 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 ) ? thanks Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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. Thanks, 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 testing. 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. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Sat, Sep 23, 2006 at 12:07:45PM +0200, Attilio Fiandrotti wrote: Sven Luther wrote: snip/ 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 testing. 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. 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 ? 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 :) Friendly, Sven Luther cheers Attilio --- Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. Aucun virus connu a ce jour par nos services n'a ete detecte. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
Sven Luther wrote: snip/ 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 testing. 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. 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). 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 :( 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. cheers Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
Sven Luther wrote: snip/ 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. This would be a reason to go with gtk 2.10.x, those packages are built and uploaded to experimental, right ? So we could do a second build using the 2.10 stuff ? Yes, GDKDFB backend found in 2.10.4 is more stable and clean than one found in 2.8.20, which is an old backported DFB backend some months old. If we can fix this issue[1] before GTK 2.10.5 is out, we may prefer switching to GTK 2.10.5 later, otherwise we may need to backport current GDKDFB backend from 2.10.4 to 2.8.20 for immediate use. 2.10.x, compared to 2.8.x, offers nothing we really need, but of course avoiding dirty backports wouldn't be bad! [1] http://lists.debian.org/debian-boot/2006/09/msg00995.html cheers Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Sat, Sep 23, 2006 at 12:45:10PM +0200, Attilio Fiandrotti wrote: 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. Understood. 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. This would be a reason to go with gtk 2.10.x, those packages are built and uploaded to experimental, right ? So we could do a second build using the 2.10 stuff ? 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. The problem on PReP is getting it to load the huge g-i initrd, not really running apps afterward, altough this would indicate there is a serious problem with matroxfb maybe. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Sat, Sep 23, 2006 at 01:56:40PM +0200, Attilio Fiandrotti wrote: Sven Luther wrote: snip/ 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. This would be a reason to go with gtk 2.10.x, those packages are built and uploaded to experimental, right ? So we could do a second build using the 2.10 stuff ? Yes, GDKDFB backend found in 2.10.4 is more stable and clean than one found in 2.8.20, which is an old backported DFB backend some months old. If we can fix this issue[1] before GTK 2.10.5 is out, we may prefer switching to GTK 2.10.5 later, otherwise we may need to backport current GDKDFB backend from 2.10.4 to 2.8.20 for immediate use. 2.10.x, compared to 2.8.x, offers nothing we really need, but of course avoiding dirty backports wouldn't be bad! [1] http://lists.debian.org/debian-boot/2006/09/msg00995.html That would be the BOOM issue, right, in my experience, from my X hacking days, is that stuff like this happens when the refresh is no more happening, and when one is using a software cursor, which is still working or something. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
Mmm, nogo on the xgi card, since 2.6.16/17 have the sisfb framebuffer device not builtin, but modular. Is there some place where we can do some kind of framebuffer device detection, and loading of the appropriate modules ? Where is it done for vesafb, which if i am not wrong, is modular on x86 ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Saturday 23 September 2006 16:17, Sven Luther wrote: Is there some place where we can do some kind of framebuffer device detection, and loading of the appropriate modules ? Where is it done for vesafb, which if i am not wrong, is modular on x86 ? That should also be an issue for the newt frontend then... See: rootskel/src/lib/debian-installer-startup.d/S40framebuffer-module-linux-* pgpYtx02UvvXE.pgp Description: PGP signature
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Saturday 23 September 2006 12:45, Attilio Fiandrotti wrote: 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. On the other hand, that does not really help directfb development... But I've now changed rootskel-gtk so that no-hardware is set by default but hardware acceleration can be enabled with directfb/hw-accel=true. pgpaA3YOPenrS.pgp Description: PGP signature
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Sat, Sep 23, 2006 at 05:09:15PM +0200, Frans Pop wrote: On Saturday 23 September 2006 16:17, Sven Luther wrote: Is there some place where we can do some kind of framebuffer device detection, and loading of the appropriate modules ? Where is it done for vesafb, which if i am not wrong, is modular on x86 ? That should also be an issue for the newt frontend then... Indeed. Also, given the way initramfs is initialized very early, i have had some thoughts of moving all the builtin framebuffer devices into the initramfs, and then have some kind of kernel fbdev hook or something which will load it. Need to find time to investigate this. See: rootskel/src/lib/debian-installer-startup.d/S40framebuffer-module-linux-* Cool, Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
Frans Pop wrote: On Saturday 23 September 2006 12:45, Attilio Fiandrotti wrote: 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. On the other hand, that does not really help directfb development... But I've now changed rootskel-gtk so that no-hardware is set by default but hardware acceleration can be enabled with directfb/hw-accel=true. IMHO i still think this was a wise move, since it solves a wide range of potential problems and the boot time option you introduced still allows people who want to debug DFB's hw acceleration to do it. The d-i ISO itself could become a useful tool for directfb developers to test DFB's HW accelerated functionalities on a wide range of different HW configurations. cheers Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Sat, Sep 23, 2006 at 12:45:10PM +0200, Attilio Fiandrotti wrote: looking at DFB's supported-hardware page http://www.directfb.org/index.php?path=Main%2FSupport%2FGraphics Well, ... I did some try with my xgi card, and even though i disabled hardware acceleration, this is a nogo. I ended up in a messed up text terminal (with black blocks and â chars for the box borders and shadow). So, it is clear that directfb needs not only the per-card drivers for acceleration, but also for normal usage. That said, i couldn't find any kind of directfb log or something, so maybe the above guess was bad, and something else funny happened, since that was with a 2.6.18 kernel. Friendly, Sven Luther
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On 23/09/06, Attilio Fiandrotti [EMAIL PROTECTED] wrote: 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 :( $ lspci | grep ATI :00:10.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] 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. Got one. -- Regards, EddyP = Imagination is more important than knowledge A.Einstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Sat, Sep 23, 2006 at 10:13:10PM +0200, Sven Luther wrote: On Sat, Sep 23, 2006 at 12:45:10PM +0200, Attilio Fiandrotti wrote: looking at DFB's supported-hardware page http://www.directfb.org/index.php?path=Main%2FSupport%2FGraphics Well, ... I did some try with my xgi card, and even though i disabled hardware acceleration, this is a nogo. I ended up in a messed up text terminal (with black blocks and â chars for the box borders and shadow). So, it is clear that directfb needs not only the per-card drivers for acceleration, but also for normal usage. That said, i couldn't find any kind of directfb log or something, so maybe the above guess was bad, and something else funny happened, since that was with a 2.6.18 kernel. DirectFB only supports : FB_ACCEL_SIS_GLAMOUR_2 FB_ACCEL_SIS_XABRE While my card is : FB_ACCEL_XGI_VOLARI_V But that is only for accel. I didn't find where the pci ids are checked, but maybe this is related to the sis-xgi vendor id change. Friendly, Sven Luther
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Sat, Sep 23, 2006 at 11:35:28PM +0300, Eddy Petrişor wrote: On 23/09/06, Attilio Fiandrotti [EMAIL PROTECTED] wrote: 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 :( $ lspci | grep ATI :00:10.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] So, do you see the garbage in the console too ? Ah, but i suppose you don't use radeonfb, but vesafb, right ? Friendly, Sven Luther
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
Sven Luther wrote: On Sat, Sep 23, 2006 at 10:13:10PM +0200, Sven Luther wrote: On Sat, Sep 23, 2006 at 12:45:10PM +0200, Attilio Fiandrotti wrote: looking at DFB's supported-hardware page http://www.directfb.org/index.php?path=Main%2FSupport%2FGraphics Well, ... I did some try with my xgi card, and even though i disabled hardware acceleration, this is a nogo. I ended up in a messed up text terminal (with black blocks and â chars for the box borders and shadow). So, it is clear that directfb needs not only the per-card drivers for acceleration, but also for normal usage. That said, i couldn't find any kind of directfb log or something, so maybe the above guess was bad, and something else funny happened, since that was with a 2.6.18 kernel. DirectFB only supports : FB_ACCEL_SIS_GLAMOUR_2 FB_ACCEL_SIS_XABRE While my card is : FB_ACCEL_XGI_VOLARI_V But that is only for accel. I didn't find where the pci ids are checked, but maybe this is related to the sis-xgi vendor id change. IIUC, you loaded the per-card (SiS) fb device, but DFB ran unaccelerated because it didn't recognize the board and furthermore acceleration was forced off, right? In this case i wonder where the bug is, in the framebuffer device or in DFB card-indipendent code? Should we start x-posting on directfb-devel to get an expert help? Attilio
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
Sven Luther wrote: On Sat, Sep 23, 2006 at 12:45:10PM +0200, Attilio Fiandrotti wrote: looking at DFB's supported-hardware page http://www.directfb.org/index.php?path=Main%2FSupport%2FGraphics Well, ... I did some try with my xgi card, and even though i disabled hardware acceleration, this is a nogo. I ended up in a messed up text terminal (with black blocks and â chars for the box borders and shadow). So, it is clear that directfb needs not only the per-card drivers for acceleration, but also for normal usage. You're talking about per-card framebuffer devices, not per-card DFB gfxdrivers, right? On i386 the vesafb device can be used in place of card-specific fb devices and DFB will run unaccelerated on top of it. Does a device driver equivalent to vesafb exists for PPCs? That said, i couldn't find any kind of directfb log or something, so maybe the above guess was bad, and something else funny happened, since that was with a 2.6.18 kernel. Usually DFB produces some debug output on VT1, can you get any info there? Attilio
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
Eddy Petrişor wrote: snip/ A round of PPC tests would be useful, especially it happens to find owners of ATI or NVIDIA boards. Got one. Eddy, do you have the chance to test if forcing off DFB's HW acceleration makes g-i run on your Mac?
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Sat, Sep 23, 2006 at 10:50:37PM +0200, Attilio Fiandrotti wrote: IIUC, you loaded the per-card (SiS) fb device, but DFB ran unaccelerated because it didn't recognize the board and furthermore acceleration was forced off, right? No, i didn't even get into gtk-di, i ended up in a somewhat messed up text di, i don't know why. Let me retry this image with the radeon. In this case i wonder where the bug is, in the framebuffer device or in DFB card-indipendent code? Should we start x-posting on directfb-devel to get an expert help? Yes, this would be nice. Maybe you can introduce the problem, and i give a full summary of what i have experienced thus far ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Sat, Sep 23, 2006 at 10:46:05PM +0200, Attilio Fiandrotti wrote: Sven Luther wrote: On Sat, Sep 23, 2006 at 12:45:10PM +0200, Attilio Fiandrotti wrote: looking at DFB's supported-hardware page http://www.directfb.org/index.php?path=Main%2FSupport%2FGraphics Well, ... I did some try with my xgi card, and even though i disabled hardware acceleration, this is a nogo. I ended up in a messed up text terminal (with black blocks and â chars for the box borders and shadow). So, it is clear that directfb needs not only the per-card drivers for acceleration, but also for normal usage. You're talking about per-card framebuffer devices, not per-card DFB gfxdrivers, right? On i386 the vesafb device can be used in place of card-specific fb devices and DFB will run unaccelerated on top of it. Does a device driver equivalent to vesafb exists for PPCs? Forget it, there is something clearly wrong in my 2.6.18 based gtk-di build, even the radeon has problems, so i probably did some error in the build. Will investigate tomorrow. Friendly, Sven Luther
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
Sven Luther wrote: On Thu, Sep 21, 2006 at 03:32:28PM +0200, Frans Pop wrote: severity 342053 important thanks Lowering the severity of this bug to important. This issue is the main reason that g-i is only provided as experimental mini.iso for powerpc. However, that does not make RC for the package as a whole. Notice: Do we have a proof that by disabling acceleration, the issue goes away ? I remember in extremadura that by booting the system by hand into text mode and then launching the graphical mode made it work, so i am not sure that we have only this as issue, not sure. Last times the g-i was tested on PPC, it turned tout that Known good : radeonfb, vesafb (or whatever x86 uses). Known bad : atyfb, nvidiafb when acceleration was enabled. But that was with GTKDFB 2.0.9 and DFB 0.9.22, while now we have DFB 0.9.25 and GTK 2.8.20 and many bugs got fixed. This is the most serious bug affecting g-i on PPC, and i wasn't able to fix it because i have no PPC HW. Sven, do you think can give the PPC g-i a try? i will help you on debugging it as much as i can. Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Fri, Sep 22, 2006 at 09:37:28AM +0200, Attilio Fiandrotti wrote: Sven Luther wrote: On Thu, Sep 21, 2006 at 03:32:28PM +0200, Frans Pop wrote: severity 342053 important thanks Lowering the severity of this bug to important. This issue is the main reason that g-i is only provided as experimental mini.iso for powerpc. However, that does not make RC for the package as a whole. Notice: Do we have a proof that by disabling acceleration, the issue goes away ? I remember in extremadura that by booting the system by hand into text mode and then launching the graphical mode made it work, so i am not sure that we have only this as issue, not sure. Last times the g-i was tested on PPC, it turned tout that Known good : radeonfb, vesafb (or whatever x86 uses). vesafb is not built on powerpc, and the laptop we had in extremadura used a radeon chipset, altough of the R300 variety. Known bad : atyfb, nvidiafb when acceleration was enabled. But that was with GTKDFB 2.0.9 and DFB 0.9.22, while now we have DFB 0.9.25 and GTK 2.8.20 and many bugs got fixed. And it will be better with gtk 2.10.x even, right ? This is the most serious bug affecting g-i on PPC, and i wasn't able to fix it because i have no PPC HW. Yes, i will. Need to build a netboot g-i image and will test that on my pegasos with the radon 9250 board. Sven, do you think can give the PPC g-i a try? i will help you on debugging it as much as i can. Indeed, that is my intentions, a first test today, and more over the week-end. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
Sven Luther wrote: snip/ Last times the g-i was tested on PPC, it turned tout that Known good : radeonfb, vesafb (or whatever x86 uses). vesafb is not built on powerpc, and the laptop we had in extremadura used a radeon chipset, altough of the R300 variety. isn't fbonly the PPC equivalent to vesafb on i386? I know claudio ciccani worked a lot on DFB's Radeon driver recently, so things may have been fixed in DFB 0.9.25. Known bad : atyfb, nvidiafb when acceleration was enabled. But that was with GTKDFB 2.0.9 and DFB 0.9.22, while now we have DFB 0.9.25 and GTK 2.8.20 and many bugs got fixed. And it will be better with gtk 2.10.x even, right ? On i386 this proved to be true, but i cannot speak for other archs as i never experimented anything personally. This is the most serious bug affecting g-i on PPC, and i wasn't able to fix it because i have no PPC HW. Yes, i will. Need to build a netboot g-i image and will test that on my pegasos with the radon 9250 board. If you experience crashes, you may want to run the d-i in a chroot cage, like explained in this [1] wiki page. Sven, do you think can give the PPC g-i a try? i will help you on debugging it as much as i can. Indeed, that is my intentions, a first test today, and more over the week-end. thanks! Having the g-i avalable for PPCs too would be really nice! Attilio [1] http://wiki.debian.org/DebianInstaller/GUIBuild -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Fri, Sep 22, 2006 at 02:52:24PM +0200, Attilio Fiandrotti wrote: Sven Luther wrote: snip/ Last times the g-i was tested on PPC, it turned tout that Known good : radeonfb, vesafb (or whatever x86 uses). vesafb is not built on powerpc, and the laptop we had in extremadura used a radeon chipset, altough of the R300 variety. isn't fbonly the PPC equivalent to vesafb on i386? That is offb, and no, it is totally different :) Most drivers are builtin the kernel though, so therei s really no need for offb, except for real old hardware. I know claudio ciccani worked a lot on DFB's Radeon driver recently, so things may have been fixed in DFB 0.9.25. Currently in unstable ? Known bad : atyfb, nvidiafb when acceleration was enabled. But that was with GTKDFB 2.0.9 and DFB 0.9.22, while now we have DFB 0.9.25 and GTK 2.8.20 and many bugs got fixed. And it will be better with gtk 2.10.x even, right ? On i386 this proved to be true, but i cannot speak for other archs as i never experimented anything personally. Ok. Let me think to get you an efika board once the developper program is underway. This is the most serious bug affecting g-i on PPC, and i wasn't able to fix it because i have no PPC HW. Yes, i will. Need to build a netboot g-i image and will test that on my pegasos with the radon 9250 board. If you experience crashes, you may want to run the d-i in a chroot cage, like explained in this [1] wiki page. Ok, thanks. Sven, do you think can give the PPC g-i a try? i will help you on debugging it as much as i can. Indeed, that is my intentions, a first test today, and more over the week-end. thanks! Having the g-i avalable for PPCs too would be really nice! Indeed. As said, i would have done this earlier, but well, the context was not favourable to this kind of things, let's say. Attilio [1] http://wiki.debian.org/DebianInstaller/GUIBuild Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
Well, My first naive test with the unstable g-i, gives just a blue screen. I can alt-ctr-f2 away, and check a bit. We did never implement the thingy which disables the acceleration in the directfbrc, right ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
Sven Luther wrote: On Fri, Sep 22, 2006 at 02:52:24PM +0200, Attilio Fiandrotti wrote: Sven Luther wrote: snip/ Last times the g-i was tested on PPC, it turned tout that Known good : radeonfb, vesafb (or whatever x86 uses). vesafb is not built on powerpc, and the laptop we had in extremadura used a radeon chipset, altough of the R300 variety. isn't fbonly the PPC equivalent to vesafb on i386? That is offb, and no, it is totally different :) Most drivers are builtin the kernel though, so therei s really no need for offb, except for real old hardware. ah, ok! I know claudio ciccani worked a lot on DFB's Radeon driver recently, so things may have been fixed in DFB 0.9.25. Currently in unstable ? yes, the same version we're using in the g-i Known bad : atyfb, nvidiafb when acceleration was enabled. But that was with GTKDFB 2.0.9 and DFB 0.9.22, while now we have DFB 0.9.25 and GTK 2.8.20 and many bugs got fixed. And it will be better with gtk 2.10.x even, right ? On i386 this proved to be true, but i cannot speak for other archs as i never experimented anything personally. Ok. Let me think to get you an efika board once the developper program is underway. ok, BTW i'm in contact with Gentoo PPC porter, maybe i could ask him if he can let me use a PPC board to debug the g-i This is the most serious bug affecting g-i on PPC, and i wasn't able to fix it because i have no PPC HW. Yes, i will. Need to build a netboot g-i image and will test that on my pegasos with the radon 9250 board. If you experience crashes, you may want to run the d-i in a chroot cage, like explained in this [1] wiki page. Ok, thanks. Sven, do you think can give the PPC g-i a try? i will help you on debugging it as much as i can. Indeed, that is my intentions, a first test today, and more over the week-end. thanks! Having the g-i avalable for PPCs too would be really nice! Indeed. As said, i would have done this earlier, but well, the context was not favourable to this kind of things, let's say. I really hope we'll be able to deliver a working g-i to PPC users too.. Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
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. pgpblXn4ZByce.pgp Description: PGP signature
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Fri, Sep 22, 2006 at 09:37:28AM +0200, Attilio Fiandrotti wrote: Last times the g-i was tested on PPC, it turned tout that Known good : radeonfb, vesafb (or whatever x86 uses). Known bad : atyfb, nvidiafb when acceleration was enabled. But that was with GTKDFB 2.0.9 and DFB 0.9.22, while now we have DFB 0.9.25 and GTK 2.8.20 and many bugs got fixed. This is the most serious bug affecting g-i on PPC, and i wasn't able to fix it because i have no PPC HW. Sven, do you think can give the PPC g-i a try? i will help you on debugging it as much as i can. Ok, i gave a quick test, and discovered the following : (hardware is a pegasos machine, with radeon 9250 graphic card). I did a plain g-i from unstable build, and netbooted the vmlinuz-chrp.initrd file. It booted nicely, but ended up in a blue screen, i suppose these are the symptoms of the crash. I thus rebuilt the installer with adding : no-hardware screenshot-dir=/ (is this one still needed ?) to /etc/directfbrc, as explained in a post from december 2005 in this bug report. This one booted fine, and the only problem i could see, is shown in the following picture : http://people.debian.org/~luther/languagechooser_language-name_0.png As you can see, there is a white space where the selection should be, this works fine when you use the mouse to point on stuff, but using up/down arrow keys exhibits this behaviour rather consistently. The last issue i saw when going to the consoles with ctr+alt+Fn to investigate a bit. The console font is garbagy, but this is probably a bug in either the radeonfb driver, or the enter/leave-VT functions of directfb. When you kill the X server from the console, this happens also. Ok, that is all for now, i will propose a patch later on which always enables no-hardware on powerpc, so we can at least get some testing done, and then would be happy to do some more advanced debuging to tackle the bug and/or also the console font issue. Friendly, Sven Luther Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] --- Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. Aucun virus connu a ce jour par nos services n'a ete detecte. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
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. Thanks, Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
severity 342053 important thanks Lowering the severity of this bug to important. This issue is the main reason that g-i is only provided as experimental mini.iso for powerpc. However, that does not make RC for the package as a whole. pgpPtetxqhpwv.pgp Description: PGP signature
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Thu, Sep 21, 2006 at 03:32:28PM +0200, Frans Pop wrote: severity 342053 important thanks Lowering the severity of this bug to important. This issue is the main reason that g-i is only provided as experimental mini.iso for powerpc. However, that does not make RC for the package as a whole. Notice: Do we have a proof that by disabling acceleration, the issue goes away ? I remember in extremadura that by booting the system by hand into text mode and then launching the graphical mode made it work, so i am not sure that we have only this as issue, not sure. If someone guides me (i haven't touched the graphical installer since extremadura mostly), i will try to debug this issue over the WE. (Note that maybe, if we wouldn't have gotten in kindergarten-like, motivation killer petty disputes these past 6 month, this issue would have been solved already :). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
Package: cdebconf-gtk-udeb Severity: normal DirectFrameBuffer by default enables hardware acceleration whenever possible, this resulted in a DFB crash on many PPC systems [1] . DFB's HW acceleration should be disabled at runtime for those fb drivers that are known to be actually broken. Detection of used framebuffer module can be done after boot by checking kernel's output, while DFB's HW acceleration can be turned off by adding no-hardware to runtime configuration file /etc/directfbrc [2]. The user should always be able to force HW accelaration off at boot time with an ad-hoc parameter. As a temporary workaround for bugs like [1] this has proven to occasionally work -Boot the graphical-installer with install video=ofonly DEBIAN_FRONTEND=newt -Let the NEWT frontend appear, switch to VT2 and type echo 'no-hardware' /etc/directfbrc echo 'screenshot-dir=/' /etc/directfbrc export DEBIAN_FRONTEND=gtk debian-installer if everything goes as expected the graphical installer should start using DFB's unaccelerated video driver and you should be able to use the Stamp key to take screenshots Attilio Fiandrotti [1] http://lists.debian.org/debian-boot/2005/12/msg00011.html [2] http://www.directfb.org/docs/directfbrc.5.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342053: DirectFrameBuffer crashes on PPC systems if HW accelerated drivers are used
On Mon, Dec 05, 2005 at 12:20:36AM +0100, Attilio Fiandrotti wrote: Package: cdebconf-gtk-udeb Severity: normal DirectFrameBuffer by default enables hardware acceleration whenever possible, this resulted in a DFB crash on many PPC systems [1] . DFB's HW acceleration should be disabled at runtime for those fb drivers that are known to be actually broken. Right now we have the following cases tested : Known good : radeonfb, vesafb (or whatever x86 uses). Known bad : atyfb, nvidiafb And furthermore, the cursor bug is due to an endianess error in the directfb accel code. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
