Switchres: modeline generator engine

[Calamity]

So the livecd32_12-13-2010_01_25_54.iso should already have those changes, doesn't it? I'm eager to test that one.

Yes, it was adding an extra byte and maybe if called twice an additional one, that's why I saw two zeros sometimes, is it possible?

Just a simple question as this really should be easy to do but I still can't get it. Imagine you have a path in your Windows partition named "C:\Roms\Mame" where all your roms reside. What exact answers would you enter through your config setup in order to make the system point to that path? I see there's a logic with that home directory, data, and stuff being mapped somehow, but I really don't know if I can make use of that without actually modifying my path structure in Windows (something I'd rather not doing). It's the same with "C:\Snap\Mame". I always use that logic as I believe is the easiest possible (ie. C:\(Roms, Snap, ...)\Emulator). I can see my hd being mapped as /dev/sda1 or something like that, but can't figure what to do with that and my path to work together.

[bitbytebit]

So the livecd32_12-13-2010_01_25_54.iso should already have those changes, doesn't it? I'm eager to test that one.

Yes, it was adding an extra byte and maybe if called twice an additional one, that's why I saw two zeros sometimes, is it possible?

Just a simple question as this really should be easy to do but I still can't get it. Imagine you have a path in your Windows partition named "C:\Roms\Mame" where all your roms reside. What exact answers would you enter through your config setup in order to make the system point to that path? I see there's a logic with that home directory, data, and stuff being mapped somehow, but I really don't know if I can make use of that without actually modifying my path structure in Windows (something I'd rather not doing). It's the same with "C:\Snap\Mame". I always use that logic as I believe is the easiest possible (ie. C:\(Roms, Snap, ...)\Emulator). I can see my hd being mapped as /dev/sda1 or something like that, but can't figure what to do with that and my path to work together.

Yes, it would keep adding an extra byte each time I guess, interesting.  Hopefully this ISO does better, at least I think I'm close at figuring out the issue but of course just have to see how OpenGL acts with that video card now.

You would use the /dev/sda1 or whatever it is as the data drive, it'll mount that under /data_ro, and when asked about the symlinks/rom locations you would then say you want to add them.  Then you would have real rom locations like, /data_ro/Roms/Mame and that would be the value for the C:\Roms\Mame directory, /data_ro/Roms/Mame when it asks where the Mame ROMS are located.  Then it'll use a symlink for you from /data_ro/Roms/Mame -> /data/roms and should work.  Same with the other locations, basically they will be mounted to /data_ro/XXX and should be case sensitive to (so might want to check in another xterm window what are the contents of /data_ro after mounting that drive).  There's a layout file in /home/arcade/.gentooarcade/ after those layouts are made which sort of shows the logic (although that file is only read on startup).  All the admin/setup stuff definitely needs some work, I eventually hope to focus on just making the setup interface better for this kind of stuff (like right now can't go back and redo the layout links after configuration, although if you go manually and do things like 'ln -s /data_ro/Roms/Mame /data/roms' it should work too).

Also you can really not even use the symlinks /data/ directory, if you run wahcade-setup and point it to where you have the Windows drive mounted then you can bypass the need for any of the custom layout stuff.  In a way it's probably better to do it that way right now, just tell wahcade-setup about /data_ro/Roms/Mame and other directories.  Of course to do that you will need a swap drive to do the re-indexing stuff, unfortunately it takes quite a bit of memory for that (may work without it, but probably depends how much memory the system has physically). 

[Calamity]

Oh, thanks, it's perfectly clear now
I'll have a try later, will let you know.

[bitbytebit]

Oh, thanks, it's perfectly clear now
I'll have a try later, will let you know.

This version, SwitchResWin-1.121-ddbfb81.7z, should no longer add the extra byte.  I was wondering why some entries weren't the same size, must have been the reason.

Also I'm writing a quick Perl script to calculate the needed dummy modes for the usermodes.txt file in Soft15khz.  It's interesting, seems there's about 190 modelines needed to really match every resolution for the most part.  Here's my basic script here, I have some checks for height to reduce the odd ones but probably could remove some more I think. 

Code: [Select]

#!/usr/bin/perl

$MAME_XML = "mame.xml";

my @resolutions = ();
my @lines = `grep "<display" $MAME_XML`;
foreach (@lines) {
        my $line = $_;
        chomp($line);
        my @parts = split(/\s+/, $line);
        my ($height, $width, $refresh, $orientation);
        foreach(@parts) {
                my $part = $_;
                chomp($part);
                my ($key, $value) = split(/=/, $part);
                $value =~ s/\"//g;
                if ($key eq 'width') {
                        $width = $value;
                } elsif ($key eq 'height') {
                        $height = $value;
                } elsif ($key eq 'refresh') {
                        $refresh = $value;
                } elsif ($key eq 'orientation') {
                        if ($value != 0 && $value != 360) {
                                $orientation = 1;
                        }
                }
        }
        if ($orientation) {
                my $tw = $width;
                my $th = $height;
                $height = $tw;
                $width = $height * (4.0/3.0);
        }
        my $new_height = recalc_height($height);
        $width = recalc_width($width);
        if ($new_height) {
                $height = $new_height;
        } else {
                # greater than 768 pixels high
        }
        if ($height && $width) {
                my $exists = 0;
                #print "$width $height $refresh\n";
                for (my $i = 0; $i < scalar(@resolutions); $i++) {
                        if ($resolutions[$i]{'width'} == $width &&
                                $resolutions[$i]{'height'} == $height)
                        {
                                $exists = 1;
                        }
                }
                if (!$exists) {
                        my $len = scalar(@resolutions);
                        $resolutions[$len]{'width'} = $width;
                        $resolutions[$len]{'height'} = $height;
                }
        }
}

for (my $i = 0; $i < scalar(@resolutions); $i++) {
        my ($width, $height);
        $width = $resolutions[$i]{'width'};
        $height = $resolutions[$i]{'height'};
        #print "$width $height\n";
        @mline = `switchres $width $height 60.00`;
        foreach (@mline) {
                my $line = $_;
                chomp($line);
                $line =~ s/\s+/ /g;
                $line =~ s/^\s+//g;
                if ($line !~ /^#/ && $line ne '') {
                        print "$line\n";
                }
        }
}

exit 0;

sub recalc_width($) {
        my $w = shift(@_);

        $w = (($w / 8)+(($w % 8)&0x01)) * 8;

        if ($w < 240) {
                $w = 240;
        }

        return $w;
}

sub recalc_height($) {
        my $h = shift(@_);
       
        if ($h < 192) {
                $h = 192;
        } elsif ($h > 192 && $h < 224) {
                $h = 224;
        } elsif ($h > 224 && $h < 240) {
                $h = 240;
        } elsif ($h > 240 && $h < 256) {
                $h = 256;
        } elsif ($h > 264 && $h < 288) {
                $h = 288;
        } elsif ($h > 288 && $h < 384) {
                $h = 384;
        } elsif ($h > 768) {
                return 0;
        }
        $h = (($h / 8)+(($h % 8)&0x01)) * 8;
        return $h;
}


It's just a rough sketch right now of it, need to do more parsing and checking to reduce things some and have some duplicates too.

[bitbytebit]

It seems that there's about 104 or so modelines necessary to allow all the different needed resolutions to be created.  I now have a new script, genres.pl, which basically is like the original genres but now uses switchres and works better than genres ever did before...

http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=blob;f=scripts/genres.pl

It's in the GIT repository under the scripts/ directory, here's the basic output of the generic monitor type (can specify monitor type, even tell it to use vsync which produces around 200 resolutions)...

