Switchres: modeline generator engine

[bitbytebit]

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.

I altered the outputs.pl script and also now have grub have first/second outputs options for both DVI and VGA, so on your AVGA card it should work
and outputs.pl should be able to tell now that it needs to enable VGA-1 only when VGA-2 is enabled on the grub command line.  Also am going to  do
some tests hacking at the Gallium OpenGL side of things with that issue I'm seeing since maybe it'll have more chance working well on the 4350 being
a complete rewrite of what hangs/gets slow currently.  I still think that mame probably is either causing the problem leaving the first buffer of the texture/shape it wants to render (it's a VBO I guess) empty.  I'm seeing if in the Mesa code checking for the NULL buffer and skipping it in those cases (at least avoid accessing it) allows things to work for mame. 

So hopefully next ISO will understand the AVGA cabinet properly and the outputs, when choosing the second VGA option, and will see if this Gallium stuff can actually work on my 4350 properly with some hacking.

[bitbytebit]

I'm uploading version 1.151-eaaaed6 of the liveCD now, which will have options for the second VGA output.  Not sure if it'll make any difference on the 4350, but always worth a try of course, at least contains the mame buffer fixes and some other odds and ends.

[Calamity]

I've tested the new one with the AVGA, it works with SECOND VGA grub option (console is still at 31 kHz), desktop is ok (have you removed the outputs.pl from there?). glxgears works. But, switchres does not work now, it makes x windows get restarted. Unfortunately I haven't tested it with video soft, to see if at least mode switching was working, I will as soon as I can.

On the HD4350, the issue persists with glxgears not working and with switchres is the same as before, however I've tested with -video soft and it is working ok (btw, do we really need opengl for vsync or it can be also achieved by the soft option in Linux? it could be a provisional workaround). I've seen that we can also remove here the outputs.pl from .xinitrc and it still works the same, so that makes me think that once it's properly selected in grub menu and xorg.conf could it be enough?

[bitbytebit]

I've tested the new one with the AVGA, it works with SECOND VGA grub option (console is still at 31 kHz), desktop is ok (have you removed the outputs.pl from there?). glxgears works. But, switchres does not work now, it makes x windows get restarted. Unfortunately I haven't tested it with video soft, to see if at least mode switching was working, I will as soon as I can.

On the HD4350, the issue persists with glxgears not working and with switchres is the same as before, however I've tested with -video soft and it is working ok (btw, do we really need opengl for vsync or it can be also achieved by the soft option in Linux? it could be a provisional workaround). I've seen that we can also remove here the outputs.pl from .xinitrc and it still works the same, so that makes me think that once it's properly selected in grub menu and xorg.conf could it be enough?

Ah interesting, if it's crashing X Windows, then checking the /var/log/Xorg.0.log.old after that, mainly the end, might be helpful.  Sounds like somehow xrandr switching is crashing X Windows there.  It's still using outputs.pl but now it knows about the second output for VGA from the grub boot menu so working as it should it sounds like.  The outputs.pl script is good to keep the confusion from happening about having an extra normal monitor on the other output of the card since X Windows won't allow modeswitching then and will always use the compatible mode for both monitors (at least won't allow it to go out of range of the other monitor).  If you do a killall startup.pl a few times, then try switchres, then you'll end up at the console after the crash (which I guess is half screen still).  From there hopefully can see some messages on the console, and then can use `sudo -u arcade startx` I think to get back into X Windows without using process.pl.  I think any good information will be in /var/log/Xorg.0.log for that issue, and sounds like it's possibly the xrandr switching and the GPU code in the X driver for it.

Software switching wont work I guess because it's using the OpenGL interface into the card DRM to get to the ability to both vsync and page flip.  Seems like it's the only path to that from what I can tell.  I still am researching OpenGL though and sounds like Alex and the Mesa developers should eventually get to the bug with the backtrace I have in Gallium.  Hopefully Gallium provides a way to fix things.

Also test the AVGA and try to run mame without switchres and still all the same settings as under switchres, so we can possibly see if it's just xrandr directly giving an issue.  I can imagine that card with the altered BIOS could trigger some bugs in the ATOM code where they aren't expecting that cards BIOS and hardwiring settings possibly.  Seems that's most likely the issue I would think there, while the other 4350 probably is hitting a bug in the OpenGL Mesa stuff and similar to the Gallium issue.  Odd thing is with Gallium on mine glxgears works great, so it's odd and I thought that would be a Mame specific thing or something else Mame triggers that glxgears doesn't.  So that is interesting how glxgears goes really slow.  It actually is bad that they don't crash in some ways, because that sounds like it'd be useless to look at it with the gdb debugger then and get any back traces  after a crash.  If it did, then I do have the build with gdb, and gallium.  Another idea I guess is to try Gallium on the 4350 (and possibly the AVGA) and see if it acts any better (assuming the AVGA crash is Mesa related, which it's probably X driver xrandr related).  I might build a test build using Gallium for you to try at least on the 4350, since maybe it acts different and if it doesn't crash like mine then that is even a bigger mystery but might as well find out to see how odd this really is .

Do you see anything in dmesg output about the network card issue?  The audio stuff might overload it so possibly looking though /var/log/messages would help.  Are they constant messages about it, try a `tail -f /var/log/messages` and see if it's continuously printing things about the audio issue.  It would be good if we eventually get the audio/net working, at least network for now, to be able to see more log information.

[bitbytebit]

I've tested the new one with the AVGA, it works with SECOND VGA grub option (console is still at 31 kHz), desktop is ok (have you removed the outputs.pl from there?). glxgears works. But, switchres does not work now, it makes x windows get restarted. Unfortunately I haven't tested it with video soft, to see if at least mode switching was working, I will as soon as I can.

