Re: On fbdev [3dfx] and console-switching...
On Wed, Jan 26, 2000 at 06:04:15AM -0700, teunis wrote: > On 26 Jan 2000, Marcus Sundberg wrote: > > > teunis <[EMAIL PROTECTED]> writes: > > > > > Hey, is there any way to catch console-switching? > > > > See the end of ggi/types.h, and ask if there's something unclear > > about it. > > > > > Mah evil program does run in the background... > > > > However this should not happen. Applications running on fbdev and > > svga targets are halted on switch-away unless they have requested > > GGICMD_NOHALT_ON_UNMAP. > > How do you do this? I'd really much rather handle this myself. There's > no real reason to halt the program - only to halt the renderer. The > program itself uses locking queues so when it runs out of space it'll wait > for the renderer to wake up. Or just toss the frames it can't draw. > (preferably: the latter :) Easy enough to do. If you only want the renderer to halt, make the renderer a separate process to draw to the target that may be fbdev or svga. Use shared memory between it and the rest of the program. This is the UNIX way. -- Tristan Wibberley
Re: On fbdev [3dfx] and console-switching...
On Wed, 26 Jan 2000, teunis wrote: > On 26 Jan 2000, Marcus Sundberg wrote: > > > teunis <[EMAIL PROTECTED]> writes: > > > > > Hey, is there any way to catch console-switching? > > > > See the end of ggi/types.h, and ask if there's something unclear > > about it. Okay. It's not clear. [clip] Now how am I supposed to use this? G'day, eh? :) - Teunis
Re: On fbdev [3dfx] and console-switching...
On 26 Jan 2000, Marcus Sundberg wrote: > teunis <[EMAIL PROTECTED]> writes: > > > Hey, is there any way to catch console-switching? > > See the end of ggi/types.h, and ask if there's something unclear > about it. > > > Mah evil program does run in the background... > > However this should not happen. Applications running on fbdev and > svga targets are halted on switch-away unless they have requested > GGICMD_NOHALT_ON_UNMAP. How do you do this? I'd really much rather handle this myself. There's no real reason to halt the program - only to halt the renderer. The program itself uses locking queues so when it runs out of space it'll wait for the renderer to wake up. Or just toss the frames it can't draw. (preferably: the latter :) Easy enough to do. > Is this by any chance a threaded application? > Then I suppose that it might be that only one thread is halted... It's a very threaded application. And halting it would be... unhealthy. To the program anyways. It won't quit if the main thread halts. At least not until you return to it - and if the condition state is not saved it may -never- quit. Right. Must fix. Must fix now. Thanks! :) G'day, eh? :) - Teunis PS: This does work on all appropriate targets, right? (eg: fbdev)
Re: On fbdev [3dfx] and console-switching...
teunis <[EMAIL PROTECTED]> writes: > Hey, is there any way to catch console-switching? See the end of ggi/types.h, and ask if there's something unclear about it. > Mah evil program does run in the background... However this should not happen. Applications running on fbdev and svga targets are halted on switch-away unless they have requested GGICMD_NOHALT_ON_UNMAP. Is this by any chance a threaded application? Then I suppose that it might be that only one thread is halted... //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: On fbdev [3dfx] and console-switching...
On Tue, 25 Jan 2000, Andreas Beck wrote: > > Hey, is there any way to catch console-switching? > > Mah evil program does run in the background... but I get all this funky > > graphics overwriting whatever console I'm on. > > Normally, this is done for you. However when you run a LibGGI application in > the background, it cannot attach to the console correctly (linux-input will > not work due to permission problems and the stdio method will be used > as fallback - you should see the cursor still blinking on fbcon on such > consoles). AFAIK the only way to solve this, is running the application as > root. [clip] Actually I start in the foreground I suspect a bug in fb-3dfx actually. I'm not running it in the background... I just switch consoles while I'm running it :) G'day, eh? :) - Teunis
Re: On fbdev [3dfx] and console-switching...
> Hey, is there any way to catch console-switching? > Mah evil program does run in the background... but I get all this funky > graphics overwriting whatever console I'm on. Normally, this is done for you. However when you run a LibGGI application in the background, it cannot attach to the console correctly (linux-input will not work due to permission problems and the stdio method will be used as fallback - you should see the cursor still blinking on fbcon on such consoles). AFAIK the only way to solve this, is running the application as root. My infamous "xggi" script is the result of that situation: I start the windowmanager _first_ with a delay before it in the background and then exec the xggi program to avoid this situation. The windowmanager will come up after the delay is through and connect to the X server that is running in the foreground. CU, Andy -- = Andreas Beck| Email : <[EMAIL PROTECTED]> =
On fbdev [3dfx] and console-switching...
Hey, is there any way to catch console-switching? Mah evil program does run in the background... but I get all this funky graphics overwriting whatever console I'm on. It's really neat-looking so I'm not too much in a hurry :) G'day, eh? :) - Teunis