I don't know for sure if this is an ok formatting for Soft15khz, suspect it is, and of course the refresh rates don't matter but are there just to show what they are actually for the reference modeline (plus I'm pretty sure Soft15khz changes them for the label anyways to integers and such)..

Code: [Select]

ModeLine "288x224x60.02" 6.038391 288 304 336 384 224 234 237 262 -HSync -VSync
ModeLine "256x224x60.02" 5.535192 256 272 304 352 224 234 237 262 -HSync -VSync
ModeLine "272x240x60.02" 5.786791 272 288 320 368 240 242 245 262 -HSync -VSync
ModeLine "768x224x60.02" 15.724976 768 800 872 1000 224 234 237 262 -HSync -VSync
ModeLine "240x224x60.02" 5.031992 240 256 280 320 224 234 237 262 -HSync -VSync
ModeLine "320x240x57.00" 6.670368 320 336 368 424 240 249 252 276 -HSync -VSync
ModeLine "512x224x60.02" 10.567185 512 536 584 672 224 234 237 262 -HSync -VSync
ModeLine "256x256x57.07" 5.544000 256 272 304 352 256 257 260 276 -HSync -VSync
ModeLine "480x192x60.02" 9.938186 480 504 552 632 192 218 221 262 -HSync -VSync
ModeLine "512x240x60.02" 10.567185 512 536 584 672 240 242 245 262 -HSync -VSync
ModeLine "640x240x60.02" 13.083181 640 664 728 832 240 242 245 262 -HSync -VSync
ModeLine "544x480x60.00" 11.214000 544 568 624 712 480 484 490 525 -HSync -VSync interlace
ModeLine "272x224x60.02" 5.786791 272 288 320 368 224 234 237 262 -HSync -VSync
ModeLine "304x224x60.02" 6.415791 304 320 352 408 224 234 237 262 -HSync -VSync
ModeLine "496x480x60.00" 10.206000 496 520 568 648 480 484 490 525 -HSync -VSync interlace
ModeLine "640x480x60.13" 13.083016 640 664 728 832 480 483 489 523 -HSync -VSync interlace
ModeLine "512x256x57.07" 10.584000 512 536 584 672 256 257 260 276 -HSync -VSync
ModeLine "256x192x60.02" 5.535192 256 272 304 352 192 218 221 262 -HSync -VSync
ModeLine "240x192x60.02" 5.031992 240 256 280 320 192 218 221 262 -HSync -VSync
ModeLine "704x480x59.94" 14.601396 704 736 808 928 480 484 490 525 -HSync -VSync interlace
ModeLine "256x240x60.02" 5.535192 256 272 304 352 240 242 245 262 -HSync -VSync
ModeLine "264x224x59.56" 5.660961 264 280 312 360 224 235 238 264 -HSync -VSync
ModeLine "376x256x57.07" 7.812000 376 392 432 496 256 257 260 276 -HSync -VSync
ModeLine "336x256x57.07" 6.930000 336 352 384 440 256 257 260 276 -HSync -VSync
ModeLine "240x240x50.00" 5.040000 240 256 280 320 240 269 272 315 -HSync -VSync
ModeLine "352x240x60.02" 7.422189 352 368 408 472 240 242 245 262 -HSync -VSync
ModeLine "512x480x60.00" 10.584000 512 536 584 672 480 484 490 525 -HSync -VSync interlace
ModeLine "480x480x60.00" 9.954000 480 504 552 632 480 484 490 525 -HSync -VSync interlace
ModeLine "384x256x55.00" 7.927920 384 400 440 504 256 262 265 286 -HSync -VSync
ModeLine "384x240x60.02" 7.925388 384 400 440 504 240 242 245 262 -HSync -VSync
ModeLine "320x224x60.02" 6.667390 320 336 368 424 224 234 237 262 -HSync -VSync
ModeLine "384x224x60.02" 7.925388 384 400 440 504 224 234 237 262 -HSync -VSync
ModeLine "640x224x60.02" 13.083181 640 664 728 832 224 234 237 262 -HSync -VSync
ModeLine "264x240x60.02" 5.660992 264 280 312 360 240 242 245 262 -HSync -VSync
ModeLine "280x240x60.02" 5.912591 280 296 328 376 240 242 245 262 -HSync -VSync
ModeLine "296x240x60.02" 6.289991 296 312 344 400 240 242 245 262 -HSync -VSync
ModeLine "800x480x60.13" 16.353770 800 832 912 1040 480 483 489 523 -HSync -VSync interlace
ModeLine "360x256x57.00" 7.551360 360 376 416 480 256 257 260 276 -HSync -VSync
ModeLine "360x240x57.00" 7.551360 360 376 416 480 240 249 252 276 -HSync -VSync
ModeLine "400x240x60.02" 8.176988 400 416 456 520 240 242 245 262 -HSync -VSync
ModeLine "280x224x60.02" 5.912566 280 296 328 376 224 234 237 262 -HSync -VSync
ModeLine "336x224x60.02" 6.918990 336 352 384 440 224 234 237 262 -HSync -VSync
ModeLine "664x496x57.52" 13.719050 664 696 760 872 496 503 509 547 -HSync -VSync interlace
ModeLine "416x224x60.02" 8.554388 416 432 472 544 224 234 237 262 -HSync -VSync
ModeLine "1024x480x60.13" 20.882507 1024 1064 1160 1328 480 483 489 523 -HSync -VSync interlace
ModeLine "248x240x57.44" 5.288602 248 264 288 336 240 248 251 274 -HSync -VSync
ModeLine "384x192x60.02" 7.925388 384 400 440 504 192 218 221 262 -HSync -VSync
ModeLine "328x240x58.02" 6.793102 328 344 376 432 240 247 250 271 -HSync -VSync
ModeLine "320x256x57.07" 6.678000 320 336 368 424 256 257 260 276 -HSync -VSync
ModeLine "376x224x59.19" 7.808712 376 392 432 496 224 236 239 266 -HSync -VSync
ModeLine "304x256x57.07" 6.426000 304 320 352 408 256 257 260 276 -HSync -VSync
ModeLine "368x256x57.07" 7.686000 368 384 424 488 256 257 260 276 -HSync -VSync
ModeLine "576x224x59.19" 11.839015 576 600 656 752 224 236 239 266 -HSync -VSync
ModeLine "336x240x60.02" 6.918912 336 352 384 440 240 242 245 262 -HSync -VSync
ModeLine "480x464x60.00" 9.954000 480 504 552 632 464 476 482 525 -HSync -VSync interlace
ModeLine "496x240x60.02" 10.189785 496 520 568 648 240 242 245 262 -HSync -VSync
ModeLine "304x240x60.02" 6.415791 304 320 352 408 240 242 245 262 -HSync -VSync
ModeLine "328x256x57.07" 6.804000 328 344 376 432 256 257 260 276 -HSync -VSync
ModeLine "512x288x51.14" 10.583999 512 536 584 672 288 289 292 308 -HSync -VSync
ModeLine "672x240x60.02" 13.837921 672 704 768 880 240 242 245 262 -HSync -VSync
ModeLine "400x224x60.02" 8.176988 400 416 456 520 224 234 237 262 -HSync -VSync
ModeLine "392x224x60.02" 8.051188 392 408 448 512 224 234 237 262 -HSync -VSync
ModeLine "1024x528x55.08" 20.882493 1024 1064 1160 1328 528 531 537 571 -HSync -VSync interlace
ModeLine "512x192x60.02" 10.567185 512 536 584 672 192 218 221 262 -HSync -VSync
ModeLine "704x528x54.91" 14.597873 704 736 808 928 528 532 538 573 -HSync -VSync interlace
ModeLine "408x256x54.82" 8.432327 408 424 464 536 256 263 266 287 -HSync -VSync
ModeLine "400x256x56.67" 8.191560 400 416 456 520 256 258 261 278 -HSync -VSync
ModeLine "768x576x50.08" 15.750160 768 800 872 1000 576 584 590 629 -HSync -VSync interlace
ModeLine "248x224x60.02" 5.283592 248 264 288 336 224 234 237 262 -HSync -VSync
ModeLine "344x240x60.02" 7.044790 344 360 392 448 240 242 245 262 -HSync -VSync
ModeLine "328x224x60.02" 6.793190 328 344 376 432 224 234 237 262 -HSync -VSync
ModeLine "368x240x60.02" 7.673789 368 384 424 488 240 242 245 262 -HSync -VSync
ModeLine "480x240x59.12" 9.938108 480 504 552 632 240 244 247 266 -HSync -VSync
ModeLine "448x224x60.02" 9.434986 448 472 520 600 224 234 237 262 -HSync -VSync
ModeLine "448x240x60.02" 9.434986 448 472 520 600 240 242 245 262 -HSync -VSync
ModeLine "376x240x60.02" 7.799589 376 392 432 496 240 242 245 262 -HSync -VSync
ModeLine "384x288x51.14" 7.937999 384 400 440 504 288 289 292 308 -HSync -VSync
ModeLine "368x224x60.02" 7.673789 368 384 424 488 224 234 237 262 -HSync -VSync
ModeLine "360x224x60.02" 7.547989 360 376 416 480 224 234 237 262 -HSync -VSync
ModeLine "496x224x60.02" 10.189785 496 520 568 648 224 234 237 262 -HSync -VSync
ModeLine "320x192x60.02" 6.667390 320 336 368 424 192 218 221 262 -HSync -VSync
ModeLine "464x224x60.02" 9.686586 464 488 536 616 224 234 237 262 -HSync -VSync
ModeLine "480x224x60.02" 9.938186 480 504 552 632 224 234 237 262 -HSync -VSync
ModeLine "432x224x59.00" 8.821680 432 448 488 560 224 237 240 267 -HSync -VSync
ModeLine "352x256x57.07" 7.434000 352 368 408 472 256 257 260 276 -HSync -VSync
ModeLine "680x224x60.02" 13.963780 680 712 776 888 224 234 237 262 -HSync -VSync
ModeLine "712x288x50.00" 14.742000 712 744 816 936 288 293 296 315 -HSync -VSync
ModeLine "680x288x50.00" 13.986000 680 712 776 888 288 293 296 315 -HSync -VSync
ModeLine "400x288x50.00" 8.190000 400 416 456 520 288 293 296 315 -HSync -VSync
ModeLine "704x240x60.02" 14.592778 704 736 808 928 240 242 245 262 -HSync -VSync
ModeLine "296x224x60.02" 6.289991 296 312 344 400 224 234 237 262 -HSync -VSync
ModeLine "416x256x57.07" 8.568000 416 432 472 544 256 257 260 276 -HSync -VSync
ModeLine "680x480x60.13" 13.963604 680 712 776 888 480 483 489 523 -HSync -VSync interlace
ModeLine "288x240x60.02" 6.038391 288 304 336 384 240 242 245 262 -HSync -VSync
ModeLine "640x256x57.07" 13.104000 640 664 728 832 256 257 260 276 -HSync -VSync
ModeLine "544x224x60.02" 11.196184 544 568 624 712 224 234 237 262 -HSync -VSync
ModeLine "432x256x57.07" 8.820000 432 448 488 560 256 257 260 276 -HSync -VSync
ModeLine "352x224x60.02" 7.422189 352 368 408 472 224 234 237 262 -HSync -VSync
ModeLine "544x256x57.07" 11.214000 544 568 624 712 256 257 260 276 -HSync -VSync
ModeLine "464x256x57.07" 9.702000 464 488 536 616 256 257 260 276 -HSync -VSync
ModeLine "720x480x60.00" 14.868000 720 752 824 944 480 484 490 525 -HSync -VSync interlace
ModeLine "648x240x60.02" 13.208981 648 672 736 840 240 242 245 262 -HSync -VSync
ModeLine "736x264x55.46" 15.120000 736 768 840 960 264 265 268 284 -HSync -VSync
ModeLine "312x288x51.14" 6.551999 312 328 360 416 288 289 292 308 -HSync -VSync



[Calamity]

I have good news with Switchres, it's working DAMNED WELL!! I've just tested it with Soft15Khz modes, and it's actually performing dynamic modelines with it, so I'm testing non 60Hz games and they're running at their original refresh, 55, 57.55, 58 Hz, etc.

With a richer mode list it's going to be perfect, because I'm seeing some issues, for instance with 384x224@59.xxx, as it goes for the existing 384x288@60 (the only with 384 pixels width) which due to this monitor limitations cannot go any further than 54Hz because of its extreme yres, so the game is unnecesarily slowed. But it's just a matter of doing a decent list. I believe that even with the default 60 modes available in Catalyst we could do something interesting. With my patched Catalyst that is able to manage up to 134 modes, I believe it will be enough.

There's some stuff to work out as how to deal with virtualized modes, as monitor's type is something that's going to determine the list of needed modes so it will have to be considered at first hand when doing the table.

I'm seeing some issues also with virtualized modes, as the streching is not properly passed to Mame, you have to use hwstretch 0/1 in regular Mame. The cleanstretch option is a CabMame one and is additional to the other, but don't know if it is a good idea to use that in the virtualize context (anyway it only works with -video d3d, not needed with -video ddraw).

It's important to remember to rename the Mame ini folder, otherwise I will use the options in them.
There's also a point that could be checked, I normally use 'resolution0' instead of plain 'resolution', it's working here with both but see all the programs doing inis use both simultaneously. I believe the correct way would be to really consider which device to point to (0/1), however, we can leave that by now.

On the other hand, livecd32_12-13-2010_01_25_54.iso still fails when -video opengl is used, works ok with -video soft. The screen goes black and I have to CTRL+C from the cosole to bring it back

[bitbytebit]

I have good news with Switchres, it's working DAMNED WELL!! I've just tested it with Soft15Khz modes, and it's actually performing dynamic modelines with it, so I'm testing non 60Hz games and they're running at their original refresh, 55, 57.55, 58 Hz, etc.

With a richer mode list it's going to be perfect, because I'm seeing some issues, for instance with 384x224@59.xxx, as it goes for the existing 384x288@60 (the only with 384 pixels width) which due to this monitor limitations cannot go any further than 54Hz because of its extreme yres, so the game is unnecesarily slowed. But it's just a matter of doing a decent list. I believe that even with the default 60 modes available in Catalyst we could do something interesting. With my patched Catalyst that is able to manage up to 134 modes, I believe it will be enough.

There's some stuff to work out as how to deal with virtualized modes, as monitor's type is something that's going to determine the list of needed modes so it will have to be considered at first hand when doing the table.

I'm seeing some issues also with virtualized modes, as the streching is not properly passed to Mame, you have to use hwstretch 0/1 in regular Mame. The cleanstretch option is a CabMame one and is additional to the other, but don't know if it is a good idea to use that in the virtualize context (anyway it only works with -video d3d, not needed with -video ddraw).

Yeah I didn't know how in Windows that exactly was done, think I need to add the hwstretch option then and only use cleanstretch with that if using the patched/cabmame version.  In Linux seems unevenstretch covers both of those options I guess.

That genres.pl script hopefully by taking the monitor in account and using switchres in theory should be able to figure out all the possible virtualized modes it would go through.

It's important to remember to rename the Mame ini folder, otherwise I will use the options in them.
There's also a point that could be checked, I normally use 'resolution0' instead of plain 'resolution', it's working here with both but see all the programs doing inis use both simultaneously. I believe the correct way would be to really consider which device to point to (0/1), however, we can leave that by now.

Yeah I didn't know for sure, seemed to be just doing resolution covers all the monitor outputs and 0/1 cover specific monitors.  It seems unclear which is the 'right' way, at least in Linux it doesn't really even make sense to use anything else because it doesn't even support multiple monitors but in Windows maybe resolution0 is the best one? or resolution to cover all, seems weird to have to do both and I always assumed those scripts are just doing something unnecessary but I may be wrong.  (probably looking at the source awhile would answer things for certain, I haven't looked too closely except for the Linux side more than Windows and remember that it doesn't really matter in Linux and don't remember what I saw for Windows).