On the HD4350, the issue persists with glxgears not working and with switchres is the same as before, however I've tested with -video soft and it is working ok (btw, do we really need opengl for vsync or it can be also achieved by the soft option in Linux? it could be a provisional workaround). I've seen that we can also remove here the outputs.pl from .xinitrc and it still works the same, so that makes me think that once it's properly selected in grub menu and xorg.conf could it be enough?

Try setting this 'gl_vbo 0' in mame.ini, see if that changes things on the 4350.  Also possibly try on the AVGA but not sure if that matters there.

[Calamity]

I still can't get the network working on the 4350 cab, when I add the eth0 option and the setup ends the machine is completely hang. The gl_vbo option didn't help either.

But I've been digging it /var/log/messages and noticed something interesting:

GroovyArcade kernel: [   789.769052] [drm_mode_getfb] *ERROR* Invalid framebuffer id

Then when I check /var/log/Xorg.0.log it seems the above error comes right after this:

[  789.768] (II) GLX: Initialized DRI2 GL provider for screen 0

(well, it really happens right after the whole GLX: block of messages, that one being the last)

I'll check with the AVGA in a while.

[bitbytebit]

I still can't get the network working on the 4350 cab, when I add the eth0 option and the setup ends the machine is completely hang. The gl_vbo option didn't help either.

But I've been digging it /var/log/messages and noticed something interesting:

GroovyArcade kernel: [   789.769052] [drm_mode_getfb] *ERROR* Invalid framebuffer id

Then when I check /var/log/Xorg.0.log it seems the above error comes right after this:

[  789.768] (II) GLX: Initialized DRI2 GL provider for screen 0

(well, it really happens right after the whole GLX: block of messages, that one being the last)

I'll check with the AVGA in a while.

I'm guessing this is a symptom from the Jpac issue, in the kernel it seems this means that the frame buffer isn't setup completely.  When we are forcing it on and it has no knowledge of the connection existing like with Jpac I guess it must not have anything ready for OpenGL to use.  I'm looking at it more, definitely very cool to have at least some lead, I suspect before when it was hanging there it was the same issue but looks like it was probably an oops or something in the kernel while now it's being a little more civil about it.  This may help actually find the code quicker that we need to fixup for making a Jpac type setup work.  I guess it needs to be hardwired completely to say the first monitor is an arcade monitor and setup all this stuff manually, that might be the way to do it.  I just have to learn how all the setup works, looks like this goes into the radeon part of the DRM instead of just the generic layer.  That's where it goes to either force or detect the DVI/VGA device.  So the individual drivers deal with that part, the force code just simply sets it as connected but the detection code does a ton of stuff.  What's odd, and indicates it's even somewhere else than that force setting, is that with force on mine it still works so it must be some more stuff done outside of the force setting where if it doesn't see the monitor connected it won't setup the frame buffer id structure correctly.

I solved the hiscore patch issue I had seen, there's a bug in the newest version it turns out and wasn't the SDL changes I made at all.  So will be able to enable that again fortunately, took me hours to track it down.  It was simply the placement of the init for it changed because mame changes moved it up and from that the call back for it to exit and save the score happened after callbacks to unload the game/rom cpu memory. 

[bitbytebit]

I still can't get the network working on the 4350 cab, when I add the eth0 option and the setup ends the machine is completely hang. The gl_vbo option didn't help either.

Are you able to access the machine before setup is complete, in theory it should be running eth0 already at that point (although I'm wondering now if that might not be happening).  I think I'm going to remove the stuff I'm doing to try and auto setup eth0 on setup, since it seems not to work and might actually be causing the issue with it not working for you and possibly hanging too.  That was for when we were not getting any console anyways and that's not the case anymore, so seems like it's not necessary anyways.  I think it might be tearing down the eth0 connection right after setup and then running into a problem when trying to restart it a second time.  If not that, then it might be a in-progress thing with the network driver for your card that'll most likely be fine by 2.6.38, since this linux-next kernel is the really bleeding edge development version.

[Calamity]

I've been testing on the AVGA cab, first of all using -video soft doesn't make any difference, so it seems opengl is working ok here and it's the mode switching the one failing as you thought. Here are some parts of Xorg.0.log that might be interesting to figure things out. I'm not seeing the drm error in /var/log/messages here however:











Now this is the console after the X Windows crash. Have a look at the "X Error of failed request" here, as that one isn't prompted in the Xorg.0.log.old and could be the issue:

[bitbytebit]

LiveCD32-MinimalNoMedia-1.159-a2cc863.iso will be uploaded in a few hours and should be interesting to test on both, I'm hoping to get the network interface working again (if it's what I think it is that broke it).  It's not going to probably change anything with the OpenGL issues on the 4350 but might allow you to send me the dmesg output with the whole of the information around that error your seeing, which should be interesting and help hardwire the monitor in the kernel by seeing all the stuff it touches on setup.

The dmesg output may show something interesting, the Xorg log seems like everything is ok actually for the most part.  The other message though on the console is interesting because it shows that xrandr isn't getting anywhere trying to set things for the VGA-1 interface.  I suspect running xrandr commands in X would be interesting, possibly either crash it or show some kind of clue.

Hopefully can use the network to get logs again after this new ISO is uploaded, if so I would check what the 'xrandr --current --verbose` output shows you.  Also the dmesg output of that startup, and the /var/log/dmesg file to possibly go along with that to get the startup information for that card.  I guess X isn't revealing any information about the crash and just exiting, but the console dmesg might show you more info or /var/log/messages even.  It sounds like either the DRM layer or the X driver is hitting a bug that the AVGA bios triggers and just bailing out and crashing. 

