Switchres: modeline generator engine

[bitbytebit]

Does that less program try to go full screen?
I'm very far from being an expert on this but it seems unlikely there's something wrong with your compile not suiting my processor as the system seems rather stable appart from that. That IO issue definitely seems related with the problem on detecting/mapping each connection I'm experimenting. BTW this may be a different issue but reminds me VeS was doing some testing with previous versions + AVGA9250 and had X-Windows restarted each time he started Mame from the frontend, I'll review his email tomorrow.

There's more interesting stuff as the blue box screen being interlaced + doublescanned in my test, so the lower part was missing. I'll do my best to get some skills with this consoles but a ftp would definitely make a difference for me, a nice thing of the ditribution made by VeS is that I could browse the directories from the explorer as network folders so I could edit the stuff easily.

The less program is just like more, actually try 'more' instead maybe that'll work better, or even do a `cat filename` to see the file (can do a shift+page-up or shift+page-down at the console to scroll up/down). 

I'm uploading new .iso right now that have lftp included, and also have the Enable on always for xorg.conf.

That interlace/doublescan thing is very odd, I'm doubting it can even do that, but the blue box is just an xterm up in the lefthand corner at 25x80 and the rest of the screen should be black. 

When the new .iso images are up, should be able to use `lftp -u username ftp://site` to ftp things somewhere.  The goal of course is to make this easy to use and not have to know about Linux, but since just at the start of getting this stuff working it's definitely not there yet, so actually helps that your less familiar with Linux since it's making me think about things a bit better since to me a lot of stuff is second nature that isn't to most people who have used Windows mostly.

[Calamity]

It's something I've seen before with how xrandr by default with multiple monitors attached has them all mirrored with the same display/screen, so then of course switching modes doesn't work because it always uses the modeline which would fix the non-arcade monitor.  I'm curious if this really happens though with the 'e' force enabled option and only one monitor attached.

Oh, that is the infamous Catalyst 'clone' feature or it's equivalent. That really needs to be disabled somehow in order to have each display as independent, otherwise, at least in Windows, they will work as a block and you won't have access to the advanced features as vsync for each display.

[Calamity]

The less program is just like more, actually try 'more' instead maybe that'll work better, or even do a `cat filename` to see the file (can do a shift+page-up or shift+page-down at the console to scroll up/down).

I was trying to use 'type' DOS command but it has some different use here

I'm uploading new .iso right now that have lftp included, and also have the Enable on always for xorg.conf.

That interlace/doublescan thing is very odd, I'm doubting it can even do that, but the blue box is just an xterm up in the lefthand corner at 25x80 and the rest of the screen should be black. 

Interlace + doublescan is actually pretty possible although we are not considering that option in our calculations as I can't imagine a use for it. It's more of an issue than anything else, when trying to do a 320x480i resolution with regular Catalyst, you get your requested interlace but as Catalyst are hardcoded to react at 320x and 400x resolutions activating doublescan for them, then you end up having doublescan + interlace, and the lower half of the screen is chopped (what really happens is that the upper half is stretched to cover the screen because of lines doubling). That issue is one of the main reasons for my patching them btw. The funny part is that with AVGA9250 that blue box part is perfect, no doublescan, and is indeed located on the lefthand corner.

So there are probably different issues getting mixed at the same time. Hopefully they'll be figured out sooner or later. I had missed the other thread were Quinny is testing, and the PAL issue and that, interesting. I hope I'll be able to try the new iso later today. Most of the time I have a baby around now and my wife is starting to get crazy each time I unroll the network cable through the house

[bitbytebit]

The less program is just like more, actually try 'more' instead maybe that'll work better, or even do a `cat filename` to see the file (can do a shift+page-up or shift+page-down at the console to scroll up/down).

I was trying to use 'type' DOS command but it has some different use here

I'm uploading new .iso right now that have lftp included, and also have the Enable on always for xorg.conf.

That interlace/doublescan thing is very odd, I'm doubting it can even do that, but the blue box is just an xterm up in the lefthand corner at 25x80 and the rest of the screen should be black.  

Interlace + doublescan is actually pretty possible although we are not considering that option in our calculations as I can't imagine a use for it. It's more of an issue than anything else, when trying to do a 320x480i resolution with regular Catalyst, you get your requested interlace but as Catalyst are hardcoded to react at 320x and 400x resolutions activating doublescan for them, then you end up having doublescan + interlace, and the lower half of the screen is chopped (what really happens is that the upper half is stretched to cover the screen because of lines doubling). That issue is one of the main reasons for my patching them btw. The funny part is that with AVGA9250 that blue box part is perfect, no doublescan, and is indeed located on the lefthand corner.

So there are probably different issues getting mixed at the same time. Hopefully they'll be figured out sooner or later. I had missed the other thread were Quinny is testing, and the PAL issue and that, interesting. I hope I'll be able to try the new iso later today. Most of the time I have a baby around now and my wife is starting to get crazy each time I unroll the network cable through the house

Yeah, I can understand that, but the odd thing is there isn't any ability to output interlace/doublescan in any of my modelines in the DRM (all are hardwired) or in the switchres modeline it'll setup for xorg.conf by default.  So it's really impossible for it to do that from what I can tell, unless it's using the default modes which might be possible.  

When you have it with the blue box, what does `xrandr -display :0.0 -q` show?   That might be interesting, and also `xrandr -display :0.0 -q --verbose` might be helpful too (after doing the Alt+Ctl+F2 to get to the second terminal, also check Alt+Ctl+F1 since that's the first terminal that X started up in).  This new version has lftp on it so if you do those commands and >log.txt for each, and ftp them somwhere and post them for me, that might show me something (and also check what is in /etc/X11/xorg.conf when in the blue window too, see what the modeline is it's using).  