On the other hand, livecd32_12-13-2010_01_25_54.iso still fails when -video opengl is used, works ok with -video soft. The screen goes black and I have to CTRL+C from the cosole to bring it back

Ah dang, yeah maybe trying to do the 'eselect opengl list' and then eselect opengl set 1 or 2 and trying both OpenGL builds, see if that does anything different.  So mame basically is hanging it sounds like and holding things in the in-between state of switching to graphics output (but is in the state because the mouse shows?).  Also possibly check the xorg.conf and change the video driver to use "ati" instead of radeon, something to try, and if not that then try it by running the create_xorg-dyn.pl <monitor_type> script and redirect that output to xorg.conf.  It may be an xorg configuration issue, I'm not sure though.  It's just strange that card acts so different than mine does, yet sounds like exactly what mine did/does when giving it vertical active lines not aligned to 8 lines.  Also seeing what happens on your AVGA card may be interesting, seeing if it's just that card and the AVGA works better now with this latest ISO. 

I'll look deeper into OpenGL, any interesting things/logs you see let me know, and I'll explore it some more. 

[bitbytebit]

Uploaded SwitchResWin-1.124-e69707d.7z Windows build that uses the hwstretch option too, no longer either/or with cleanstretch like before.  Also am using both resolution and resolution0 to be safe and duplicate the .ini files behaviors.