I also commented out the output.pl script for now to see and I suspect we don't really need that script anyways since it's only if a person is connecting multiple monitors to try to do what simply connected the extra monitor would do anyways.

[Calamity]

I'll keep an eye on that.

It makes sense that this problem is happening here because of the jpac issue, that's the difference probably as the 4350 must be the same. These are the results by now:

4350: console video OK, X Windows OK, mode switching OK, openGL ERROR
9250: console video ERROR, X Windows OK, mode switching ERROR, openGL OK

So the error I'm seeing from drm with the 4350 that seems to be preventing openGL from working, could be due to the need of forcing outputs also inside the radeon driver code, and might be related to the other one with 9250 not being able to show proper video on the console and failing with mode switching for xrandr not properly addressing the outputs, despite openGL is not affected in that case. That makes me think that both cards initializations follow different paths in the radeon driver, as I think I've been seeing different stuff being prompted in each case, although not completely sure. Of course it could be that AVGA special bios is kind of confusing radeon drivers, but I'd like to think it's not that.

Hopefully this new version will have the network on to provide you with the logs. After some tests I'm slowly getting some rudimentary skill moving around this system and I had my hands tied up not being able to copy the files to my laptop.

BTW when doing tests with the 9250 I noticed this line in one of the logs (I believe it was Xorg.0.log):

[ 133.573111] i2x i2c-1: unable to read EDID block

Ah, I forgot to say that running mame only instead of switchres also crashed just the same.

[bitbytebit]

BTW when doing tests with the 9250 I noticed this line in one of the logs (I believe it was Xorg.0.log):

[ 133.573111] i2x i2c-1: unable to read EDID block

Ah, I forgot to say that running mame only instead of switchres also crashed just the same.

Do you see this reference in the /var/log/dmesg file or /var/log/messages?

radeonfb

I think I might know what is going on, possibly your card is supported by the old radeon framebuffer driver.  If it is detecting the card, it may be getting in the way of things on the AVGA cab.  I probably need to totally disable that I'm guessing, but hopefully with the newer ISO you can confirm it's really the culprit.  Didn't realize that could happen, it may be the issue it seems.

Does running mame with the -noswitchres option and not letting it do mode switching also crash it?


Also what does the output of:


cat /proc/fb


Look like?  does it say radeonfb at all or radeondrmfb?


Also another thing to try if it's using radeonfb, is to edit the grub boot prompt when booting and add this...

video=radeonfb:off

I think that will turn it off and allow KMS to take over.

[Calamity]

Do you see this reference in the /var/log/dmesg file or /var/log/messages?

radeonfb

I think I might know what is going on, possibly your card is supported by the old radeon framebuffer driver.  If it is detecting the card, it may be getting in the way of things on the AVGA cab.  I probably need to totally disable that I'm guessing, but hopefully with the newer ISO you can confirm it's really the culprit.  Didn't realize that could happen, it may be the issue it seems.

Does running mame with the -noswitchres option and not letting it do mode switching also crash it?

I'm almost sure I've seen that radeonfb name on the AVGA cab. So it was the messages file from where I took that one. However I won't be sure until I check it there, maybe tomorrow, the fact is that machine is in another house and I'm just going there for testing during half an hour or so and then leave.

Didn't check with the -noswitchres option, but I think it's not mame fault as I believe sznesw also crashed (not fully sure though).

But I am almost positive that I've seen different messages from both cabs, something that made me curious at. BTW could it be that it's using that other drive for pre-ATOM bios?

[bitbytebit]

Do you see this reference in the /var/log/dmesg file or /var/log/messages?

radeonfb

I think I might know what is going on, possibly your card is supported by the old radeon framebuffer driver.  If it is detecting the card, it may be getting in the way of things on the AVGA cab.  I probably need to totally disable that I'm guessing, but hopefully with the newer ISO you can confirm it's really the culprit.  Didn't realize that could happen, it may be the issue it seems.

Does running mame with the -noswitchres option and not letting it do mode switching also crash it?

I'm almost sure I've seen that radeonfb name on the AVGA cab. So it was the messages file from where I took that one. However I won't be sure until I check it there, maybe tomorrow, the fact is that machine is in another house and I'm just going there for testing during half an hour or so and then leave.

Didn't check with the -noswitchres option, but I think it's not mame fault as I believe sznesw also crashed (not fully sure though).

But I am almost positive that I've seen different messages from both cabs, something that made me curious at. BTW could it be that it's using that other drive for pre-ATOM bios?