I am thinking that one big thing needed, at least with Jpac, is going through all the connectors and disabling all but the main one and do like Soft15Khz and require the first output to be used only.  Since we can't see the monitors and they are 'invisible' with Jpac, it seems like the only way to really work with it.  Basically force connector 1 (DVI-I-1) on permanently and every other one off.  Does that sound like the way Windows users are used to doing this?  I figure dual screens are only useful for testing, although another option is to basically force the card to act like an AVGA card and always have the first output be CGA no matter what and second VGA.  I can specify at the grub.conf stuff which connectors do what and sounds like this might be what I need to do.  The one issue though is knowing what is the first one, because there are VGA- connectors and DVI-I- connectors and then HDMI-I- connectors too.  So hard to know for sure what will work in all cases, not sure if best to choose the VGA-1 and DVI-I-1 or not.  The other confusing thing is that is how the DRM stuff calls them by those names, but in xrandr we get different ones like DVI-0 is possibly DVI-I-1 from the DRM layer, but not with all cards so it's not consistent (it's all so new though, must be expected, I think all this stuff will become easier to work with in a few months when they start realizing some of this odd issues and get X Windows working with it more consistently).  


Update:

See the other thread with the possibly grub command line changes to try, try this with the new .iso and see if anything is better using them if the default doesn't work better. Basically there's ways to specify the exact connector to force on and the resolution to use for it.  

[Calamity]

Yeah, I can understand that, but the odd thing is there isn't any ability to output interlace/doublescan in any of my modelines in the DRM (all are hardwired) or in the switchres modeline it'll setup for xorg.conf by default.  So it's really impossible for it to do that from what I can tell, unless it's using the default modes which might be possible.

I see what you mean and indeed suspected some of the default modes stuff was somehow being invoked as I also got that unexpected 31 Khz mode on my AVGA cab right before X Windows was started.

I am thinking that one big thing needed, at least with Jpac, is going through all the connectors and disabling all but the main one and do like Soft15Khz and require the first output to be used only.  Since we can't see the monitors and they are 'invisible' with Jpac, it seems like the only way to really work with it.  Basically force connector 1 (DVI-I-1) on permanently and every other one off.  Does that sound like the way Windows users are used to doing this?  I figure dual screens are only useful for testing, although another option is to basically force the card to act like an AVGA card and always have the first output be CGA no matter what and second VGA.  I can specify at the grub.conf stuff which connectors do what and sounds like this might be what I need to do.  The one issue though is knowing what is the first one, because there are VGA- connectors and DVI-I- connectors and then HDMI-I- connectors too.  So hard to know for sure what will work in all cases, not sure if best to choose the VGA-1 and DVI-I-1 or not.  The other confusing thing is that is how the DRM stuff calls them by those names, but in xrandr we get different ones like DVI-0 is possibly DVI-I-1 from the DRM layer, but not with all cards so it's not consistent (it's all so new though, must be expected, I think all this stuff will become easier to work with in a few months when they start realizing some of this odd issues and get X Windows working with it more consistently).

According to SailorSat newer ATI cards use DVI as their primary device, and VGA as second, it's the opposite to the older Radeon like 9250. So the expected behaviour is that they'll boot with both connections on, but if no monitor is detected in either of them, they will go to the default setup turning on primary device only (DVI). However there are many cards with two DVIs, HDMIs and no VGA, so it will be different there. So what you're saying will do that also, and might work. Dual screen support could be added when we have this simpler scheme fully working, but it's not required now, what we must make sure is that the 'clone' feature is not added, as it's a kind of fake dual screen thing that many people are using in their home cinemas without knowing it really sucks.

The interesting thing is that when starting your previous cd with either one of the connections plugged, it seemed that after the boot, that is displayed simultaneousy through both connections, each of the parts was showing on a different device, so the missing part with DVI was the one that showed on VGA. This is independant to the issue with default(?) modes I was commenting that I think has been there from previous versions.

I don't really know if that behaviour with connection management and how it is different with newer cards has to do with software (drivers,...) or is a BIOS feature. However that DRM stuff in development seems promising as once it's mature hopefully it could also work with HD5000 family and above, that definitely don't support anything without EDID on Windows.

[bitbytebit]

Yeah, I can understand that, but the odd thing is there isn't any ability to output interlace/doublescan in any of my modelines in the DRM (all are hardwired) or in the switchres modeline it'll setup for xorg.conf by default.  So it's really impossible for it to do that from what I can tell, unless it's using the default modes which might be possible.

I see what you mean and indeed suspected some of the default modes stuff was somehow being invoked as I also got that unexpected 31 Khz mode on my AVGA cab right before X Windows was started.

I am thinking that one big thing needed, at least with Jpac, is going through all the connectors and disabling all but the main one and do like Soft15Khz and require the first output to be used only.  Since we can't see the monitors and they are 'invisible' with Jpac, it seems like the only way to really work with it.  Basically force connector 1 (DVI-I-1) on permanently and every other one off.  Does that sound like the way Windows users are used to doing this?  I figure dual screens are only useful for testing, although another option is to basically force the card to act like an AVGA card and always have the first output be CGA no matter what and second VGA.  I can specify at the grub.conf stuff which connectors do what and sounds like this might be what I need to do.  The one issue though is knowing what is the first one, because there are VGA- connectors and DVI-I- connectors and then HDMI-I- connectors too.  So hard to know for sure what will work in all cases, not sure if best to choose the VGA-1 and DVI-I-1 or not.  The other confusing thing is that is how the DRM stuff calls them by those names, but in xrandr we get different ones like DVI-0 is possibly DVI-I-1 from the DRM layer, but not with all cards so it's not consistent (it's all so new though, must be expected, I think all this stuff will become easier to work with in a few months when they start realizing some of this odd issues and get X Windows working with it more consistently).

According to SailorSat newer ATI cards use DVI as their primary device, and VGA as second, it's the opposite to the older Radeon like 9250. So the expected behaviour is that they'll boot with both connections on, but if no monitor is detected in either of them, they will go to the default setup turning on primary device only (DVI). However there are many cards with two DVIs, HDMIs and no VGA, so it will be different there. So what you're saying will do that also, and might work. Dual screen support could be added when we have this simpler scheme fully working, but it's not required now, what we must make sure is that the 'clone' feature is not added, as it's a kind of fake dual screen thing that many people are using in their home cinemas without knowing it really sucks.

The interesting thing is that when starting your previous cd with either one of the connections plugged, it seemed that after the boot, that is displayed simultaneousy through both connections, each of the parts was showing on a different device, so the missing part with DVI was the one that showed on VGA. This is independant to the issue with default(?) modes I was commenting that I think has been there from previous versions.

I don't really know if that behaviour with connection management and how it is different with newer cards has to do with software (drivers,...) or is a BIOS feature. However that DRM stuff in development seems promising as once it's mature hopefully it could also work with HD5000 family and above, that definitely don't support anything without EDID on Windows.

So are you able to see the grub menu on bootup with both cards, or just the AVGA one?

I'm now looking at the difference between the 'e' option and 'D' option which seems to be that e is force it on while D is force it on digitally.  I'm not fully sure why it wouldn't know if the output is digital or analog in the DRM stuff.  It has VGA connectors and DVI connector types, also TV connector types but I'm also sort of confused about that too and if I should call it a TV-1 for a person with a PAL/NTSC TV or still use the DVI-I-1 output.  I think the best default is the 640x480 CGA mode and Enable forced on just the DVI-I-1 output, hopefully rest aren't connected. 


The clone screen thing in X Windows requires setup with virtually expanding the desktop larger and having monitors both fit on it.  This will never work though because they are still connected, only the Nvidia proprietary drivers can actually treat both outputs like two independent screens.  Anyways under Linux dual monitor support doesn't work for mame, and also seems it's really tricky to either setup xorg.conf for this in a generic way (if that's even possible).  Using xrandr you can sort of setup things but you still need to make a big virtual desktop for a single card with 2 outputs, and why it's really just one screen and the modeswitching just won't work.  So it's probably best to avoid dual monitors on a card and expecting the arcade mode to work, unless doing tests of course.  I actually use 2 video cards on my desktop for dual monitors because otherwise it's not fully independent in Linux, on my arcade cab I have an older radeon in there to allow output to a normal LCD monitor if necessary because having the other output connected confuses xrandr and it won't switch to arcade resolutions at all.  I had in the perl switchres to basically turn off all monitors except the one chosen, which you have to choose because it's hard to tell which connected one is the one you want.  I might need to do something similar, perhaps just turn off everything besides the first output/DVI.


So your saying that if I pick DVI-I-1 as the only arcade output, this will duplicate the behavior of Soft15Khz and always make the first output work?  Or would that require an AVGA card to use the digital connection?  That's the main issue I have with it, if I pick DVI would only newer radeons work on the first output and if I pick VGA only older ones on the first output and need to have a VGA connection too.  Not sure how to just always have the first output  enabled in both cases with one simple grub config option, that also is viewable upon boot.  Although I guess since the AVGA can output to 15Khz on boot then there could be a separate grub option for it using the VGA-1 output instead?

[Calamity]

I won't be able to try the new iso until tomorrow but I've managed to copy the config file and log from the previous one for you to check. I copied them doing ssh from my laptop to the cab. I'm also very slowly getting familiar with the consoles trying to restart X Windows with different options, etc. Editing xorg.conf with that 'vi' command is a complicated, reminds me of DOS edlin. At some point I was able to have video on X desktop while switching consoles by CTRL + ALT + 1, 2, 3 but it was out of range (no option changed, just restarting it).

I can see the grub menu on both cards but with HD4350 it's out of range (jpac however allows a duplicated distorted picture).

On boot, both connections are on, I believe this happens with all cards (ATI, nVidia, etc), and they output the same standard vesa mode. But at some point during startup it's when monitor checking is done and then the secondary device is turned off if there is no monitor plugged. In Windows that point is right after the driver is loaded, in Linux it seems to be when DRM is started. However, trying to answer your question (I'm not sure), forcing DVI as primary should only be done for the newer Radeon, and for the older ones the VGA should be the primary (bear in mind that Radeon 9250 DVI is only digital, not digital/analog like in HD4350, so the DVI-VGA adapter wouldn't even fit) so I can't think of an easy choice for you to do, but to have both options on grub menu and the user selecting it.

[bitbytebit]

I won't be able to try the new iso until tomorrow but I've managed to copy the config file and log from the previous one for you to check. I copied them doing ssh from my laptop to the cab. I'm also very slowly getting familiar with the consoles trying to restart X Windows with different options, etc. Editing xorg.conf with that 'vi' command is a complicated, reminds me of DOS edlin. At some point I was able to have video on X desktop while switching consoles by CTRL + ALT + 1, 2, 3 but it was out of range (no option changed, just restarting it).

I can see the grub menu on both cards but with HD4350 it's out of range (jpac however allows a duplicated distorted picture).

On boot, both connections are on, I believe this happens with all cards (ATI, nVidia, etc), and they output the same standard vesa mode. But at some point during startup it's when monitor checking is done and then the secondary device is turned off if there is no monitor plugged. In Windows that point is right after the driver is loaded, in Linux it seems to be when DRM is started. However, trying to answer your question (I'm not sure), forcing DVI as primary should only be done for the newer Radeon, and for the older ones the VGA should be the primary (bear in mind that Radeon 9250 DVI is only digital, not digital/analog like in HD4350, so the DVI-VGA adapter wouldn't even fit) so I can't think of an easy choice for you to do, but to have both options on grub menu and the user selecting it.

Sounds good I will look at the logs, thanks.

Yeah I'm right now hopefully making it so it has the multiple boot menu options for DVI or VGA, and also making a script run that will turn off all other monitors/outputs besides the first one and one we picked at boot basically (at X startup that is, using xrandr, it can turn off monitors/outputs).  This will at least make sure that mode switching works right, since if those other outputs are on it won't, and also at the same time should allow us to force on connectors (although right now I'm forcing on only the first DVI or VGA one in this newest work I'm doing).

So might have an .iso up tonight which may be something to test tomorrow too.  Also I do have disk installation fully working now although need to figure out the changes for the way the startup.pl script work then because it no longer is the same startup (no autologin once installed on the harddrive).  Also hopefully usb stick bootup will work eventually but there's some issues with it finding the root file system since it's a usb stick and not a CD drive (probably just simple grub command line issues I think).  

Hopefully we've got the video issues somewhat cornered with getting the output forced on but yet only for the first input so Jpac is happy but does't take out modeswitching in the process.  It's interesting because this seems to be a big issue with truly getting modelines to work with xrandr and generally the newest Linux DRM stuff working when things like Jpac are used or TV's, real Arcade Monitors.  So I'm figuring this isn't going to be easy, I now realize that this d9800 makes it a lot easier and I didn't suspect there was so many issues actually.  So am glad I started working on this now, seems like to get things working with Linux and the newest stuff (which is what allows the vsync and modeline switching to work close to ideal) is sort of uncharted territory and we're wading through some interesting issues.  I just wish the Linux DRM people cared more about this, the Alex guy has been very helpful, yet there's really no interest in any actual changes in the core Linux code itself to figure out the Arcade Monitor issues (since I admit it's quite a crazy thing, try to figure out how to work with monitors that basically give no information back and with Jpac the monitor is invisible and that's just not the easiest problem to solve).  How does Windows exactly output to a Jpac connected monitor, if it can't see it, is that something only Soft15Khz solves or an ArcadeVGA card?  Oh, you mean they always enable the first monitor even if not connected?  Which I guess the DRM layer doesn't even do, interesting, so we do have the ability to do more and possibly enable only one of any of the outputs, as long as we know which is preferred ahead of time (and without a viewable grub menu, possibly only setup ahead of time with a normal monitor would be the way to do it, like I guess arcadeVGA and Soft15khz sometimes require).

Also you can use the nano editor and it'll be much nicer than vi  


Update:

Yeah from the xorg logs I definitely see that it's bad to have enabled all the interfaces like that, so newer changes I have done should be much better about that.  I think it might have to do with how the HDMI is shared with the other output, and for HDMI it's seeing all the default modes and that might be part of the issue. 

[Calamity]

How does Windows exactly output to a Jpac connected monitor, if it can't see it, is that something only Soft15Khz solves or an ArcadeVGA card?  Oh, you mean they always enable the first monitor even if not connected?

Yes, that's how it works in my experience (don't mean it's the rule). In fact with Windows I have video through DVI-VGA with default Cat 9.3 options. However, if I wanted to plug the arcade monitor to the VGA (second device), I believe I should start the system with a pc monitor connected to the DVI and the arcade monitor to the VGA, then activate the second display on screen/properties, and then it should be already on for the next Windows session, provided I didn't unplug the VGA cable in the middle (then it would disable it).

Yeah from the xorg logs I definitely see that it's bad to have enabled all the interfaces like that, so newer changes I have done should be much better about that.  I think it might have to do with how the HDMI is shared with the other output, and for HDMI it's seeing all the default modes and that might be part of the issue. 

Yes, we have that HDMI there to deal with 
Reminds me that's something I have to investigate, as I don't know if DVI and HDMI can be used as independent devices with this card or not, as I intended at the beginning (that would make possible to use the same card with a plasma TV for movies and an arcade monitor or crt TV for games).

[bitbytebit]

How does Windows exactly output to a Jpac connected monitor, if it can't see it, is that something only Soft15Khz solves or an ArcadeVGA card?  Oh, you mean they always enable the first monitor even if not connected?

Yes, that's how it works in my experience (don't mean it's the rule). In fact with Windows I have video through DVI-VGA with default Cat 9.3 options. However, if I wanted to plug the arcade monitor to the VGA (second device), I believe I should start the system with a pc monitor connected to the DVI and the arcade monitor to the VGA, then activate the second display on screen/properties, and then it should be already on for the next Windows session, provided I didn't unplug the VGA cable in the middle (then it would disable it).

Yeah from the xorg logs I definitely see that it's bad to have enabled all the interfaces like that, so newer changes I have done should be much better about that.  I think it might have to do with how the HDMI is shared with the other output, and for HDMI it's seeing all the default modes and that might be part of the issue.  

Yes, we have that HDMI there to deal with  
Reminds me that's something I have to investigate, as I don't know if DVI and HDMI can be used as independent devices with this card or not, as I intended at the beginning (that would make possible to use the same card with a plasma TV for movies and an arcade monitor or crt TV for games).

I think I see the issue you saw with interlace/doublescan together when booting into X with the xterm box config on first boot.  It's weird, didn't do that before but I suspect the *fixes* they did for interlace/doublescan have possibly actually done the opposite and broken interlace/doublescan in X Windows (but fine it seems in the frame buffer).  They might have an update for the X driver which works with that change in DRM, else I might have to reverse it for now and report how it seems to actually just doublescan/interlace and end up with what seems to be a progressive half size display.

Update:

I see what causes this now, it's actually the Option "Enable" "True" I added to force the X Windows to work on outputs, I'm hoping that isn't necessary for the Jpac case because it seems to totally destroy overscan.  It might be actually due to the other interfaces also being enabled, it's hard to point to just one output in xorg.conf and tell it what to do.  I may have to use xrandr to do that I'm guessing.

[Calamity]

Hi bitbytebit,

It's finally working! I've tested CGA-DVI, NTSC-DVI and PAL-DVI and they all get to the desktop without problems (strange but only CGA failed 3 of 4 times, then it worked, but I suspect it could have been the jpac overflowing the keyboard buffer, this happens very very rarely but it could have happened right now corrupting my tests). Apart from that everything was nice and clean, all modes perfectly adjusted. It only seems to fail when run an existing Mame game from Wahcade. When it does not exist, it quickly switches video mode (I can see a big mouse cursor indicating a low res mode) but then switches back Wahcade. But when I select the Gridlee game (just one I see you've included) then unfortunately the screen goes black and never comes back (I'm able to go to the console however). So this seems to be improving a lot. I've attached the logs for you to check, right to the point where I get out of video.

[bitbytebit]

Hi bitbytebit,

It's finally working! I've tested CGA-DVI, NTSC-DVI and PAL-DVI and they all get to the desktop without problems (strange but only CGA failed 3 of 4 times, then it worked, but I suspect it could have been the jpac overflowing the keyboard buffer, this happens very very rarely but it could have happened right now corrupting my tests). Apart from that everything was nice and clean, all modes perfectly adjusted. It only seems to fail when run an existing Mame game from Wahcade. When it does not exist, it quickly switches video mode (I can see a big mouse cursor indicating a low res mode) but then switches back Wahcade. But when I select the Gridlee game (just one I see you've included) then unfortunately the screen goes black and never comes back (I'm able to go to the console however). So this seems to be improving a lot. I've attached the logs for you to check, right to the point where I get out of video.

Sounds good, yeah I'm overhauling how Wahcade is setup because the config it uses right now is not really functional, also have really improved the window manager used and selection.  It's going to need a swapspace setup for wahcade to actually generate the filter lists it seems, I discovered that, so really the current wahcade setup isn't going to probably work well.  Does it work though from the command line running `switchres <romname>` ?   That should work from an xterm hopefully (right mouse and 'new' option). 

I've been getting a lot of the setup and general install part working better, and will include a better window manager named lxde which is really nice and also have chromium setup on it now too so there's a web browser. 

I need to add swap space configuration and have wahcade with a generic setup for those free roms at first, also on setup it'll now launch the wahcade setup so everything can be configured from there to  point to the /data_ro/ drive mounted roms possibly. 

Later tonight I should have all that done, and will get some new .iso's up most likely by tomorrow.  Definitely looking interesting now, the PAL TV setup seems to be somewhat working and I think the fixes I've done would probably complete that (can't get desktop but games work).  Also hopefully am going to get a USB stick and fix that installation, and fix up any issues with normal hard drive install.  I think the whole wahcade setup will make things better, since it'll do all the work, just the need for a swap drive unfortunately to create the filter list for the ROMS (seems that process takes way too much memory, although if a system has more than the system I am testing on that's a laptop with 500 meg it might be able to work without swap enabled).

[bitbytebit]

New .iso files are up, hopefully the Wahcade behavior is better and also the desktop setup might work better too I'm hoping.

[Calamity]

I'll test that later today, as well as Switchres from the console to see if it works that way.

[Calamity]

Hi bitbytebit,

The new version seems to load quicker and the new Windows environment is very cool, Wahcade also loads now the correct Mame list. However I still have the same issue as soon as I load Mame, either from Wahcade or using switchres romname from lxterm. The video is just turned off, as was happining before in the previous steps. I can bring the desktop back by going into the cosole 1 and pressing ctrl+c. Could it be that xrandr is using a different device for output?

[bitbytebit]

Hi bitbytebit,

The new version seems to load quicker and the new Windows environment is very cool, Wahcade also loads now the correct Mame list. However I still have the same issue as soon as I load Mame, either from Wahcade or using switchres romname from lxterm. The video is just turned off, as was happining before in the previous steps. I can bring the desktop back by going into the cosole 1 and pressing ctrl+c. Could it be that xrandr is using a different device for output?

Yeah that might just be what is happening.  From the console when the X Windows screen is black, see what `xrandr -display :0.0 --current` shows you.  Possibly send the output if you can, or just see what modes/displayoutputs are active and have the resolution set to it.  That should show what is going on, it might be getting the current screen wrong I think.  Also see what dmesg output shows at the time when it's still black on the console, it'll show the DRM switching activity, and possibly at the end of your /var/log/Xorg.0.log file it might shed some clues. 

[Calamity]

- xrandr says DVI-0 is enabled, VGA-0 and HDMI-0 disabled. DVI-0 has two available modes, 640x480@30 and 256x240@59 (this one is marked as active and current video mode). So at first sight everything looks correct 

- dmesg propts a very long output, at the end of it it was mentioning DVI-I-1 all the time.

Today I hadn't the network plugged, I'll send you the logs as soon as I can.

BTW is there a text editor available from the new desktop environment?

[bitbytebit]

- xrandr says DVI-0 is enabled, VGA-0 and HDMI-0 disabled. DVI-0 has two available modes, 640x480@30 and 256x240@59 (this one is marked as active and current video mode). So at first sight everything looks correct 

- dmesg propts a very long output, at the end of it it was mentioning DVI-I-1 all the time.

Today I hadn't the network plugged, I'll send you the logs as soon as I can.

BTW is there a text editor available from the new desktop environment?

That is interesting, it technically sounds correct so definitely odd it's going black.  Also when you get logs, xrandr with --verbose added onto that command line will show even more information.  Yeah the DVI-I-1 is equal to DVI-0 in X windows, so that all sounds good, very strange.

The 'nano' text editor is probably the best one to use, which is a lot easier to use than vi.

It'd possibly be interesting to see the output of mame/switchres from the command line, using the '--args -verbose' added to switchres to pass verbose to mame.  So this doesn't happen on the other AVGA card cabinet, just the newer ATI card? 

[bitbytebit]

I have a SwitchRes version 1.10r91 uploaded now.  I have been able to have Soft15khz modelines installed, and rewrite them to match the one generated by switchres for a game when it loads.  I don't have my windows system setup to test if this really works, so needing to know if it works or not.  Basically I can load all Soft15Khz modelines, run switchres and since it mostly covers the common resolutions it seems to be enough to always have one we can use.  Then at that point after rewriting the appropriate matching modeline I run the ActiveLines RegEnum stuff that should restart the ATI Catalyst drivers.  Calamity, if you could test this and check the latest diff's in the GIT repository to see if this is really working right.  You can basically uninstall/reinstall Soft 15khz to reset the modelines to the defaults again, and this only will alter existing modelines from Soft15khz or other ATI custom modelines.

[Calamity]

I've been thinking of the xrandr thing and it could be working after all, as I do can see the mouse cursor at 256x240 during an instant, right before the screen goes blank, so it definitely must be switching resolutions. So, the issue might happen later, maybe with SDL or something? (I don't have a clear picture of how many layers are actually operating with video in Linux). It's strange because at least I should be able to return from Mame pressing ESC, but it just gets stuck there and I have to CTRL+C from the console. There's a test that I should have done and didn't... it's to check jpac leds to see if we have sync, in case we have that would mean the issue falls on the software part. I'll send you those logs.

Good news you have the Windows part done, I'll test it as soon as I can, however I don't use Soft-15Khz as I'm in the process of testing my patched drivers that do more or less the same thing, but will definitely be interesting to see if they can coexist.

[Calamity]

So this doesn't happen on the other AVGA card cabinet, just the newer ATI card?  

The lastests tests I've done were with the HD4350, I haven't tested the AVGA cab since last week as it's in another place, however remind it was loading X Windows without problems, but was also failing when invoking a game from Wahcade (it was going out from X Windows), so I don't know if it could be the same issue or not.

[bitbytebit]

So this doesn't happen on the other AVGA card cabinet, just the newer ATI card?  

The lastests tests I've done were with the HD4350, I haven't tested the AVGA cab since last week as it's in another place, however remind it was loading X Windows without problems, but was also failing when invoking a game from Wahcade (it was going out from X Windows), so I don't know if it could be the same issue or not.

It sounds like an SDL/OpenGL (most likely OpenGL) issue I guess, it actually is possibly the same behavior I saw when the vertical active lines were not  aligned to 8.  Of course it can't be doing that, the 8 thing, because it shouldn't be giving those values and I just tested the h9110 monitor type here and doesn't do it, so somehow it's trigging a similar issue in OpenGL but for some other reason card/chip specific.  I do see this behavior when running on an Intel chipset, basically other cards other than the Radeon, but that's somewhat expected because the OpenGL Gallium stuff isn't stable on those yet and I think the compile I am doing might be wrong for them (or they just don't work well yet with KMS/DRM/Gallium).  So it could be an OpenGL bug, I need to recompile those and also check to make sure I'm enabling every possible compatiblity I can, and look at the SDL build too.  They work well on my 4350 card but for some reason there's something different on yours, which is why I'm really curious about the AVGA card.  It could bring up a whole other issue with the crashing, which is interesting, so this is definitely the next level it looks like to work on is getting the actual SDL/OpenGL Gallium stuff working with all chips instead of just a few Radeons.  One interesting thing to see would be the output of `lspc -v` on your 4350 system (can from there see the pci ID and then just run `lspci -v 0:1:0` or similar to shorten the information output) because that will show exactly what RV chip is on there and if it's really the same chipset as mine is.

 
Also some other tests to try would be running with the --xrandr option to switchres, which will use xrandr to mode switch instead of SDL.  Then with that use the `--emulator xterm` and that won't run mame but instead an xterm and will show you if it can switch resolutions and then point to SDL/OpenGL.  Also then after that can try just the `--args -video soft` and use software rendering and see if that works (may have to add -throttle -mt onto that --args line for vsync to work too).  Those are a few interesting things to try, I get the feeling you will see a resolution switch without mame, and you will see it work with software rendering, at least if it's the SDL/OpenGL layer issues I'm guessing it is.

Another test would be running glxgears inside of an xterm and see if OpenGL runs, or the output of glxinfo and see what driver it's using and chipset.

[Calamity]

Hi bitbytebit,

I've done some tests and definitely is related to OpenGL, as switchres works flawlessly with the -video soft option, but when I use -video openg the screen goes blank. I've saved the logs of both for you to check, as well as the results of the stuff you asked.

This is the output of lspci:

arcade ~ # lspci -v -s 02:00.0
02:00.0 VGA compatible controller: ATI Technologies Inc RV710 [Radeon HD 4350] (
prog-if 00 [VGA controller])
        Subsystem: ASUSTeK Computer Inc. Device 02a8
        Flags: bus master, fast devsel, latency 0, IRQ 67
        Memory at d0000000 (64-bit, prefetchable) [size=256M]
        Memory at feae0000 (64-bit, non-prefetchable) [size=64K]
        I/O ports at e000 [size=256]
        Expansion ROM at feac0000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 3
        Capabilities: [58] Express Legacy Endpoint, MSI 00
        Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [100] Vendor Specific Information <?>
        Kernel driver in use: radeon
        Kernel modules: radeon

By the way 02:00.1 is an audio device of Ati HD4000's family, I guess it's related to HDMI audio part?

arcade ~ # lspci -v -s 02:00.1
02:00.1 Audio device: ATI Technologies Inc R700 Audio Device [Radeon HD 4000 Ser
ies]
        Subsystem: ASUSTeK Computer Inc. Device aa38
        Physical Slot: 16
        Flags: bus master, fast devsel, latency 0, IRQ 65
        Memory at feafc000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: [50] Power Management version 3
        Capabilities: [58] Express Legacy Endpoint, MSI 00
        Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [100] Vendor Specific Information <?>
        Kernel driver in use: HDA Intel
        Kernel modules: snd-hda-intel

For some reason lscpi only works when I ssh from my notepad to root, but the command is not recognized when from my cab (xterm), where is it supposed to be run? I couldn't either run glxgears or glxinfo, these commands are not recognized.

I won't be able to do tests on the AVGA cab for some days, but I'll post the results as soon as I get them.

I've been able to test the Mame roms included and it works great with mode switching, hopefully this issue is figured out soon as I'm eager to test it at its full capabilities.

[bitbytebit]

Hi bitbytebit,

I've done some tests and definitely is related to OpenGL, as switchres works flawlessly with the -video soft option, but when I use -video openg the screen goes blank. I've saved the logs of both for you to check, as well as the results of the stuff you asked.

This is the output of lspci:

arcade ~ # lspci -v -s 02:00.0
02:00.0 VGA compatible controller: ATI Technologies Inc RV710 [Radeon HD 4350] (
prog-if 00 [VGA controller])
        Subsystem: ASUSTeK Computer Inc. Device 02a8
        Flags: bus master, fast devsel, latency 0, IRQ 67
        Memory at d0000000 (64-bit, prefetchable) [size=256M]
        Memory at feae0000 (64-bit, non-prefetchable) [size=64K]
        I/O ports at e000 [size=256]
        Expansion ROM at feac0000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 3
        Capabilities: [58] Express Legacy Endpoint, MSI 00
        Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [100] Vendor Specific Information <?>
        Kernel driver in use: radeon
        Kernel modules: radeon

By the way 02:00.1 is an audio device of Ati HD4000's family, I guess it's related to HDMI audio part?

arcade ~ # lspci -v -s 02:00.1
02:00.1 Audio device: ATI Technologies Inc R700 Audio Device [Radeon HD 4000 Ser
ies]
        Subsystem: ASUSTeK Computer Inc. Device aa38
        Physical Slot: 16
        Flags: bus master, fast devsel, latency 0, IRQ 65
        Memory at feafc000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: [50] Power Management version 3
        Capabilities: [58] Express Legacy Endpoint, MSI 00
        Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [100] Vendor Specific Information <?>
        Kernel driver in use: HDA Intel
        Kernel modules: snd-hda-intel

For some reason lscpi only works when I ssh from my notepad to root, but the command is not recognized when from my cab (xterm), where is it supposed to be run? I couldn't either run glxgears or glxinfo, these commands are not recognized.

I won't be able to do tests on the AVGA cab for some days, but I'll post the results as soon as I get them.

I'm updating the OpenGL and SDL/xorg-server and SDL libraries all to the newest versions, hoping maybe that fixes something, also added some support to those for the different extra features of Radeon cards so maybe that'll help.  Your lspci looks exactly the same as mine does here, so is the exact same chip, definitely strange.  In the xterm for lspci you might have to do the 'sudo -s' first to become root, I'm not sure why the glxgears and glxinfo aren't working though, odd. 

I'm also updating mame to version 140u2 with the patches (they changed a bunch of stuff, is requiring refactoring some stuff with the redraw patch).  Also mess 140u2 hopefully, will see how that goes since I had to pull the SVN of it to work with u2.  I'm making Gentoo ebuilds of them too, so will be actual packages for the system which is kind of nice to have available for Gentoo users.

I'll look at the logs more and let you know what I find, there's definitely something odd about OpenGL and supporting different cards, but this is really weird how we have the same one and it's doing the odd stuff on yours but not mine.

[bitbytebit]

I've got a new 32bit ISO uploaded which has newer OpenGL and SDL libraries, with some extra compile options to possibly help the OpenGL issue.  Also newest mame and mess versions 0140u2 hiscore/galaxian/redraw patched are on it.  I found why glxgears and glxinfo aren't working, I guess they were only built on my 64 bit build so didn't figure that out till after the newest 32 bit version uploaded.  If this version doesn't work then on the next ISO they'll be there to possibly check although I doubt they'll tell too much info though. 

[Calamity]

I've tested dynamic stuff with Soft-15Khz installed, I believe there's some things that need to be modified for it to work. When you read resolutions from registry, you're recalculating vfreq which is good for your inner stuff but you should not redo the label by using 'int (vfreq)', but keep the original one you read from registry (always 60 with soft-15khz) so you will address the correct registry key and system mode label when editing it. So most of the resolutions you read are being relabeled as @59 and passing that as a parameter to Mame, which is using a random resolution as it doesn't find that one. Also you must use the strict ones available in the system. At the moment, if a game is 320x224 you're using that one, when you should go for the next available one: 320x240 and operate on that with the correct vfreq we want, then run Mame with 320x240@60 even if you have tweaked it to be 58.00 Hz. A problem does arise when dealing with vertical games, as the resulting rotated resolution is the one you should check against the mode table, and it won't be there probably. I've been checking the registry while running switchres to see the changes, but I haven't seen any, probably because the right resolutions were not pointed to.

[bitbytebit]

I've tested dynamic stuff with Soft-15Khz installed, I believe there's some things that need to be modified for it to work. When you read resolutions from registry, you're recalculating vfreq which is good for your inner stuff but you should not redo the label by using 'int (vfreq)', but keep the original one you read from registry (always 60 with soft-15khz) so you will address the correct registry key and system mode label when editing it. So most of the resolutions you read are being relabeled as @59 and passing that as a parameter to Mame, which is using a random resolution as it doesn't find that one. Also you must use the strict ones available in the system. At the moment, if a game is 320x224 you're using that one, when you should go for the next available one: 320x240 and operate on that with the correct vfreq we want, then run Mame with 320x240@60 even if you have tweaked it to be 58.00 Hz. A problem does arise when dealing with vertical games, as the resulting rotated resolution is the one you should check against the mode table, and it won't be there probably. I've been checking the registry while running switchres to see the changes, but I haven't seen any, probably because the right resolutions were not pointed to.

Odd, I actually am just using the same label from the registry that I read from it, not rewriting it at all, so not sure why the label would change.  I basically am storing the label and modeline (lpValueName and lpData) values, then only changing the lpData values to the modeline switchres created (which should always be less than or equal to the HxW of the label, so the buffer is correctly sized for it).  So I'm really just using the same label, and not giving it any information about the actual vertical frequency, could it be dynamically calculating the label for us?  I do need to use the label for the resolution from the registry for mame though, which probably is the issue, since it's still using the actual parameters and not the label (from the previous change I had made to do that), I kind of forgot about that needing to be done too.  So sounds like if I redo the mame label on the command line to match the labels, maybe it'll start working.  If you run it with -v -v then it'll show the changes it's making in more detail, it should be changing the values, at least is here from the Soft15khz ones put into the registry.  If it doesn't find one that fits though, it'll just default to the old behavior of naming the resolution it wants but not having it in the registry as the default would be without switchres.  I suspect the main issue is the command line to mame needs to be changed, I will do that since it should be a simple change (actually back to how I was originally doing it before I started reading the modeline information details in lpData).

Update:

Actually from what I can tell I actually am using the label completely, with the same vertical refresh rate that is in the registry.  It wouldn't though on older mame versions, since that is given with the separate -refresh argument to mame (are you testing with the older mame version), that might explain what is going on if so.  I'm fixing it so it saves the refresh rate separately from the label for the older mame version, but for newer ones it should be using the exact same registry key label as the -resolution line to mame. 

[bitbytebit]

I've tested dynamic stuff with Soft-15Khz installed, I believe there's some things that need to be modified for it to work. When you read resolutions from registry, you're recalculating vfreq which is good for your inner stuff but you should not redo the label by using 'int (vfreq)', but keep the original one you read from registry (always 60 with soft-15khz) so you will address the correct registry key and system mode label when editing it. So most of the resolutions you read are being relabeled as @59 and passing that as a parameter to Mame, which is using a random resolution as it doesn't find that one. Also you must use the strict ones available in the system. At the moment, if a game is 320x224 you're using that one, when you should go for the next available one: 320x240 and operate on that with the correct vfreq we want, then run Mame with 320x240@60 even if you have tweaked it to be 58.00 Hz. A problem does arise when dealing with vertical games, as the resulting rotated resolution is the one you should check against the mode table, and it won't be there probably. I've been checking the registry while running switchres to see the changes, but I haven't seen any, probably because the right resolutions were not pointed to.

I am pretty sure I figured out what is going on, was checking for the vfreq when finding the best modes among the registry modelines, which now that we can change them that doesn't matter anymore.  So it wasn't finding one that would work and just using the one it generated instead.

I uploaded a new Windows version that hopefully fixes this correctly, 1.01r107

[Calamity]

There's still a bug in it. Have a look at my logs attached. It's filling a 240x240 modeline structure with 320x240 mode, and 320x256 with 384x256, which produces a bad mode as labels don't match modeline resolutions. Good news are it's actually editing registry keys and taking affect, so we are just one step from having it working.

[bitbytebit]

There's still a bug in it. Have a look at my logs attached. It's filling a 240x240 modeline structure with 320x240 mode, and 320x256 with 384x256, which produces a bad mode as labels don't match modeline resolutions. Good news are it's actually editing registry keys and taking affect, so we are just one step from having it working.

Cool, good to know it can dynamically change them, now it looks like I need to improve my method of finding the best resolution then .  Will let you know when I get that improved, had wondered about how well that would work in all cases and seems to be hitting an issue there.

[bitbytebit]

There's still a bug in it. Have a look at my logs attached. It's filling a 240x240 modeline structure with 320x240 mode, and 320x256 with 384x256, which produces a bad mode as labels don't match modeline resolutions. Good news are it's actually editing registry keys and taking affect, so we are just one step from having it working.

I think this fixes it, found the issue with having checks with < instead of <=, hopefully doesn't foul up anything else which I don't think it will.  Also now am using the label for the check to make sure it's the right/max width/height the resolution can handle and write back the old value after we are done with running mame and using the modeline to what it was originally.  

This one hopefully works correctly now:

SwitchResWin-1.115-d23d86b.7z

Small bug with 240x240 resolution, well actually any that were 16 pixels larger horizontally it would choose but this fixes that now:


SwitchResWin-1.116-eaaab88.7z

[Calamity]

I'll try that one. I suppose you've done it but just in case, for each mode, label height/width and its modeline height/width (active x y) must match, so if a given mode is not found, go for a bigger one where it fits in, but use this second one for all the registry and Mame stuff, only the game's vfreq will be used.

[bitbytebit]

I'll try that one. I suppose you've done it but just in case, for each mode, label height/width and its modeline height/width (active x y) must match, so if a given mode is not found, go for a bigger one where it fits in, but use this second one for all the registry and Mame stuff, only the game's vfreq will be used.

I think I've done that, basically using the label HxW for matching, and if the resolution we want is less than the label it picks the one closest but still larger than our modeline so will fit in the allocated buffer for that label/modeline.  I'm using the labels just for matching and mame command line -resolution/-refresh stuff, but internally the real HxW and Vfreq it'll actually set the modeline.  Hopefully the matching always has the AI to pick the best available modeline now. 

[Calamity]

No, that's what I meant. Internally you can't use the real H/W but the one that matches the label Otherwise you'll get a bad working mode (it'll be completely out of sync, not only chopped or anything). However I'll test that but it won't work very probably. So once you decide for an existing mode you unfortunately have to ignore your original H/W for calculations and use the label ones.

So if you need to a mode like 384x256@55, and the closest you have is 400x256@60, you'll have to actually calculate a real modeline with 400x256@55, and then call Mame -resolution 400x256@60, that's the best you can do.

That's why I suggested that we need to create a decent mode table (with my patched drivers we can reach to 134 modes), as using a list of about 30 modes will be definitely not enough, although this technique combined with normal Soft-15Khz mode list will still produce much richer results than what's normally achieved.

[bitbytebit]

No, that's what I meant. Internally you can't use the real H/W but the one that matches the label Otherwise you'll get a bad working mode (it'll be completely out of sync, not only chopped or anything). However I'll test that but it won't work very probably. So once you decide for an existing mode you unfortunately have to ignore your original H/W for calculations and use the label ones.

So if you need to a mode like 384x256@55, and the closest you have is 400x256@60, you'll have to actually calculate a real modeline with 400x256@55, and then call Mame -resolution 400x256@60, that's the best you can do.

That's why I suggested that we need to create a decent mode table (with my patched drivers we can reach to 134 modes), as using a list of about 30 modes will be definitely not enough, although this technique combined with normal Soft-15Khz mode list will still produce much richer results than what's normally achieved.

Ah ok, I see now, interesting.  Yeah looks like with more modelines it would help overcome all the cases, mostly should work decent on common games now I'm suspecting but that'll be nice to have modeline tables then in usermodes.txt.  I'll look at lrmc and see about ripping out the code in there since it basically will do this for the set of mame games, but replace the modeline generation with the switchres one. 

I'll also take a look at regenerating the modeline after the registry match is found, or possibly moving the registry check before modeline calculation and then use the available hxw for calculation.

[bitbytebit]

Ok, I think I got it working right, version SwitchResWin-1.117-3bf4ed6.7z will do a recalculation of the modeline so if you only have 240x240 in the registry it'll take a 240x224 resolution and recalculate it to 240x240 instead.  Not sure if there's some missing logic to double check if it needs to use any extra flags but guessing not since that logic should already be in place, I think.  It now just requires a vast number of resolutions to be more accurate, more the better of course.   So the modeline generator part should make this work very well.

[bitbytebit]

I think I found the issues with crashing/black screen when running mame with opengl support.  Seems to be that the Gallium support (http://en.wikipedia.org/wiki/Gallium3D) for Mesa causes this to happen.  It at least seems to be the difference between what your seeing and what I normally get on my other system, when run on my test laptop with an Intel video card.  So I'm not 100% sure it's really going to fix what your seeing but it does seem to be a very likely candidate, I suspect Gallium support and Mame only work under certain conditions and seems to not be very compatible with multiple card types.  I can still get the same performance without Gallium for mame, so seems to not matter when it isn't used.

I'll have some new .iso files up soon without Gallium support in them, and will see how they work, hopefully fix the issue and can finally see how under Linux the mode-switching works.  I'm still baffled as to why my cabinet can handle Gallium support just fine, but every other system and even yours with the same video card doesn't, very strange, but this at least should be a more compatible stable option all around.  Now hopefully in a few weeks to a month the 2.6.38 kernel will arrive with the page flip support and we'll have a very accurate vblank/sync support to really make any tearing not occur.  It's odd because I don't see tearing as it is, so this change sounds like it'll just be even better which it's already pretty good.

[bitbytebit]

I've gotten those new .ISO files up and hopefully have fixed the mame/gallium OpenGL issue by removing gallium from OpenGL and using the classic Mesa code instead.  I also have it able to switch back and forth between Gallium mode and non-Gallium mode through running eselect like this...

eselect opengl list ->
 [1]   nogalium *
 [2]   xorg-x11

eselect opengl set 2 -> (will set it to use Gallium)
eselect opengl set 1 -> (will set it to not use Gallium)

Hopefully that works as expected, am taking advantage of a feature of portage/Gentoo packaging for OpenGL where they allow multiple libraries for different video cards.  So a person who has a system like mine where Gallium works and wants to try it can, although I really think it works the same without it because I ran the N64 emulator mupen64plus and didn't see a difference immediately. 

I'm also going to try and find the issue with mame and gallium, although may be one of those very hard to figure out things.  At least am going to see if I can run a debugger and find what code it's actually hitting to segfault (which is what it seems to be doing, either that or it locks like you see with a black screen, right in the middle of switching modes, I also think this might be the same issue that causes the non-aligned to 8 lines height to lock similar to what your seeing).

[Calamity]

I've tested new Switchres and I'm afraid there's still something that prevents it from working, though hopefully I've figured it out. When switching to the just created modeline, the mode is broken, completely out of sync, after that I can't even modify it with Arcade_OSD. I've seen that the registry key is stored with one or more extra zero bytes after the checksum, and that might probably be the issue. Please check that and I'll test it again tonight, as well as the new ISO.

[bitbytebit]

I've tested new Switchres and I'm afraid there's still something that prevents it from working, though hopefully I've figured it out. When switching to the just created modeline, the mode is broken, completely out of sync, after that I can't even modify it with Arcade_OSD. I've seen that the registry key is stored with one or more extra zero bytes after the checksum, and that might probably be the issue. Please check that and I'll test it again tonight, as well as the new ISO.

I think I know exactly the problem, I was adding a + 1 to the lpcData size calculation and so it makes sense and without that it should do it right.  Am testing that now.  Will have a new Windows binary up soon.

I hopefully have figured out this openGL thing, it's weird because basically when I compile both Gallium and non-Gallium versions then either way with eselect works now.  I think that by compiling both I'm doing something with the OpenGL libraries which is a good thing, maybe it needs both, at least it now works on my 'test case' that had issues and now is fine (a toshiba laptop with an intel i915G or something video card).  It at least was doing a similar thing, so hopefully by fixing that it also will fix the other cases where openGL hangs or crashes from mame.