[Calamity]

I'll keep testing. There's something I've seen, when the screen is black I still have the sync leds on in the jpac, so the mode switching is performed properly, it's just that it hangs after that. I've also tested glxgears and it propmts normal stuff to the console but shows starts a window with nothing inside, just a black background, I suppose there should be something showing there. Then when I kill that window I get the same error message in the console as when I do CTRL+C in the Mame case. If I do glxgears -fullscreen it just goes full screen with the mouse cursor only on a black background, I have to kill this too as there's no way to exit (ALT+TAB does work however, it does not with Mame).

Could this be due to the need of also specifying the target device inside OpenGL? I don't know if this make any sense at all, but I do use that stuff with DirectX. After all, having the same card, the only difference I can think about is the monitor part again...

[bitbytebit]

I'll keep testing. There's something I've seen, when the screen is black I still have the sync leds on in the jpac, so the mode switching is performed properly, it's just that it hangs after that. I've also tested glxgears and it propmts normal stuff to the console but shows starts a window with nothing inside, just a black background, I suppose there should be something showing there. Then when I kill that window I get the same error message in the console as when I do CTRL+C in the Mame case. If I do glxgears -fullscreen it just goes full screen with the mouse cursor only on a black background, I have to kill this too as there's no way to exit (ALT+TAB does work however, it does not with Mame).

Also check this command out, 'eselect mesa list' and possibly run eselect set <number> to switch from classic to gallium and back. (need to be root for this, sudo -s).  That looks interesting, just found that can be changed.

Update:
Looks like that command won't actually switch on the LiveCD since it's a read only file system.  I'll look at this more and see what the difference is exactly, and build an ISO with this switched to gallium possibly (odd because I thought it was defaulting to gallium, but seems to be classic).

[bitbytebit]

I'll keep testing. There's something I've seen, when the screen is black I still have the sync leds on in the jpac, so the mode switching is performed properly, it's just that it hangs after that. I've also tested glxgears and it propmts normal stuff to the console but shows starts a window with nothing inside, just a black background, I suppose there should be something showing there. Then when I kill that window I get the same error message in the console as when I do CTRL+C in the Mame case. If I do glxgears -fullscreen it just goes full screen with the mouse cursor only on a black background, I have to kill this too as there's no way to exit (ALT+TAB does work however, it does not with Mame).

Could this be due to the need of also specifying the target device inside OpenGL? I don't know if this make any sense at all, but I do use that stuff with DirectX. After all, having the same card, the only difference I can think about is the monitor part again...

Couple of things to try:

Try to turn off the hiscore patch, actually do that for now since there seems to be an odd bug in the SDL part of it and it messes with the OpenGL stuff
  /home/arcade/mame.ini -  disable_hiscore_patch 1

Try changing some of the opengl values in mame.ini, see if turning on filtering, or if turning off the -gl_notexturerect stuff
 


I've possibly done some stuff that might help, but still looking at this and also am going  to try to add the newest DRM/KMS page flipping support too.  That way the next update hopefully will be really a big step forward and I might figure some stuff out too by then. 

[Calamity]

Hi bitbytebit,

I've been doing all kind of tests editing mame.ini, all opengl options I've imagined, filters, screen, turning off vsync, but the issue is still there. As you said, these eselect commands are failing for the readonly file system. I also have a problem with this version not being able to get in ldex when I try to activate eth0, it just gets stuck in a black screen after the config terminal exits and I have to turn off the machine. That also happens if I try to mount a drive. I believe this stuff with the drives, not the network, has been there from previous versions, and may be the reason that I haven't been able to mount a drive yet, but at the beginning I was confused with the other issues, if only I had more experience with this system I could provide you with better feedback. So I keep stuck with this, it could be something silly with my machine, though I never had a problem before, however these days hopefully I'm going to test this on the AVGA cab. As I can't get the network working nor plug a usb stick I can't send you the logs, I've copied by hand some of the output of switchres invoking mame.

Here it's reporting an audio error (btw I haven't been able to have audio working with any live-cd I have tested, not only arcade gentoo). This shouldn't be the cause, but just in case:

Audio: Start initialization
Audio: Driver is
Audio: Initialization failed. SDL error: No available audio device
output: unable to open output notifier file /tmp/sdl_out

[...]

OpenGL: VBO supported
OpenGL: PBO supported
OpenGL: FBO supported
OpenGL: using vid filter: 0
GL texture: copy 1, shader 0, dynamic 1, 256x240 256x240 [PALETTE16, Equal: 0, l: 0, Palette, 1,
            scale 1x1, border 0, pitch 320,256/8192], colors: 2048, bytes/pix 4

... that's the end of the output, right after there it dies.

[bitbytebit]

Hi bitbytebit,

I've been doing all kind of tests editing mame.ini, all opengl options I've imagined, filters, screen, turning off vsync, but the issue is still there. As you said, these eselect commands are failing for the readonly file system. I also have a problem with this version not being able to get in ldex when I try to activate eth0, it just gets stuck in a black screen after the config terminal exits and I have to turn off the machine. That also happens if I try to mount a drive. I believe this stuff with the drives, not the network, has been there from previous versions, and may be the reason that I haven't been able to mount a drive yet, but at the beginning I was confused with the other issues, if only I had more experience with this system I could provide you with better feedback. So I keep stuck with this, it could be something silly with my machine, though I never had a problem before, however these days hopefully I'm going to test this on the AVGA cab. As I can't get the network working nor plug a usb stick I can't send you the logs, I've copied by hand some of the output of switchres invoking mame.

Here it's reporting an audio error (btw I haven't been able to have audio working with any live-cd I have tested, not only arcade gentoo). This shouldn't be the cause, but just in case:

Audio: Start initialization
Audio: Driver is
Audio: Initialization failed. SDL error: No available audio device
output: unable to open output notifier file /tmp/sdl_out

[...]

OpenGL: VBO supported
OpenGL: PBO supported
OpenGL: FBO supported
OpenGL: using vid filter: 0
GL texture: copy 1, shader 0, dynamic 1, 256x240 256x240 [PALETTE16, Equal: 0, l: 0, Palette, 1,
            scale 1x1, border 0, pitch 320,256/8192], colors: 2048, bytes/pix 4

... that's the end of the output, right after there it dies.

Yeah I'm hoping the changes I made to the OpenGL compile might help, added some compile time options and if that doesn't work then might try older versions or something.  The drive/network stuff, black screen, might be better in the next version but not sure.   The audio issue sounds like your sound card might be one that Linux doesn't support or needs something special like firmware or another different type of configuration option.  That might be something solvable eventually with possibly looking at the logs more, but for now will worry more about the video output the audio device in SDL looks like it just doesn't see it, what kind of sound card is in the machine?

Good news is I have just gotten a running version of the newest Linux kernel working with the page flipping support enabled, with the line accuracy vsync now and it definitely looks nice.  It seems they enabled the vblank interrupts and are using them now, so that's a good thing but definitely need to figure out the video card support in general before can see that :/.