I'm pretty sure that's what's going on, radeonfb is getting in the way.  I'll fix that, figure out the right way to disable it either not compiling it into the kernel or with grub.conf.  Will hopefully get a new ISO with that change to test, so the one I uploaded may be good to get logs from the 4350 with hopefully and logs from the AVGA and  possibly try the testing, but I do think that radeonfb is the whole issue and without it we might just have the AVGA working if that older card does ok with KMS (Which from what I can tell it's worked longer than the r600-700 gpu cards have).

[Calamity]

The fact is the one motherboard I have here is dual AGP PCIe so I don't know if I could plug an AVGA I have around also and have both cards on for testing, I suppose I should tweak something in the bios to select the one to boot with or something, but don't know if that will mess the system even more. However the main issue with this I suspect will be forniture related, as the space is so narrow on the shelf that it might not even fit.

[bitbytebit]

The fact is the one motherboard I have here is dual AGP PCIe so I don't know if I could plug an AVGA I have around also and have both cards on for testing, I suppose I should tweak something in the bios to select the one to boot with or something, but don't know if that will mess the system even more.

I'm hoping that the change I am making to the kernel should make it act right, I think it's just disabling the radeonfb module from compiling will do it.  Also am doing something which may allow the sound to work, so will see how that goes too.  Also possibly if we are lucky, I think the changes I made will kick the DRM KMS mode for the framebuffer right after the grub menu too.  I'm trying to compile that part in instead of being modules, should be nicer on bootup I hope.

It'll probably be about 8-12 hours before I get back, the kernels are compiled, and can test it and upload an ISO. I'm hoping I don't have to do another compile after that and it works with the changes, kernel compiling takes quite a while since it has so many modules in that generic kernel config I'm using.

[bitbytebit]

I'm uploading LiveCD32-MinimalNoMedia-1.165-cf69349.iso right now which has improved the radeon setup in the kernel.  I removed all the extra framebuffer modules which are older depreciated ones, moved the whole radeon and DRM into the kernel itself.  So right after the grub menu it goes straight into 15khz output now so really happens pretty fast, and you in theory now could do the needed maintenence and emergency repair stuff on an arcade monitor (since it does 15khz immediately without accessing the file system.  It would be nice to get grub to do the same, but I am guessing that'll not be possible since it seems aimed at VESA modes. 

So this version should in theory work better with the AVGA, and hopefully the network works so the 4350 can get logs, the sound might work on there too since I built in the older OSS support too besides just ALSA which might be what your sound card needs. 

I've been looking at the kernel stuff for the issue with the invalid fb id for the 4350, at least am getting more familiar with it but still can't see where it is not allocating that.  It'll probably help to have the complete log output of where that message is, maybe even the startup dmesg from the /var/log/dmesg too.  So I can trace through those and figure out each part of the code it uses on startup and the difference when it doesn't think the monitor is connected.

Thanks,
Chris

[Calamity]

I've tested 1.159 on the 4350 cab and the network still doesn't work (the system hangs). But I've managed to get the logs from there by formatting an usb pendrive with ext4 and copying the files there, the logs are attached. Hopefully there's some stuff there to start with. I also found the last version that had the network working for me, it was 1.02 32bit 12-10-2010_1291963428, so I also got the logs from there, it's interesting to notice that the drm error was not there at that point (??), however I've checked that opengl was crashing the system the same as now.

I've downloaded the new one, will test it soon.

[bitbytebit]

I've tested 1.159 on the 4350 cab and the network still doesn't work (the system hangs). But I've managed to get the logs from there by formatting an usb pendrive with ext4 and copying the files there, the logs are attached. Hopefully there's some stuff there to start with. I also found the last version that had the network working for me, it was 1.02 32bit 12-10-2010_1291963428, so I also got the logs from there, it's interesting to notice that the drm error was not there at that point (??), however I've checked that opengl was crashing the system the same as now.

I've downloaded the new one, will test it soon.

Sounds good, thanks, will look at the logs.  Also have gotten most of the cabmame patches to port (except sound sync of course) and not gotten changeres yet, so have the patch (not in the ISO yet) now basically almost the whole cabmame patch for both Windows/Linux and mame 140u2 (separate thread about cabmame in software is where I posted it, since people were wanting the cabmame patches for 140u2).  Also have a question about cleanstretch in there, since I got it ported better this time, but I now see an interesting difference between how it works in Linux vs. Windows because of the hwstretch Windows only option vs. the unevenstretch Linux option.

I'm thinking the network issue will be resolved most likely by 2.6.38, probably something in the -next branch of Linux they are refactoring or something.

[Calamity]

Good news, 1.165 is working flawlessly on my Avga cab!!!!, I mean all of it (console, x windows, mode switching, opengl), have to set to First Vga. On 4350 it has the same issue still, but this is promising. Writting from a mobile phone, more on this later.

[bitbytebit]

Good news, 1.165 is working flawlessly on my Avga cab!!!!, I mean all of it (console, x windows, mode switching, opengl), have to set to First Vga. On 4350 it has the same issue still, but this is promising. Writting from a mobile phone, more on this later.

Sounds great, I was  hoping for that, now know it seems we are down to either a Mesa bug or J-Pac/DRM detection issue for the 4350.  I have a patch they DRM developers applied to Mesa which they say will fix the Gallium bug and allow us to try Mesa with Gallium which possibly will bypass/fix the bug on the 4350.  It at least will hopefully let us use Gallium, which should be better, and also I have emailed Alex more info and the messages log of what's happening and explained the J-Pac issue to him to see what his thoughts are.  Also I think I have a more stable kernel which may fix audio/networking, just need to test it.  Seems the drm-next branch probably is better since it's just as up to date with the DRM changes but the rest of the kernel is the more stable 2.6.37-rcX series.  Since it seems 2.6.38 won't be seen out till probably March 2011 I figure it's better to use drm-next, probably stick with that branch since it's actually ahead of the linux-next for DRM video cards but the rest is pretty much stable (and DRM stuff looks to be good at keeping stable in that branch).

[Calamity]

It's very nice how this new version shows 15Khz nearly from the beginning, and when using the AVGA its 15Khz all the time. Something interesting is that you need to use FIRST VGA with this kernel, so that explains how before it was not consistent as the radeonfb used different names than drm. So now it's FIRST DVI for 4350 and FIRST VGA for 9250. I've been testing glxgears, wahcade, and mame games and all is working fine, mode switching is just a pleasure to the eye. On the less good side is that I have no sound either with this motherboard (older asus) but as you say this may eventually be solved with the new kernel.

So I'm eager to test the new Gallium stuff to see if the only remaining bug on the 4350 is finally bypassed. Something I really want to do know is to test more roms than the included ones, so will try to mount the harddrive next time. Btw I formatted an usb pendrive and installed the system in it, however I was unable to boot from it (it justs prompts to press any key or something, couldn't see it properly). I think I followed the steps, setup grub in it and marked the partition with the 'boot' flag but of course I could be missing something.

