Change resolution on the fly?

Crivens

Crivens

Administrator
Staff member
Administrator
Moderator
Hello *,

OK, after using my $SEARCHENGINE for some days now, reading the sticky posts here and some attempts to be creative about it, it may be the smart thing to try and ask here: Why does my xorg quit itself when wine wants to change the resolution?

Background: After some time I wanted to play some old games again, which already were working with wine. But when I click the "start" button of Baldurs Gate, the X server drops core on resolution change. I am also a bit suprised that X11 does not change the resolution when pressing ctrl-alt-´+´ / ctrl-alt-´-´. That must have been done to X11 somewhere in the last years.

System : RELENG_8, amd64, radeonhd, using wine being build in /compat/i386.

Happens with ati driver, radeonhd, vesa... This even happens to Xephir, which I thought would be the best way to work around this. But no luck :(

Any ideas?
 
Xorg doesn't crash here when changing resolutions. And yes, ctrl+alt++/- functionality was removed from most drivers (or perhaps the X server) back when xrandr 1.2 was implemented in the drivers. Does X crash if you use xrandr from an xterm to change the resolution? Can you get a backtrace.

Also, you really should switch to xf86-video-ati ('radeon') even if it's unrelated to the crash. radeonhd is completely, 100% undeveloped and unsupported.

Adam
 
Crivens said:
Hello *,

OK, after using my $SEARCHENGINE for some days now, reading the sticky posts here and some attempts to be creative about it, it may be the smart thing to try and ask here: Why does my xorg quit itself when wine wants to change the resolution?

Background: After some time I wanted to play some old games again, which already were working with wine. But when I click the "start" button of Baldurs Gate, the X server drops core on resolution change. I am also a bit suprised that X11 does not change the resolution when pressing ctrl-alt-´+´ / ctrl-alt-´-´. That must have been done to X11 somewhere in the last years.

System : RELENG_8, amd64, radeonhd, using wine being build in /compat/i386.

Happens with ati driver, radeonhd, vesa... This even happens to Xephir, which I thought would be the best way to work around this. But no luck :(

Any ideas?
Click to expand...

A work around would be to set wine mode to "Graphics->Emulate Virtual Desktop" this will prevent wine from changing screen's resolution instead it will resize its window.
 
Thank you two for the feedback so far. Radeonhd is the hardware, the driver is of course the xf86-video-ati. And putting wine into the "Emulate Desktop" mode also does not help. It will work correctly untill the app wants to go fullscreen, and then Xorg curls up.

The backtrace, according to the core file, is this:
Code: 
(gdb) bt
#0  0x00000008016d08bc in kill () from /lib/libc.so.7
#1  0x00000008016cf6bb in abort () from /lib/libc.so.7
#2  0x00000000004740c4 in ddxGiveUp ()
#3  0x000000000046d65d in AbortServer ()
#4  0x000000000046dcdf in FatalError ()
#5  0x0000000000467f01 in OsInit ()
#6  <signal handler called>
#7  0x00000008016cd417 in strlen () from /lib/libc.so.7
#8  0x00000008016c6072 in open () from /lib/libc.so.7
#9  0x0000000801635f29 in vsnprintf () from /lib/libc.so.7
#10 0x0000000814f93292 in make_error_string ()
   from /usr/local/lib/dri/r600_dri.so
#11 0x0000000814f9332c in yyerror () from /usr/local/lib/dri/r600_dri.so
#12 0x0000000814f96907 in _mesa_parse_arb_program ()
   from /usr/local/lib/dri/r600_dri.so
#13 0x0000000814f8ea1d in _mesa_parse_arb_vertex_program ()
   from /usr/local/lib/dri/r600_dri.so
#14 0x0000000814ee3dbc in _mesa_ProgramStringARB ()
   from /usr/local/lib/dri/r600_dri.so
#15 0x0000000801e3de1e in __glXDisp_Render (cl=Variable "cl" is not available.
) at glxcmds.c:1823
#16 0x0000000801e41cc0 in __glXDispatch (client=0x801a1a200) at glxext.c:578
#17 0x0000000000436590 in Dispatch ()
#18 0x000000000042c8ea in main ()
I will now build the dri with debug and see what that gets me. Seems like someone is passing bad pointers around.
 
Your X server is crashing in the glx code due to something whacked with the r600 DRI driver. Basically, 3D applications will fall back to accelerated indirect rendering (passing OpenGL commands through the X server) since 32-bit apps don't work properly with DRI on 64-bit installations. And, yeah, your assessment is almost certainly accurate about bad pointers being passed, but it likely has nothing to do with changing resolutions but, instead, sending the first commands to the 3D driver.

I've probably not seen this because I'm actually using Mesa from git rather than from the ports tree. You could try updating your driver and seeing if that makes a difference for you.

Adam
 
Hmmmm, this means I need to update the dri code outside of ports. I had ports updated not a week ago, but maybe there is some new stuff. *sight* Are there any dragons about there, outside the charted ports?
 
Generally, any port related to Xorg is going to be far removed from what is available upstream. So, yes, there is definitely new stuff related to DRI/Mesa. You will want to update libdrm and mesa, and I think that requires updating xorg macros (it will let you know, of course, when you try to build libdrm/mesa if you need to update macros).

Adam
 
Just to leave a ping here, I tried the new dri from git but it alone does not work. Compiling a newer Mesa is hitting some snags which I did not have the time to iron out for now. Currently, I can spend about max 1h on this per day, so I'll just let it be known that my progress here will be a bit slow.
 
*sigh* - one might have tought that this would be cleaned up by now.

After I was told that emulators/wine works on amd64, I tried to go back to some place in Tristram - turns out things got worse. Not only crashes the X server, but thanks to all the stuff now in KMS the whole system simply curls up and dies once something goes full screen. I'll check out some more games as soon as possible.

Does anyone know anything?
 
You must log in or register to reply here.
Back
Top