I'll have a new ISO build up in a few hours hopefully, or maybe tomorrow, and you can see how this new OpenGL compile and the newer DRM kernel act.  



Update:
Also this might help some, the Gentoo Linux handbook which basically is the Manual telling how to install/do about anything you need.  So may help at least as a reference when you see an issue, look the topic for it up of what generally is happening and it tells how to setup every aspect of a Linux/Gentoo system.

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1

[bitbytebit]

One thing I'm wondering, do we even need OpenGL to do the vsync for us if the actual Atom Bios and Kernel DRM layer through the X Server/Driver are following the vblank/sync?  It is one thing I don't fully grasp, how the vsync stuff worked but the page flipping on the actual radeon card wasn't active yet.  Now it is, and besides accuracy I'm wondering what else that gains for us.  Wondering if OpenGL was emulating what now should just be happening in X itself, had read something awhile back where someone said the right place to do it was in Xorg and that was being worked on and OpenGL was just making up for the lack of that.

[bitbytebit]

I'm uploading a new 32 bit version now, LiveCD32-Minimal-1.133-aff4e1c.iso (will take a few hours), and 64 bit one after that.  From what I can tell this page flip support is quite amazing because I had debugging on and it turned out with page flipping it was logging to the logfile every page flip.  Amazingly things were mostly ok doing that still, noticed only because the most intense games hit the CPU at 99%.  So if it could handle that type of abuse to a live CD setup, and seeing how the page flipping worked since it was logging every flip, seems pretty promising.

If this one still has issues with the OpenGL, will have to dig into what that texture part is it always gets stuck at.  That is something I've seen, same place when it was sticking on the non 8 line aligned vertical height.  Seems there might be some Mame/SDL specific OpenGL bug there or touchy part of code which for some reason your card is hitting and other odd tests I've done with mame have hit that too in the past.

[Calamity]

Thanks for the link, I'll have a look.

One thing I'm wondering, do we even need OpenGL to do the vsync for us if the actual Atom Bios and Kernel DRM layer through the X Server/Driver are following the vblank/sync?  It is one thing I don't fully grasp, how the vsync stuff worked but the page flipping on the actual radeon card wasn't active yet.  Now it is, and besides accuracy I'm wondering what else that gains for us.  Wondering if OpenGL was emulating what now should just be happening in X itself, had read something awhile back where someone said the right place to do it was in Xorg and that was being worked on and OpenGL was just making up for the lack of that.

Vsync is a low level feature. So in Windows, the scheme (as I understand it) should be the driver running in ring 1 directly dealing with hardware, so performing the actual low level stuff needed for vsync (doing a loop to read a hardware port for a given value, interrupts, or whatever is done today for vsync), then over that the DirectX/OpenGL layer providing the applications running in ring 3 (Mame) with methods to access those driver features. In Linux the scheme seems different and as I said I don't exactly know which different parts of the system are interfacing with hardware. However, it could be that the DRM was already supporting vsync, but not page flipping, that's a different thing. I believe page flipping is implemented by dynamically modifying the hardware offset that points to the start of framebuffer's video memory, so with next refresh the contents of the screen are completely modified without the need to perform a memory copy, therefore with zero overhead. Without page flipping, one could do vsync as long as the system provides with a method to read the vblank state, but would need to sit waiting there until that happens to quickly do a memory copy to vram before the electron beam reaches the top of the screen. On the other hand, without vsync, one could do page flipping, but would have tearing. So both things are used combined.

[bitbytebit]

Thanks for the link, I'll have a look.

One thing I'm wondering, do we even need OpenGL to do the vsync for us if the actual Atom Bios and Kernel DRM layer through the X Server/Driver are following the vblank/sync?  It is one thing I don't fully grasp, how the vsync stuff worked but the page flipping on the actual radeon card wasn't active yet.  Now it is, and besides accuracy I'm wondering what else that gains for us.  Wondering if OpenGL was emulating what now should just be happening in X itself, had read something awhile back where someone said the right place to do it was in Xorg and that was being worked on and OpenGL was just making up for the lack of that.

Vsync is a low level feature. So in Windows, the scheme (as I understand it) should be the driver running in ring 1 directly dealing with hardware, so performing the actual low level stuff needed for vsync (doing a loop to read a hardware port for a given value, interrupts, or whatever is done today for vsync), then over that the DirectX/OpenGL layer providing the applications running in ring 3 (Mame) with methods to access those driver features. In Linux the scheme seems different and as I said I don't exactly know which different parts of the system are interfacing with hardware. However, it could be that the DRM was already supporting vsync, but not page flipping, that's a different thing. I believe page flipping is implemented by dynamically modifying the hardware offset that points to the start of framebuffer's video memory, so with next refresh the contents of the screen are completely modified without the need to perform a memory copy, therefore with zero overhead. Without page flipping, one could do vsync as long as the system provides with a method to read the vblank state, but would need to sit waiting there until that happens to quickly do a memory copy to vram before the electron beam reaches the top of the screen. On the other hand, without vsync, one could do page flipping, but would have tearing. So both things are used combined.

Yeah from what I read it seems that it's like Windows and this give that hardware page flip support in the driver, with Mesa/OpenGL taking advantage of it with the current vsync ability through the SDL part of Mame.  So it basically I guess makes it a lot more efficient and avoid tearing even more than before. 

It's interesting with this oddity with vertical games now, the sides of the screen are full of garbage frame buffer stuff since it doesn't update that part I guess.  I'm looking deeper into the code to see if there's something Mame could do, while hoping the Alex guy from AMD will respond with good news and know how to fix it there.  Suspect it's some oversight in the page flip code, but it's interesting too because it makes sense from how page flipping works.  I wonder if it's an odd case of how mame does vertical games and only updates the game screen and the sides are kind of on their own.  I can see how that's definitely a performance improvement, would think the frame buffer would be able to keep itself clear on each page flip though without overhead, or maybe not.  Also that's making me look at the Mame code with OpenGL which is where you see the hangs, hopefully fixed in the latest ISO but am being cautious since I of course am just guessing and hoping the changes I made help it.  Figure if I really get to know that OpenGL code in Mame better it might help me find what could cause issues, probably look at the Mesa OpenGL code from there too.  Definitely interesting, I've been wanting to look at that since I did some of the hacking at the 1.3 SDL parts to get it working and did get somewhat familiar with how it works.  It's interesting that it stops at the texture copy stuff, which is something that some of those mame options say they change but not sure if it's that part it avoids.  Also seems that means it's trying some part of OpenGL your card/chip isn't wanting to do, might mean at a lower level the kernel driver isn't fully enabling it so maybe the newer kernel changes have a chance helping it from that aspect then.  Going backwards in Mesa versions seems like a last resort, so waiting for that, since it gets tricky doing that and still supporting the newer Xorg stuff which we need for vsync to work at all or page flipping.

[Calamity]

I'm burning the new 'minimal' version right now, will be testing in a while.

That garbage issue sounds like the buffer is not being cleared before it's used, maybe because the cleaning function invoked from Mame right after creating that buffer is not working any more due to the OpenGL version change (the buffer could not be ready yet when trying to clear it), I've seen similar issues with DirectX, I believe due to the small changes in behavior from version to version that make code that has always worked well stop working.

[bitbytebit]

I'm burning the new 'minimal' version right now, will be testing in a while.

That garbage issue sounds like the buffer is not being cleared before it's used, maybe because the cleaning function invoked from Mame right after creating that buffer is not working any more due to the OpenGL version change (the buffer could not be ready yet when trying to clear it), I've seen similar issues with DirectX, I believe due to the small changes in behavior from version to version that make code that has always worked well stop working.

I *think* I figured the garbage issue out (at least a work around if it is fixable at the kernel level), am compiling to test my theory.  I found that the screen clear only happens on screen resizes or vector games.  I'm not sure but am checking to see if putting that clear at the initialization fixes it.  It's non-changing garbage so seems only one single clear would remove if, if it cleared the entire screen and not just the visible area.  At least can kind of see something I think, but will be able to run tests quicker once I get mame compiled and then won't take so long per change in the source to hack around with it.