There's a chance that grub could also show 15 KHz, but it would be necessary to do some low level stuff with the bios modes (interrupt capturing and that). Is grub code available? Is it 16-bits? A folk from the Spanish forums made a program called Boot15Khz that resides on the partition or boot sector and does that, so it is possible indeed.

[bitbytebit]

It's very nice how this new version shows 15Khz nearly from the beginning, and when using the AVGA its 15Khz all the time. Something interesting is that you need to use FIRST VGA with this kernel, so that explains how before it was not consistent as the radeonfb used different names than drm. So now it's FIRST DVI for 4350 and FIRST VGA for 9250. I've been testing glxgears, wahcade, and mame games and all is working fine, mode switching is just a pleasure to the eye. On the less good side is that I have no sound either with this motherboard (older asus) but as you say this may eventually be solved with the new kernel.

So I'm eager to test the new Gallium stuff to see if the only remaining bug on the 4350 is finally bypassed. Something I really want to do know is to test more roms than the included ones, so will try to mount the harddrive next time. Btw I formatted an usb pendrive and installed the system in it, however I was unable to boot from it (it justs prompts to press any key or something, couldn't see it properly). I think I followed the steps, setup grub in it and marked the partition with the 'boot' flag but of course I could be missing something.

There's a chance that grub could also show 15 KHz, but it would be necessary to do some low level stuff with the bios modes (interrupt capturing and that). Is grub code available? Is it 16-bits? A folk from the Spanish forums made a program called Boot15Khz that resides on the partition or boot sector and does that, so it is possible indeed.

Yeah Grub is GNU project available here: http://www.gnu.org/software/grub/
There's a newer version, and older which is the one we are using since that is what Gentoo uses currently and newer one requires some system changes.  It would be nice to get grub to use 15khz itself, the newer version does the actual vesa mode stuff, I don't think the older version does but I might be wrong.   I've also with the newer build have reduced the size considerably of the ISO images, they had gotten a bit of bloat and I figured out how to clean the uneeded stuff from them to slim them down a lot more.  Will have new ISO's up later tonight if Gallium works and include the newer kernel in them too hopefully.

[Calamity]

I've downloaded grub-0.97 source (is that the one?) to have a look. I stage2 folder, there's a file asm.S. I think it could be done by editing the function set_vbe_mode, so that right after the mode is set with int 10h we should reprogram it using the methods in arcmon.asm, which source can be downloaded here:

http://www.mameworld.info/pc2jamma/downutil.html

I could do that for sure if it was plain assembly, but that c stuff in the middle of grub project neutralizes my powers, apart from the hell of trying to build that thing. But it seems possible indeed.

[bitbytebit]

I've downloaded grub-0.97 source (is that the one?) to have a look. I stage2 folder, there's a file asm.S. I think it could be done by editing the function set_vbe_mode, so that right after the mode is set with int 10h we should reprogram it using the methods in arcmon.asm, which source can be downloaded here:

http://www.mameworld.info/pc2jamma/downutil.html

I could do that for sure if it was plain assembly, but that c stuff in the middle of grub project neutralizes my powers, apart from the hell of trying to build that thing. But it seems possible indeed.

Oh cool, I can definitely handle the C side, assembly wise I'm probably useless .  That's the version in Gentoo, that we are using.  I can will look at the source and the link you sent, sounds neat.

[Gray_Area]

Having followed this thread a bit, and gotten a bit lost in the details - again, what are you trying to attempt here?...and what is your overall progress?

[bitbytebit]

Having followed this thread a bit, and gotten a bit lost in the details - again, what are you trying to attempt here?...and what is your overall progress?

We are trying to utilize the full potential of an arcade monitor for refresh rate exactness (to drive the game by that if possible, so avoid tearing at least expense of the system by following the video cards vsync interrupts), and general resolution/modeline duplication (similar to what Advanced Mame did/does but in a way that uses the systems native methods like the registry and xrandr in Linux, so we are able to keep it up to date and have it be more transparent and separate from Mame).  We want to do this equally well in both Linux and Windows, basically no limited modeline counts. 

So far the progress is, in Linux things are pretty much perfect if you have most Radeon cards, although there's some issues in the OpenGL side stopping certain ones from working.  I have a d9800 and can run everything just about perfect vsync and hxw, no throttle and no tearing or sound slowness or fastness. 

So far in Windows we have gotten the ability on the Radeon/ATI driver/cards to do about the same within limits of 60 predefined hxw combinations but we can dynamically rewrite those modelines to change the refresh rates to what we need (so mostly all games will be able to do the same as in Linux, but there's really 100 or so hxw modelines needed to match Linux with a few exceptions, possibly 160 or so to do just about the exact same in Windows).

Also out of this there's a Linux cabmame version able to utilize arcade monitors, same patches, plus it works in 140u2 for Windows too, extra benefit to help our goal of running full potential of arcade monitors there.   

So basically the ATI radeon drivers in Windows can eventually be patched to hold the needed 160 custom modelines, Calamity is working on that.  Would be nice to dynamically load modelines in all drivers for Windows, I'm not sure if that'll happen unless people figure out how to patch them (The ATI one seems to just do it with certain API calls done with it). 

In Linux we need to expand into other cards besides ATI Radeon ones, although the other drivers in Linux not as matured as the ATI DRM one currently (Nvidia and Intel ones *might* work though, untested).  Also figure out these OpenGL issues, in Linux it's best to build a distribution to do all this because it requires patches to the system and very new code they are just releasing combined with just the right build options and setup.  So we've done that, and it's working quite well besides rough edges and the compatibility.  We seem to be now figuring out some things about J-Pac support, there's a few issues there with driving it correctly since the system can't really sense the monitor so the issues are probably due to that.

Also of course the modeline generation of SwitchRes is quite nice and probably the best out there of any modeline generator for Arcade monitors, which was at first the main goal but it turns out to get those modelines to work on systems you have to do all the other work too.  Fortunately we have Soft15khz to do the registry setup of modelines in Windows for us to dynamically modify, and in Linux the DRM KMS kernel work and xrandr to push the modelines into work there. 

It's quite a list of stuff we want to do because of the goal of the full potential (arcade monitors and radeon cards, and others, in theory should be able to really get perfect display on a d9800, and near perfect for a lot of games on other monitors, which that hasn't ever been exploited before this), but we've done a lot too at the same time so that if you have a radeon card and arcade monitor both Windows and Linux have increased capability at display on arcade monitors with exact vsync within the monitors physical limitations.

