Bug#373253: [directfb-dev] Cause of g-i crashing on AMD64 at VT switch found
Attilio Fiandrotti schrieb: IIUC pthread_cancel() is revealing difficult to be replaced: should we proceed adding libgcc1 to d-i, hence leaving you DFB guys all the time you needed to implement an appropriate replacement for that call? I can make quick hackish workarounds for selected drivers now, but if adding the library is still possible, I'd do that. -- 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#373253: [directfb-dev] Cause of g-i crashing on AMD64 at VT switch found
Frans Pop schrieb: On Monday 04 December 2006 23:55, Denis Oliver Kropp wrote: Attilio Fiandrotti schrieb: IIUC pthread_cancel() is revealing difficult to be replaced: should we proceed adding libgcc1 to d-i, hence leaving you DFB guys all the time you needed to implement an appropriate replacement for that call? I can make quick hackish workarounds for selected drivers now, but if adding the library is still possible, I'd do that. Stated like that I think I prefer my hackish workaround in our build system over your hackish patches :-) Will implement now. You do still intend to remove the pthread_cancel() calls in the not to distant future though? No, it would have been a patch only for you :) -- 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#400898: [directfb-users] Problems with pixelformat rgba 6/0, 6/0, 6/0, 0/0
Attilio Fiandrotti schrieb: Denis Oliver Kropp wrote: Attilio Fiandrotti schrieb: Hi We recently received bugreports [1] [2] about this pixelformat not being supported by DFB, and googling around i found out that someone else came here asking for help earlier [3] [4]. Is there anything that can be done to fix this ? The screenshot says it's 4bit which is not supported. Adding DSPF_LUT4 wouldn't be that hard though. But I'm wondering how it would look like. Is this using vesafb or nvidiafb? vesafb, on i386 and amd64 we always start that fb device at boot passing video=vesa vga=788 to the kernel and ATM adding one more patch to our directfb sources shouldn't be a problem. 788 should be 16 bit. I wonder why it's reporting 4 bit. -- 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#395257: [directfb-dev] Workaround for keymap related bugs in g-i available, please test it
Attilio Fiandrotti schrieb: Hi Today, after many unlucky experiments, i tried disabling the keyboard module in directfbrc, hence having linux_input manage the keyboard, as DOK and suggested some times ago and Davide reminded me yesterday. Guess guess, now keymap can be correctly switched multiple times between english and italian, and i also verified that - With de-latin1 keymap the @ symbol is obtained with AltGr-q - With sg-latin1 keymap the @ symbol is obtained with AltGr-2 Are dead keys in the key map and working? All this with console in utf mode. I prepared a miniiso [1] for testing: could you dear d-i fellows please test and report whether your local keymap correctly works? CC'ing directfb-dev too: dok, do you believe managing keyboard via linux_input instead of keyboard module has any drawback? I'm wondering it makes a difference. Ville, IIRC, took the code from the keyboard driver. the iso is named that way because in /usr/local/bin you'll find test binaries from DirectFB-examples, which may be useful for debugging purposes, especially df_input :) -- 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#395257: [directfb-dev] Workaround for keymap related bugs in g-i available, please test it
Attilio Fiandrotti schrieb: Denis Oliver Kropp wrote: Attilio Fiandrotti schrieb: Hi Today, after many unlucky experiments, i tried disabling the keyboard module in directfbrc, hence having linux_input manage the keyboard, as DOK and suggested some times ago and Davide reminded me yesterday. Guess guess, now keymap can be correctly switched multiple times between english and italian, and i also verified that - With de-latin1 keymap the @ symbol is obtained with AltGr-q - With sg-latin1 keymap the @ symbol is obtained with AltGr-2 Are dead keys in the key map and working? IIRC, a specific bug (394871) is still open about deadkeys not working, but i cannot verify by myself if deadkeys now work, as i don't have the necessary knowledge 2006-05-05 dok23:07:23Denis Oliver Kropp [EMAIL PROTECTED] Files: src/core/input.c (1.119) (+105 -3;) First and fully working implementation of dead key handling using static tables for mapping of dead keys and following symbols to the combined symbol. -- 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#373253: [directfb-dev] Cause of g-i crashing on AMD64 at VT switch found
Attilio Fiandrotti schrieb: Denis Oliver Kropp wrote: Attilio Fiandrotti wrote: Hi i recently put my hands on an AMD64 machine, so i had the chance to run the installer from a chroot and i noticed that the crash produces this log libgcc_s.so.1 must be installed for pthread_cancel to work (!) [ 5905:0.000] -- Caught signal 6 (unknown origin) -- libgcc_s.so.1 must be installed for pthread_cancel to work Aborted adding this library (and full libc) to the chroot prevents the crash. Good news! Is it ok to include the library or should the input driver be changed to not use pthread_cancel()? Last night, talking with Frans Pop and Kurt Roeckx, it turned out that including correct libraries may be a bit complicated right now, and possibly we could not make it in time for Etch. So, i was asked to investigate about the possibility to remove pthread_cancel() calls from DirectFB code: dok, do you believe that's possible / easy to do? Should be possible with minor effort. pthread_cancel() is evil anyways. -- 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#373253: [directfb-dev] Cause of g-i crashing on AMD64 at VT switch found
Attilio Fiandrotti schrieb: Denis Oliver Kropp wrote: Should be possible with minor effort. pthread_cancel() is evil anyways. Dok, we would really really apreciate if you could provide us ASAP the patch: we're now kind of running out of time as Etch release date gets closer every day. I'll build an experimental ISO image with your patch and ask people to test it to catch possible issues coming from the patch. Working on it now. -- 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#373253: [directfb-dev] Cause of g-i crashing on AMD64 at VT switch found
Attilio Fiandrotti wrote: Hi i recently put my hands on an AMD64 machine, so i had the chance to run the installer from a chroot and i noticed that the crash produces this log libgcc_s.so.1 must be installed for pthread_cancel to work (!) [ 5905:0.000] -- Caught signal 6 (unknown origin) -- libgcc_s.so.1 must be installed for pthread_cancel to work Aborted adding this library (and full libc) to the chroot prevents the crash. Good news! Is it ok to include the library or should the input driver be changed to not use pthread_cancel()? -- 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
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]