[Calamity]

Well, something interesting. This version does not hang any more. It starts Mame normally, switches video mode, BUT: it runs incredibly slow, 5-6% of speed in all games. I've seen logs and it just the same than before but now the texture lines are for or five and it does not stop there any more. The input lag is so high I have to quickly press esc to get out, otherwise it gets stuck with the game running.

[bitbytebit]

Well, something interesting. This version does not hang any more. It starts Mame normally, switches video mode, BUT: it runs incredibly slow, 5-6% of speed in all games. I've seen logs and it just the same than before but now the texture lines are for or five and it does not stop there any more. The input lag is so high I have to quickly press esc to get out, otherwise it gets stuck with the game running.

Check if the /var/log/messages file has any information in it, may be over logging (or output of running 'dmesg').

I fixed the junk stuff on the frame buffer, it's quite interesting, I guess there's now an extra buffer and it's sort of triple buffering perhaps.  I had to increase the number of clear times from two to three, now it's fine (has to run a clear per buffer used I guess).

Code: [Select]

diff -ru --exclude=obj --exclude='*.rej' --exclude='*.orig' ../mame_u2_ga/src/osd/sdl/drawogl.c ./src/osd/sdl/drawogl.c
--- ../mame_u2_ga/src/osd/sdl/drawogl.c 2010-12-11 12:07:43.073333333 -0600
+++ ./src/osd/sdl/drawogl.c 2010-12-15 13:58:22.649966300 -0600
@@ -3225,7 +3225,7 @@
  sdl_info *sdl = (sdl_info *) window->dxdata;
 
  //FIXME: Handled in drawogl_window_draw as well
- sdl->blittimer = 2;
+ sdl->blittimer = 3;
 }

At least can include that fix now in the next ISO.



Definitely not part of the issue your seeing though, seems like an over logging issue but then again maybe something to do with the opengl still.


Also try to run `top` in a terminal window before running mame, see if there's anything eating the CPU that's running.  In top you can do Shift+P to see the CPU processes first, and 'q' to exit out of top. 

[Calamity]

I forgot to say it runs fine with video soft option.

[bitbytebit]

I forgot to say it runs fine with video soft option.

How does glxgears run, does it do something similar?  How many FPS does it run at, and does it say it's locked to the refresh rate?  What is the Mesa version and OpenGL version it reports with glxinfo?  That at least will isolate it to either mame or OpenGL.

Seems like we're getting closer, and it will be interesting seeing if things run well on your other cab now with the AVGA card.  If so it'll mean there's probably something bad about the interaction between the current Mesa OpenGL and that specific card.  Although really odd because I went through again the logs you sent of mame startup and your card is identical to mine and even your mame startup, weird.

[Calamity]

glxgears says running synchronized to the vertical refresh. The frame rate should be approximately the same as the monitor refresh rate... but the glxgears window shows nothing but a black backgroud (should I see something inside that Window?) so I have to close it, and then it prompts the "X10 Fatal IO error 11 (resource temporarily unavailable)...

glxinfo says GLX version 1.4, 2.1 Mesa 7.10-devel

top shows processes running but pressing shift+p several times I can't see any of them using more that 2-3% of cpu.

That tripplebuffer behavior makes a lot of sense with page flipping so it seems this SDL Mame is still behind of current OpenGL implementations, could it be the issue?

[bitbytebit]

glxgears says running synchronized to the vertical refresh. The frame rate should be approximately the same as the monitor refresh rate... but the glxgears window shows nothing but a black backgroud (should I see something inside that Window?) so I have to close it, and then it prompts the "X10 Fatal IO error 11 (resource temporarily unavailable)...

glxinfo says GLX version 1.4, 2.1 Mesa 7.10-devel

top shows processes running but pressing shift+p several times I can't see any of them using more that 2-3% of cpu.

That tripplebuffer behavior makes a lot of sense with page flipping so it seems this SDL Mame is still behind of current OpenGL implementations, could it be the issue?

Interesting, so it's still the same issue but is pointing to Mesa/OpenGL just not playing well with the hardware for some reason.  I'm not sure about how the Mesa version plays into the mame version and also if older Mesa versions matter or not with the vsync and page flipping.  I suspect though older versions shouldn't matter as long as they work nicely with Xorg, although it's definitely a bit confusing since it's the same video card and I'm not sure what extra variable is changing how OpenGL reacts (or what could, maybe the mother board or processor perhaps, compile flags, SSE support or MMX type stuff).  The newer Gallium stuff probably won't work any better, I actually tried it here and it failed to run mame or glxgears, although not sure if possibly it was a build issue.  I'll look for more ideas, test an older Mesa version and see if it allows everything to work still and the newer Xorg likes it.  I guess it'll be interesting to see how the other AVGA card and cab act, so if I don't get something by then at least that'll hopefully show something if that card acts better.  Since it's a whole other GPU it's interesting to see, although definitely wondering what else on a Radeon card could change the behavior between ours.  Does your possibly have a different BIOS than mine, do you know what the specs are of the memory on it and stuff? 

Running `sudo grep drm /var/log/dmesg` might be interesting to see the specs of the card.

[Calamity]

I'll check that now. Mine is an Asrock Intel board, audio integrated, I think it might be something colateral, not the videocard.

UPDATE: Same as yesterday, the system gets stuck before loading ldex if I boot with the network cable, so I can't get the logs for you.
Something interesting however, when running dmesg after exiting Mame, the log is full lines saying "hda-intel: spurious response 0x0:0x0, last cmd=0x3f0012 (and similar ones).

Definitely tomorrow I'll test this with the other cab.

This is my motherboard:

http://www.asrock.com/mb/overview.asp?Model=4COREDUAL-SATA2%20R2.0

[bitbytebit]

I'll check that now. Mine is an Asrock Intel board, audio integrated, I think it might be something colateral, not the videocard.

UPDATE: Same as yesterday, the system gets stuck before loading ldex if I boot with the network cable, so I can't get the logs for you.
Something interesting however, when running dmesg after exiting Mame, the log is full lines saying "hda-intel: spurious response 0x0:0x0, last cmd=0x3f0012 (and similar ones).

Definitely tomorrow I'll test this with the other cab.

This is my motherboard:

http://www.asrock.com/mb/overview.asp?Model=4COREDUAL-SATA2%20R2.0

Odd, yeah the audio chip in that system just might not be a great one in Linux from what I can tell, but need to look at that some. 

I'm uploading an ISO to a new `Testing/' directory, as LiveCD32-MinimalNoMM-1.140-8757967.iso which has reverted Mesa and libdrm to earlier versions.  It's a stab at seeing if that makes any difference.  Right now I'm actually pushing them back forward in my tree and going to do some testing with the newer Mesa Gallium stuff.  That's because I have found something interesting, first the Alex guy from AMD seems to think that the newest Gallium branch would be the best.  So I tested and found that with that enabled as Gallium it seems to segfault in the r600g Mesa/DRM library when running Mame.  It doesn't do this for glxgears or other applications I suspect, it seems like either an SDL/Mesa or Mame/OpenGL issue going on.  It segfaults at the  shader code, same place as you see issues.  So that seems to tell me possibly in Mame all that code which sets up OpenGL shaders is somehow a bit buggy and the Gallium stuff triggers similar to what you've seen.   I'm just not sure why you can trigger it without Gallium enabled, but I'm thinking it's still related someway.  I am learning more about how the Gallium/Classic Mesa/OpenGL is setup, differences and there's a few different branches in GIT too (the main branch constantly is adding/changing by the minute, it's a quite active development, yet Alex says it's fine and I do sort of believe him). 

So when that ISO is done uploading, would be interesting to test it, just to see if reverting to the 7.9 branch of Mesa works instead of the 7.10 currently active development one. 

I'm compiling a debug build of mame and opengl with gdb on a LiveCD and am going to try to chase this segfault in mame from Gallium down, which I just get the feeling if that is fixed it might fix your issue too plus allow us to use Gallium which is supposed to be the recommended OpenGL branch/mode now.