[bitbytebit]

So I'm eager to test the new Gallium stuff to see if the only remaining bug on the 4350 is finally bypassed. Something I really want to do know is to test more roms than the included ones, so will try to mount the harddrive next time. Btw I formatted an usb pendrive and installed the system in it, however I was unable to boot from it (it justs prompts to press any key or something, couldn't see it properly). I think I followed the steps, setup grub in it and marked the partition with the 'boot' flag but of course I could be missing something.

Got a response back from Alex about the 4350 and J-Pac, he says try it with the env variable vblank_mode=0 (run `export vblank_mode=0` in xterm and then run glxgears or switchres).  Of course this avoids using the vblank interval, but still uses OpenGL, and at least would point out I guess the possible issue.  He says it might not work well for the vblank because of it running through J-Pac it can't see the monitor I guess, here's his full response.  I'm guessing there would still be a way around this, hopefully...

                  The connector stuff doesn't have any bearing on the accel code per se.
                   If you see a console or X, then the display side is fine even if you
                   have to force the display.  I suspect the black screen and slow issues
                   are due to vblank interrupt issues.  Most GL apps enable vsync by
                   default which may be problematic on jpac or on interlaced displays.
                   Try setting the env var vblank_mode=0 before starting a 3D app and see
                   if it helps.

Update: Also I tested this and it seems that vblank_mode=0 still allows the waitvsync option to work with nothrottle for mame, so I guess this isn't a bad thing if it works.
New kernel with drm failed with some bugs in memory and cdrom access being buggy, so I'm going back to the old one but I might have found the eth0 network issue oddly tied to the xorg-server for some reason and it not restarting X after config.  I'm testing a previous version of the xserver, that might be what changed and started the issue, also audio might be actually me not setting the mixer to unmute for the right card number.  Test possibly with running `alsamixer` and see if you can toggle cards and check, I now am unmuting 0-3 to be extra safe and that might help I hope. 

[bitbytebit]

It's very nice how this new version shows 15Khz nearly from the beginning, and when using the AVGA its 15Khz all the time. Something interesting is that you need to use FIRST VGA with this kernel, so that explains how before it was not consistent as the radeonfb used different names than drm. So now it's FIRST DVI for 4350 and FIRST VGA for 9250. I've been testing glxgears, wahcade, and mame games and all is working fine, mode switching is just a pleasure to the eye. On the less good side is that I have no sound either with this motherboard (older asus) but as you say this may eventually be solved with the new kernel.

So I'm eager to test the new Gallium stuff to see if the only remaining bug on the 4350 is finally bypassed. Something I really want to do know is to test more roms than the included ones, so will try to mount the harddrive next time. Btw I formatted an usb pendrive and installed the system in it, however I was unable to boot from it (it justs prompts to press any key or something, couldn't see it properly). I think I followed the steps, setup grub in it and marked the partition with the 'boot' flag but of course I could be missing something.

There's a chance that grub could also show 15 KHz, but it would be necessary to do some low level stuff with the bios modes (interrupt capturing and that). Is grub code available? Is it 16-bits? A folk from the Spanish forums made a program called Boot15Khz that resides on the partition or boot sector and does that, so it is possible indeed.

I'm uploading this version LiveCD32-MinimalNoMedia-1.191-9cdbada.iso which has hopefully fixed the network interface issue, maybe fixed audio, and now has a 'CD Acceleration' program under the Preferences menu.  The setting for vblank can be turned off there globally without setting the env variable, which when you test will be interesting to see if that fixes OpenGL on the 4350 with J-Pac.  You can also tune all the other settings for OpenGL in that program, which might be interesting to fiddle around with it and see if anything works.  The way the whole login and setup works has been improved, a large change which should avoid the weird network interface issue (seemed to be an interaction of the startup.pl script and X startup while setting up the network, all that doesn't happen anymore and startup.pl runs then exits and lets GDM take over after that to run X Windows).

I've been looking at the assembly in Grub and that program, definitely interesting and the assembly is quite crazy looking but at least it  shows it is possible.

The Gallium bugs are being worked on, they now have it run without a crash but it's a black screen for mame yet the game runs normal.  So I guess it's improving, although there's definitely something really weird going on and I wonder if it's possibly something Mame is doing, basically there's always a NULL buffer in the vertix buffers for the first one it seems.  Not sure why Gallium would suddenly find it, maybe it's Gallium, hopefully they figure more out.

[Calamity]

