Hallo!
Just discovered 2 bugs (or at least strange behaviours):
1) create a gemwin, then close the gemwin with the mouse (clicking on the "x" right above the window ...) -> crash (also if there is no gemhead ...) the console tells me:
GEM: Only using 8 color bits Direct Rendering enabled! GEM: Start rendering X connection to :0.0 broken (explicit kill or server shutdown). pd_gui: pd process exited
for a gdb backtrace see below ...
2) If I want to make a fullscreen Gem-window with [fullscreen 1( my window manager (kde3.5) is really messed up ... I don't know how to explain ... resolution is really low and if I move the mouse I get out of the gemwin and see the rest of the screen (the patch, console ...) in a really low resolution ...
I'm using Gem from cvs (compiled in january), pd0.39, xorg, debian, 2.6.14 kernel ...
LG Georg
gdb backtrace for problem 1:
Program received signal SIGPIPE, Broken pipe. [Switching to Thread -1210788160 (LWP 7621)] 0xb7e9037e in __write_nocancel () from /lib/tls/libpthread.so.0 (gdb) bt #0 0xb7e9037e in __write_nocancel () from /lib/tls/libpthread.so.0 #1 0xb79e5b5e in XUnlockDisplay () from /usr/X11R6/lib/libX11.so.6 #2 0xb79e5e5f in _X11TransWrite () from /usr/X11R6/lib/libX11.so.6 #3 0xb79c96a5 in _XError () from /usr/X11R6/lib/libX11.so.6 #4 0xb79c97cd in _XReply () from /usr/X11R6/lib/libX11.so.6 #5 0xb7abb6ea in XF86DRIGetDrawableInfo () from /usr/lib/libGL.so.1 #6 0xb6ed41fd in __driUtilUpdateDrawableInfo (pdp=0x83e65d0) at dri_util.c:424 #7 0xb6eda580 in radeonGetLock (rmesa=0x82d9300, flags=12) at radeon_lock.c:107 #8 0xb6ed7b9e in radeonFlushCmdBuf (rmesa=0x82d9300, caller=0xb6f3ab4a "radeonFlush") at radeon_ioctl.c:617 #9 0xb6ed819e in radeonFlush (ctx=0xffffffe0) at radeon_ioctl.c:1255 #10 0xb6ed997e in radeonCopyBuffer (dPriv=0x83e65d0) at radeon_ioctl.c:902 #11 0xb6ed677e in radeonSwapBuffers (dPriv=0x83e65d0) at radeon_context.c:568 #12 0xb6ed44cf in driSwapBuffers (dpy=0x8289c90, drawablePrivate=0xffffffe0) at dri_util.c:470 #13 0xb7a97bae in glXSwapBuffers () from /usr/lib/libGL.so.1 #14 0xb7c37386 in GemMan::swapBuffers () from /usr/lib/pd/extra/Gem.pd_linux #15 0xb7c37dc1 in GemMan::render () from /usr/lib/pd/extra/Gem.pd_linux #16 0x080b1ef4 in sched_tick (next_sys_time=63815680) at m_sched.c:355 #17 0x080b2cd8 in m_scheduler () at m_sched.c:460 #18 0x080b5d45 in sys_main (argc=5, argv=0xbfba086c) at s_main.c:292 #19 0xb7d63ed0 in __libc_start_main () from /lib/tls/libc.so.6
Georg Holzmann wrote:
Hallo!
Just discovered 2 bugs (or at least strange behaviours):
create a gemwin, then close the gemwin with the mouse (clicking on the "x" right above the window ...) -> crash (also if there is no gemhead ...) the console tells me:
GEM: Only using 8 color bits Direct Rendering enabled! GEM: Start rendering X connection to :0.0 broken (explicit kill or server shutdown). pd_gui: pd process exited
on my machine this does not crash. however, it does crash, when you "create" the gem-window, close it with the mouse and then hit the "destroy" button.
actually the problem is that when a display/window-handle becomes invalid (because you the window gets destroyed by someone else) and then you access this invalid handle, the X-server will crash.
in theory, i see 3 solutions to this problem: a) perform a check whether the handle is still valid before doing any critical operation on it: unfortunately i haven't found any possibility to do so b) register a callback function that gets called whenever the window is destroyed - similar to resize-callbacks: unfortunately i haven't managed to do so... c) provide X with an error-handler that gets called whenever something really bad has happened (like a critical operation on an invalid handle): unfortunately there IS already an error-handler, which for some unknown reason does not get called. (if it did, then the ErrorHandler would need to be fleshed out, in order to prevent a crash; but that is just a minor issue...)
i guess i need some help here by some oldschool X-programmers. (gÃŒnter...?)
If I want to make a fullscreen Gem-window with [fullscreen 1( my window manager (kde3.5) is really messed up ... I don't know how to explain ... resolution is really low and if I move the mouse I get out of the gemwin and see the rest of the screen (the patch, console ...) in a really low resolution ...
"fullscreen" tries to go in fullscreen-mode with the current dimension of the gemwindow (and not that of the display). so if you make do [dimen 640 480, fullscreen 1, create(, your monitor should go into fullscreen-mode @ 640x480. if this is not possible (e.g. your dimension is 500x500 and hardly any hardware supports that in fullscreen), Gem tries to find the "best" available resolution as reported by the X-server. when it finds a suitable resolution which is lower than your current one, it will switch to that; X will then make a virtual desktop.
you can change the resolutions back with Ctrl+Alt+"+"
solutions: + specify the current resolution as dimen before creating the fullscreen window. + only specify the resolutions you really want in your xorg.conf
btw, i am quite happy with this behaviour, as it allows me to go into fullscreen mode and still access the pd-patch in case of emergency.
mfg.asdr. IOhannes
Hallo!
on my machine this does not crash. however, it does crash, when you "create" the gem-window, close it with the mouse and then hit the "destroy" button.
okay ... ;)
"fullscreen" tries to go in fullscreen-mode with the current dimension of the gemwindow (and not that of the display). so if you make do [dimen 640 480, fullscreen 1, create(, your monitor should go into fullscreen-mode @ 640x480. if this is not possible (e.g. your dimension is 500x500 and hardly any hardware supports that in fullscreen), Gem tries to find the "best" available resolution as reported by the X-server. when it finds a suitable resolution which is lower than your current one, it will switch to that; X will then make a virtual desktop.
you can change the resolutions back with Ctrl+Alt+"+"
solutions:
- specify the current resolution as dimen before creating the
fullscreen window.
- only specify the resolutions you really want in your xorg.conf
thanks - now I understand the behaviour ...
btw, i am quite happy with this behaviour, as it allows me to go into fullscreen mode and still access the pd-patch in case of emergency.
yes, that's true ...
LG Georg