[Calamity]

I've finally tested the cd on the AVGA cab, and unfortunately can't get to the desktop there, it's quite similar to what I've been suffering in the other cab, with first mode switch I get a split screen, but can still see it thanks to jpac. Then the screen gets perfect when it loads the terminal for the setup menu, I go through the setup, but then, when it should display the lxde desktop, I get out of video (sync led off on jpac). I've tested first of all CGA + First VGA, but as it didn't work have also tried CGA + DVI, PAL + DVI, etc., without success. So we are still stuck in a previous stage with this cab, not being able to get to the desktop and test opengl. However, I can go to the console pressing CTRL + F1, and I've taken a picture of the screen, in case it could be useful (have a look at the line "disable primary dac", should that be there?):

[bitbytebit]

I've finally tested the cd on the AVGA cab, and unfortunately can't get to the desktop there, it's quite similar to what I've been suffering in the other cab, with first mode switch I get a split screen, but can still see it thanks to jpac. Then the screen gets perfect when it loads the terminal for the setup menu, I go through the setup, but then, when it should display the lxde desktop, I get out of video (sync led off on jpac). I've tested first of all CGA + First VGA, but as it didn't work have also tried CGA + DVI, PAL + DVI, etc., without success. So we are still stuck in a previous stage with this cab, not being able to get to the desktop and test opengl. However, I can go to the console pressing CTRL + F1, and I've taken a picture of the screen, in case it could be useful (have a look at the line "disable primary dac", should that be there?):

Try to specify the 'generic' monitor type on the setup.  Since the setup loads, it's running X fine at that point it seems.  It sounds like it's fouling up at using a h9110 modeline for the desktop.  So see if the generic one, which it's using to load in the first place, helps at all.

[Calamity]

Try to specify the 'generic' monitor type on the setup.  Since the setup loads, it's running X fine at that point it seems.  It sounds like it's fouling up at using a h9110 modeline for the desktop.  So see if the generic one, which it's using to load in the first place, helps at all.

It's already using the generic monitor (that's what it shows when loading stuff), ah.. ok you mean to select that on the setup... However I think it's not that, it's the connection issue again, I have no video, not a bad modeline. I'm pretty sure this is the same I was seeing before with the other cab, before you fixed it somehow, I was also seeing the setup but not the desktop. Something strange: I can see there VGA-0 and VGA-1 though the second connection should be DVI.

[bitbytebit]

Try to specify the 'generic' monitor type on the setup.  Since the setup loads, it's running X fine at that point it seems.  It sounds like it's fouling up at using a h9110 modeline for the desktop.  So see if the generic one, which it's using to load in the first place, helps at all.

It's already using the generic monitor (that's what it shows when loading stuff), ah.. ok you mean to select that on the setup... However I think it's not that, it's the connection issue again, I have no video, not a bad modeline. I'm pretty sure this is the same I was seeing before with the other cab, before you fixed it somehow, I was also seeing the setup but not the desktop. Something strange: I can see there VGA-0 and VGA-1 though the second connection should be DVI.

Ah, possibly in your home /home/arcade/ directory there's a file, .xinitrc, and in there remove the line referencing /usr/local/bin/outputs.pl
which may be causing the issue I *think*.  Also are you choosing the VGA menu option for that cab, suspect it'll need to go out only on that
first VGA connection on the AVGA which is what the second option chooses.  Although that script is part of the problem possibly too, but both
issues may be connected.

[Calamity]

Yes, I'm using the VGA option at the boot menu, also tested the others just in case. So I suppose I should CTRL + F2 and from there kill the desktop somehow (?), edit .xinitrc and restart the desktop (fvwm?).

[bitbytebit]

Yes, I'm using the VGA option at the boot menu, also tested the others just in case. So I suppose I should CTRL + F2 and from there kill the desktop somehow (?), edit .xinitrc and restart the desktop (fvwm?).

Actually an easier way would be to change in while in setup.  Basically right when it asks you the monitor type, open another xterm and edit that .xinitrc file to not include that outputs.pl line.  Then go ahead and choose the monitor type, then it should hopefully all startup without it, since running it at all may be a bad thing.  Otherwise you could from the second console edit it, and run `killall xinit`, or switch to the first console and push Ctl+C from there.

[bitbytebit]

It's interesting because I'm isolating an issue at the point where it hangs for you, or gets slow at least.  It's weird because it happens when I enable Gallium, it segfaults at the exact point yours either hangs or gets slow/screen goes black (on the 4350 at least).  I'm getting my liveCD build in a test mode with all the layers of mame->sdl->opengl->dri to have symbols and able to debug/backtrace on them.  I have gotten a backtrace up through mame but it didn't have enough symbols to show me more than the function names in the OpenGL libraries in Mesa for the r600g.so module being the culprit.  I hopefully can pinpoint this, I get the feeling if it's fixed and Mesa can use Gallium then things might just work well for you on the 4350 as well as we would be able to use the actively developed Mesa code (classic is depreciated now). 

So I am close I think to getting a backtrace today, possibly filing a bug on the drm lists if I don't figure out how to fix it myself.  Hopefully leads to the 4350 and Mame working even better, since it works for me in Classic mode but I suspect what your seeing and what I am seeing with Gallium enabled points to something touchy and unstable in there somewhere.  It's taking awhile, but I am seeing why finally, this whole Mesa OpenGL/SDL and Mame combination is quite a beast and then add the drm library with kernel mode KMS and Xorg drivers.  It's just a large amount of layers there having to work together, and all very new as of the last 6 months basically.  It'll be worth it because they've made great improvements, which I've seen here, but seems getting this all stable and working on all cards in a 'set' with mame utilizing all of the layers is going to take some time.

[Calamity]

It will be interesting to have those logs working to figure what's going on. By now I can't use the network so if it's necessary I'll take pictures of the monitor to show you the messages

Well, I've doing some tests with the AVGA cab. Removing the /usr/local/bin/outputs.pl line has worked! I did it before selecting h9110 in the setup, then the desktop loaded perfectly. And finally could run glxgears and see the gears moving! So ironically the new stuff is working better on the 9250 than on the 4350. But when I run mame (through switchres) the mode switching was not working, instead the 256x240 frame was showing as a small box on the left top corner on the desktop, the game running perfectly however, and then, when exiting, the whole desktop is set to 256x240. I imagine this is a side effect of removing outputs.pl, and it should be working otherwise (provided the video was on, of course) as I see an error message when exiting Mame saying it can't get back to 640x480, and xrandr --current says both VGAs are disconnected. I've also tested the noMM iso here and it's the same with it. So it could a matter of modifying outputs.pl somehow to still have video and xrandr working again. It's remarkable that the console video mode still doesn't work with this card, it's outputing 31 Khz there, something that is definitely fixed on the 4350.

Back with the 4350, I've tested noMM iso with exactly the same results I had with the new one yesterday, so going to a previous version does not fix things. However, I've seen something interesting today, that was indeed there also yesterday, but I didn't report it as it was so strange I thought it was an error with my tests. When the desktop loads for the first time, I go to the terminal and run switchres gridlee, the screen goes black and I have to CTRL+C to go back to the desktop. It's the second time I run switchres from the terminal when the game actually loads, but I get that slooow frame rate of 2-3%. So it needs to get hang a first time to be able to run later, but something must result corrupted when exiting with CTRL+C that somehow allows it to run later but very slow... glxgears still shows a black window and have to CTRL+C it also to exit. Mode switching however works flawlessly with this cab.

It would be good to have more people testing this to check with other machines also. I'm starting to think that the new kernel could have some troubles dealing with my motherboard, as I have also those other strange problems with the integrated network card, and of course the audio chip, and maybe that's making the system fail somehow. I could try to trace back the problem because I was actually able to use the network before, but haven't been anymore since some versions ago.

[bitbytebit]

It will be interesting to have those logs working to figure what's going on. By now I can't use the network so if it's necessary I'll take pictures of the monitor to show you the messages