We hit the target now. With my HD4350, it works either with vblank_mode=1/0, fails with 2/3 (don't know what the default is, but could be 2 or 3?). gxlgears works, swithcres works. However there's indeed a problem with waitvsync when doing so. It's not vsynced actually, page flipping does work as there's no tearing and background flash lights in some games are solid, but the prompted fps doesn't match the target ones at all, it fluctuates around, so something is missed there when disabling vblank_mode. I believe that value must be on for things to work, but for some reason my video card + jpac combination is failing with it. I've found that the 3-4% fps I was getting before only happens when I press F11 to print the speed, and it also gets stuck when pressing tab for the osd, so it seems that the new page flipping is conflicting with Mame propting stuff on the screen for some reason, are you seeing this also?

I've run alsamixer and found that it's detecting two sound devices on my cab, the actual VIA integrated audiocard (1) and the hdmi audio part of the HD4350 (0). I can't toggle anything  but volume with this program I believe. In fact the VIA audiocard shows it's volume and everything is on ok, and the other one seems off. However in console 1 I'm getting this message:

ALSA lib pcm_dmix.c:1018:(snd_pcm_dmix_open) unable to open slave

[bitbytebit]

We hit the target now. With my HD4350, it works either with vblank_mode=1/0, fails with 2/3 (don't know what the default is, but could be 2 or 3?). gxlgears works, swithcres works. However there's indeed a problem with waitvsync when doing so. It's not vsynced actually, page flipping does work as there's no tearing and background flash lights in some games are solid, but the prompted fps doesn't match the target ones at all, it fluctuates around, so something is missed there when disabling vblank_mode. I believe that value must be on for things to work, but for some reason my video card + jpac combination is failing with it. I've found that the 3-4% fps I was getting before only happens when I press F11 to print the speed, and it also gets stuck when pressing tab for the osd, so it seems that the new page flipping is conflicting with Mame propting stuff on the screen for some reason, are you seeing this also?

I've run alsamixer and found that it's detecting two sound devices on my cab, the actual VIA integrated audiocard (1) and the hdmi audio part of the HD4350 (0). I can't toggle anything  but volume with this program I believe. In fact the VIA audiocard shows it's volume and everything is on ok, and the other one seems off. However in console 1 I'm getting this message:

ALSA lib pcm_dmix.c:1018:(snd_pcm_dmix_open) unable to open slave

It does fine here with the OSD, I'm guessing it is what Alex was talking about and  seems that it won't run without vblank/sync set differently or off (or fixed timing I think) and that doesn't allow it to perfectly match the game.  I do actually see that part here when turning off vblank, I thought it was not acting as smooth but it didn't tear and was able to run with nothrottle.  So at least we have some sort of insight into what is happening, seems that a J-Pac setup doesn't allow the radeon DRM stuff to activate using the cards interrupts to match the blanking of the monitor.  I think that makes sense too, it's just odd though and would think there's a way around this somehow.  I'll tell Alex what we've found, also the newer ISO will have that DRI utility which actually labels what each of those values are so you'll be able to know exactly what the meaning is of the ones that work and ones that don't. 

They basically have:
* Never synchronize with vertical refresh, ignore applications choice
* initial swap interval 0, obey applications choice
* initial swap interval 1, obey applications choice
* Always synchronize with vertical refresh, application chooses the minimum swap interval

I think those are in order from 0 - 3, and default is probably 3 I think.  I would think they could figure out a way to make this work on J-Pac, you might have more insight though than me on how the monitor/video card work together (or if they really actually need to) for knowing when a vblank occurs and how to implement this vblank stuff properly even if the monitor can't be seen (or is that even possible, can windows really do this, how does it get by if it does).

My laptop I am testing the basic interface on also has sound card issues, I think it's because it's trying to use the HDMI output.  Try this, make a .asoundrc file in the /home/arcade/ directory with this in it...

Code: [Select]

pcm.!default {
type hw
card 1
}

ctl.!default {
type hw
card 1
}

Here's a page talking about this more, can also try aplay -l to see all cards and know what number to use above.

http://www.linuxquestions.org/questions/slackware-14/no-sound-with-flash-player-in-firefox-after-adding-nvidia-gt-220-graphics-card-809773/

[Calamity]

Vsync is working smoothly in Windows with this same card, so it's possible indeed. As for the jpac, I am almost sure it was vsynced yesterday with on AVGA card (jpac also there). So this sounds as one of those new EDID philosophy 'features' of newer cards related to not feeling monitors, as the one of turning off video, vsync support might be internally disabled. Technically vsync is something internal to the videocard, as it's the videocard the one driving the electron beam, not the opposite, so it's the card who knows when it's sending its vblank signal, so the jpac should not matter here unless the driver is designed to do so.

I'll keep testing with the new iso and all those options.

Btw I think it's highly possible that I can do the assembly patch for grub, provided it works as I think it does and you can build it later, so I won't be able to test it here. By now it will need to be fixed to plain text mode (mode 03h) but it will be enough for a menu. The opcode's parameter format of that assembler is opposite of what I'm used to, but I think it won't be difficult to convert arcmon.asm into that.

[bitbytebit]

Vsync is working smoothly in Windows with this same card, so it's possible indeed. As for the jpac, I am almost sure it was vsynced yesterday with on AVGA card (jpac also there). So this sounds as one of those new EDID philosophy 'features' of newer cards related to not feeling monitors, as the one of turning off video, vsync support might be internally disabled. Technically vsync is something internal to the videocard, as it's the videocard the one driving the electron beam, not the opposite, so it's the card who knows when it's sending its vblank signal, so the jpac should not matter here unless the driver is designed to do so.

I'll keep testing with the new iso and all those options.

Btw I think it's highly possible that I can do the assembly patch for grub, provided it works as I think it does and you can build it later, so I won't be able to test it here. By now it will need to be fixed to plain text mode (mode 03h) but it will be enough for a menu. The opcode's parameter format of that assembler is opposite of what I'm used to, but I think it won't be difficult to convert arcmon.asm into that.

Ah, interesting, so it's not really the J-Pac alone but the card is helping make it somehow trigger the DRM layer to decide not to support the vsync.

The newer iso is uploaded, I think it'll solve the network issue and here I was able to get sound to work with that .asoundrc file trick, I had to pick 2 on this laptop it seemed.  The output of aplay -l really helped, I suspect it's doing the same thing there and needs this.  I need to figure out how that normally is automated in sound setup, possibly a menu option I guess or script to check for it.  There's actually a program alsaconf that if you run it may actually do all that for you, I'll need to look at possibly running that on first startup and save the config or something.

That would be great, sounds amazing to get grub to output 15khz, we'd basically be close as possible to the AVGA card then in Linux without it needed to be AVGA or even Radeon/ATI cards possibly in the future.

[Calamity]

I've ported the Arcmon.asm code into AT&T inline assembly syntax, bear in mind it's the first time I use this syntax so it's likely to contain errors, though I've tried to do it as well as possible. The attached file contains the proc named set_arcade_mode which needs to be copied into /stage2/asm.S grub's source file, possibly below set_vbe_mode function. Then this proc must be used in substitution of set_vbe_mode in builtins.c where it's used, and should be referenced also I think in files shared.h and asmstub.c. Let me know if you are able to compile it, or send me the errors in case it's not possible. If you are going to test this, please make sure you have a way to undo changes before updating the boot sectors and stuff as this could fail (probably) as it's untested, and the hd could become unbootable. Is there a way to test this virtually or something?

[bitbytebit]

I've ported the Arcmon.asm code into AT&T inline assembly syntax, bear in mind it's the first time I use this syntax so it's likely to contain errors, though I've tried to do it as well as possible. The attached file contains the proc named set_arcade_mode which needs to be copied into /stage2/asm.S grub's source file, possibly below set_vbe_mode function. Then this proc must be used in substitution of set_vbe_mode in builtins.c where it's used, and should be referenced also I think in files shared.h and asmstub.c. Let me know if you are able to compile it, or send me the errors in case it's not possible. If you are going to test this, please make sure you have a way to undo changes before updating the boot sectors and stuff as this could fail (probably) as it's untested, and the hd could become unbootable. Is there a way to test this virtually or something?

I just have to use it I think on the liveCD and it should, or USB stick, and if it fails only will hurt the CD .  It compiles, I just had to change the comments from ; to // and then it compiled fine, I'll be testing it and let you know how it works.  Sounds really awesome.

[Calamity]

Great. Also make sure you are not passing any param to this proc as it does not use any, unlike the set_vbe_mode that needed the mode number to be passed to it.

[bitbytebit]

Great. Also make sure you are not passing any param to this proc as it does not use any, unlike the set_vbe_mode that needed the mode number to be passed to it.

It's interesting, that part of grub's code basically is a command available if you drop to a command prompt at the grub menu with 'c'.  It's testvbe MODE, so I tried that and passed 768 to it, since I was guessing number wouldn't matter since this new function overrides the choice.  It just got something out of range though and the monitor went into standby mode like it wasn't connected though.  I'm thinking this is actually testing it, what mode number is this actually using?  This is a good way to test it, but looks like with grub we'll need to find another entry point to place it I guess.  I'll look more into how it fits.

[Calamity]

I see, I was doubting if it was the right point to place the function. But is the arcade monitor out of range when testing it? It's using mode number 03h, the standard BIOS text mode, by calling int 10h to set the mode, and after that it's tweaking the crtc stuff to modify it to 15KHz. So if the mode is working, it would be a matter of calling the proc right before the menu options are printed.

[dmarcum99]

Hi guys!

Does switchres have the ability to generate all the modelines used by the games in mame at one time?  I recall LRMC has that ability by using the "mamelist.xml > xxxxx.txt" command....

Also, I read in the description that switchres can read a config file where you can specify your custom monitor setting..??  How would I go about this and what format does this monitor info need to be in?  In LRMC I can enter the monitor specs kinda like advame...." 3 - 40 / 15.5 - 50.5 / 40-120 " and list a couple of reference modes.  I just want to make sure I can use your program to the fullest with my monitor. (NEC XM-2950) if this is genererating better modelines.

[bitbytebit]

Hi guys!

Does switchres have the ability to generate all the modelines used by the games in mame at one time?  I recall LRMC has that ability by using the "mamelist.xml > xxxxx.txt" command....

Also, I read in the description that switchres can read a config file where you can specify your custom monitor setting..??  How would I go about this and what format does this monitor info need to be in?  In LRMC I can enter the monitor specs kinda like advame...." 3 - 40 / 15.5 - 50.5 / 40-120 " and list a couple of reference modes.  I just want to make sure I can use your program to the fullest with my monitor. (NEC XM-2950) if this is genererating better modelines.

There's a perl script called genres.pl here...

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

It does the generation for all the different modelines in mame games now, has some command line options which should explain the usage.  It's of course most of the time no longer needed since switchres can do this dynamically, but more useful in Windows to create a table of modelines for Soft15khz and we can work off of that to change them dynamically to what we need.

In the switchres.conf file, can be under /etc/ or in the home directory, you can either say mon=<TYPE> which is quite extensive actually but for your monitor since seems even more than a d9800, you could do something like this...

You can have as many of these as you need, can also use on the command line with --mrange "line"...

MonitorLimits 15500-50000,40-120,2.187,4.688,6.719,0.190,0.191,1.018,0,0,576,768

Although the values past the V refresh above are Horizontal front porch, sync pulse, back porch, and Vertical ones, then positive or negative Hsync,Vsync, and max active lines, and max size to interlace/virtualize at.  So they might be different, and breaking it up into ranges for each set of front porch/sync pulse/back porches might be the right thing to do (for a d9800 there's about 5 ranges). 

Here's an example config:
http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=blob_plain;f=src/SwitchResC/extra/switchres.conf;hb=HEAD