Have you been able to get any other SVGALIB and/or SDL apps working?

hmm yes. well dosbox tends to run using X instead of vgalib.
but to be honest I never tried the vgalib variant of sdl. I always use X

Dosbox doesn't like SDL returning an error on video mode initialization. It doesn't handle that correctly and crashed. However, the true problem is that SDL couldn't initialize your video system. I can't help you there either, but that's what you have to get going. I would guess svgalib can't switch to the desired resolution or bit depth - and you just have to find out why 😉

You could also try the framebuffer console instead of svgalib if you know how to enable it and your kernel supports that.

DOSBox should be fixed to not crash. No matter what error happens, a robust program should catch and handle it gracefully instead of crashing...

Walter Dnes wrote:

I've now "advanced" to the point where svgalib spins its wheels for a few seconds, and segfaults. It doesn't matter whether I run dosbox as regular user or root. I can't figure out what strace is saying, so I'm uploading the tail end of the log. The strace log is over 3 megabytes, but it's probably just the last bit that's useful.

I managed to figure it out, indirectly, backwards, etc. To make sure that I had the latest versions of everything relevant, I rebuilt svgalib and everything that depended on svgalib. At the end of the "links" build output, was a note that links (aka links2) needed to be suid in order to be able to use svgalib. This reminded me that one of the last commands in the strace log was "getuid32()", which indicated that it cared about setuid. I setuid dosbox, and it now comes up in drive Z:. The following error comes up, but at least I'm in dosbox...

CONFIG: Using default settings. Create a configfile to change them
ALSA:Can't subscribe to MIDI port (65:0)
MIDI:Opened device:none

Does somebody want me to post a checklist or FAQ entry about my "experiences", to save other linux users a bunch of fumbling around? To the instructions on my first post, add the following...

chmod u+s /usr/games/bin/dosbox
*WARNING* this can be a security risk; use with care, and not on multi-user machines.

That would be great. You could add the info to the Wiki if you wanted.

It looks like the next step is to get ALSA working on your system so you can have MIDI support 😀

ALSA seems to be working for him, there's just no (hardware) MIDI port. Typical average onboard sound... the timidity++ package provides a soft synth that can register as a MIDI port. More details can be found in the package's docs.

HunterZ wrote:

That would be great. You could add the info to the Wiki if you wanted.

It looks like the next step is to get ALSA working on your system so you can have MIDI support 😀

I'll hold off "educating others" until I get the various combinations sorted out and I know what I'm doing. Here's what I think I've found so far...
- dosbox requires sdl
- sdl has the option of being compiled with, or without, svgalib support
- svgalib bangs away directly at the hardare, which requires root-level permission.
- if sdl is compiled with svgalib linked in, any program using sdl (dosbox or mplayer or whatever) indirectly uses svgalib, and therefore must be run setuid root (potential security risk, frowned on in linux)
- if sdl is compiled *WITHOUT* linkage to svgalib, I find I don't have to screw around with loading svgalib_helper and chmod /dev/console and setuid dosbox as root.

Running *WITHOUT* svgalib linked into sdl is obviously the preferred way to go. On Gentoo, I control the system and can rebuild sdl to my specs. On "consumer-oriented-desktop" versions of linux, the end-user may not have that level of control, and may have to resort to running dosbox setuid root, etc.

I wonder why svgalib needs to be linked in... many other libs, like OpenGL, are used differently: SDL only loads the DLL (or .so for linux) when it is first accessed. Needs special programming, though - probably whoever did the svgalib driver left that out.

By the way, what happens if you "export SDL_VIDEODRIVER=x11" before you run dosbox with your svgalib-linked-in SDL? SDL shouldn't access svgalib at all in that case. It might just be the autodetect that triggers svgalib calls.

It sounds like he's saying that it doesn't need to be linked in. My guess is that SDL supports both X and svgalib as output devices under linux (makes sense to me).

And it's way out in left field. There's been an upgrade to bash 3 recently. I have a customized prompt that is supposed to show up in shells and subshells (e.g. an xterm). It's no longer showing up the way I like it. Something has changed the way environmental variables like "PS" are passed. "PS" wasn't getting passed properly under my weird scheme. Neither was "DISPLAY". Not finding "DISPLAY", sdl went to "plan B", namely svga.

I was going nuts trying to correlate behaviour from a few days ago (before the bash upgrade), with current behaviour (after bash upgrade). DISPLAY existed in text consoles so launching from there used X, which I always have running in the background. DISPLAY did not exist inside an xterm, so dosbox tried using svga.

I've straightened out how environmental variables are passed under the "new and improved" layout and things work properly. That's my current explanation, and I think it covers everything.