Well, I've doing some tests with the AVGA cab. Removing the /usr/local/bin/outputs.pl line has worked! I did it before selecting h9110 in the setup, then the desktop loaded perfectly. And finally could run glxgears and see the gears moving! So ironically the new stuff is working better on the 9250 than on the 4350. But when I run mame (through switchres) the mode switching was not working, instead the 256x240 frame was showing as a small box on the left top corner on the desktop, the game running perfectly however, and then, when exiting, the whole desktop is set to 256x240. I imagine this is a side effect of removing outputs.pl, and it should be working otherwise (provided the video was on, of course) as I see an error message when exiting Mame saying it can't get back to 640x480, and xrandr --current says both VGAs are disconnected. I've also tested the noMM iso here and it's the same with it. So it could a matter of modifying outputs.pl somehow to still have video and xrandr working again. It's remarkable that the console video mode still doesn't work with this card, it's outputing 31 Khz there, something that is definitely fixed on the 4350.

Back with the 4350, I've tested noMM iso with exactly the same results I had with the new one yesterday, so going to a previous version does not fix things. However, I've seen something interesting today, that was indeed there also yesterday, but I didn't report it as it was so strange I thought it was an error with my tests. When the desktop loads for the first time, I go to the terminal and run switchres gridlee, the screen goes black and I have to CTRL+C to go back to the desktop. It's the second time I run switchres from the terminal when the game actually loads, but I get that slooow frame rate of 2-3%. So it needs to get hang a first time to be able to run later, but something must result corrupted when exiting with CTRL+C that somehow allows it to run later but very slow... glxgears still shows a black window and have to CTRL+C it also to exit. Mode switching however works flawlessly with this cab.

It would be good to have more people testing this to check with other machines also. I'm starting to think that the new kernel could have some troubles dealing with my motherboard, as I have also those other strange problems with the integrated network card, and of course the audio chip, and maybe that's making the system fail somehow. I could try to trace back the problem because I was actually able to use the network before, but haven't been anymore since some versions ago.

Yeah on the AVGA card I suspect it's not getting the input names right, it's odd because on boot up not going into 15khz mode says it probably is labeling the VGA input different, maybe VGA-2 instead of VGA-1 or something.  The outputs.pl script would normally turn off extra outputs, and try to enable the first one or VGA-0 (in xrandr, which is equivalent to VGA-1 for DRM kernel stuff).  I think the outputs must be oddly setup in the vbios on the AVGA card and it's abnormal, where the first input physically might not be the first one xrandr sees.   You could try the other output, and VGA then DVI mode and see if either work with outputs.pl enabled, also same with how it is now if you haven't trying DVI on it just to see.  I suspect logs would point closer to what is going on, mainly 'xrandr --current' output and the /var/log/dmesg output and/or dmesg output to see what the inputs are being mapped to on that system compared to the 4350 (maybe use an older version to see that?).  I suspect that the network/audio issues may be the kernel I'm using, hopefully they push out 2.6.37 soon and get some 2.6.38-rcX versions which are really meant for public consumption.  I am hoping that the 2.6.38 kernel is the one that we can hold at when it's released and wait till normal version changes come out after that.  They just keep fixing little DRM issues here and there right now inbetween 2.6.36 and 2.6.38, some not in 2.6.37 release candidates. 

I did get a good debug trace though, and filed a report here...

https://bugs.freedesktop.org/show_bug.cgi?id=32455

I suspect it's like what your seeing on the 4350 possibly but it just doesn't crash in your case, but there may be something Mame is doing wrong with the OpenGL buffers it passes.  It at least looks like the first one is NULL and in Gallium it crashes, in Classic it might just depend on the system state and on your it gets stuck while mine it acts just fine unless I use Gallium.

I'm going to go over that outputs.pl script some and figure out what I can improve with it, but I think it'll work if we got the right input specified at the grub command line.  If your able you could try to edit the grub command line and try VGA-2 and see if that works.  I think it might be calling DVI-I-1 VGA-1 or something odd like that.  The part about both being VGA outputs and saying they are disconnected is definitely interesting, it sounds like the one we are forcing enabled at bootup isn't the ones your seeing, and of course to force enabled at bootup we can only do one or else all are enabled then it goes haywire with all interfaces though to be connected.

[bitbytebit]

Looking at your pictures, I am now guessing that it is VGA-1 in xrandr and VGA-2 in the DRM layer/bootup which are the first output, and so it's not able to force VGA-1 on for the DRM layer and in Xorg not knowing which to choose possibly for the mode switching. 

[Calamity]

Looking at your pictures, I am now guessing that it is VGA-1 in xrandr and VGA-2 in the DRM layer/bootup which are the first output, and so it's not able to force VGA-1 on for the DRM layer and in Xorg not knowing which to choose possibly for the mode switching. 

Yes could be that, will it work if I edit the files in the iso before burning it? However I'm not sure how to modify that outputs.pl to point to the other output.

I've been reading a bit about the drm thing, I imagine it could be possible to patch that in order to provide the drm layer with a fake EDID for arcade monitors, it theory that would avoid the need of forcing displays as it would think it's autodetecting a monitor, even if plugged to the secondary device. And the EDID could provide the drm with the proper arcade modelines.

[bitbytebit]

Looking at your pictures, I am now guessing that it is VGA-1 in xrandr and VGA-2 in the DRM layer/bootup which are the first output, and so it's not able to force VGA-1 on for the DRM layer and in Xorg not knowing which to choose possibly for the mode switching. 

Yes could be that, will it work if I edit the files in the iso before burning it? However I'm not sure how to modify that outputs.pl to point to the other output.

I've been reading a bit about the drm thing, I imagine it could be possible to patch that in order to provide the drm layer with a fake EDID for arcade monitors, it theory that would avoid the need of forcing displays as it would think it's autodetecting a monitor, even if plugged to the secondary device. And the EDID could provide the drm with the proper arcade modelines.

Possibly editing the Grub command line, I think you can push 'c' at the menu for grub and it'll let you edit it (says at the bottom of grub menu).  Then the outputs.pl script might still have to be removed for now, I'll have to redo that or remove it all together possibly.

The EDID thing is confusing to me though because how would you know it's an arcade monitor since it just basically says it's found a monitor without an EDID or in the Jpac case it probably doesn't even see the monitor at all.  So you'd never know which one is the right one to choose, since I am guessing only the EDID and general signal like the Jpac happens to remove are how it could detect connected monitors.  So it's definitely a big trickier than I even though I guess, knowing which input is used and adjusting for backwards ones on the AVGA, and then to know what resolution to use plus not knowing if a person would even see the grub menu in most cases.  I'll have to think about that more, is there any way at all that we could detect a monitor in a Jpac mode besides just guessing the first input is working?  Basically my patches do similar to what your saying but don't give it an EDID but have them hard wired into the kernel as modelines for inputs we tell it are arcade monitors (and the force enable switch with that for Jpac).

[Calamity]

Of course I mean to do this for a dedicated arcade distribution, where you instruct people using it to plug their monitors to the VGA output, whatever it is the first or the second device, so you wouldn't need the grub menu, we would intercept the point where the DRM is reading the VGA DDC (we can know its the VGA from the DRM labels) and if it doesn't find it, feed the thing with a fake arcade EDID, with some basic CGA modelines to go though the startup until we load X Windows and use xrandr. It's the same you are doing but might help to sort the different outputs issue. I don't mean it would be easy to insert that there, but I believe it shouldn't be too hard to implement an EDID structure.

UPDATE: I just remembered there're cards with both DVIs as outputs...anyway.


BTW...

I think the outputs must be oddly setup in the vbios on the AVGA card and it's abnormal, where the first input physically might not be the first one xrandr sees.   You could try the other output, and VGA then DVI mode and see if either work with outputs.pl enabled, also same with how it is now if you haven't trying DVI on it just to see.

The 9250's I'm testing second output is a digital only DVI, so I couldn't plug the arcade monitor to it.