Re: wine XShm problem on remote display

[Benjamin Fabricius]

Am Dienstag, den 13.06.2006, 16:22 +0200 schrieb Alexandre Julliard:
> Benjamin Fabricius  writes:
> > vst:/opt/fst # ./fst /mnt/testsuite/oberon4/Oberon-8.dll
> > yo... lets see...
> > The program 'fst.exe.so' received an X Window System error.
> > This probably reflects a bug in the program.
> > The error was 'BadAccess (attempt to access private resource

denied)'.
> > (Details: serial 114 error_code 10 request_code 144 minor_code 1)
> >   (Note to programmers: normally, X errors are reported

asynchronously;
> > that is, you will receive the error a while after causing it.
> >    To debug your program, run it with the --sync command line
> >    option to change this behavior. You can then get a meaningful
> >    backtrace from your debugger if you break on the gdk_x_error()
> > function.)
>
> Wine will handle that error properly, but here it sounds like fst (or
> more likely Gtk) has replaced the Wine error handler with its own, so
> Wine doesn't get a chance to handle it.

thanks for the hint,

isn't there a possibility in wine to turn of the use of the xshm
extension globally?

i read that there used to be wine.conf with 
[x11drv]
......
 ; Use XFree86 DGA extension if present
 UseDGA = Y
 ; Use XShm extension if present
 UseXShm = Y
......

is there a mechanism to do this in my wine version (20050725)
or current builds?

or do you see a way different way to workaround this, i. e. to write an
own
error handler. i'm not to deep into the x matter though...

thanks again
bf

wine XShm problem on remote display

[Alexandre Julliard]

Benjamin Fabricius  writes:
> or do you see a way different way to workaround this, i. e. to write an
> own
> error handler. i'm not to deep into the x matter though...

The error handler exists already, all you need is to convince Gtk to
call the previous handler instead of dying right away; or else try to
initialize Wine after Gtk so that its handler takes over.