Switchres: modeline generator engine

[Calamity]

Ah just found a bug, where I transfered over the values for the h9110 wrong, did the same timing vertically as the cga definition, not sure if that is an issue...

That wouldn't be really important but for 256 lines modes and such, where you might start loosing lines at the top of the screen, this is a different issue, believe me.

Also I'm wondering if that's an issue, how the h9110 has a lower Hfreq range, not 15.725-15.750 like the generic cga monitor would have?   How does that work, I'm pretty sure the Soft15Khz modelines and ArcadeVGA ones all tune to 15.750 but in the definition for it it's lower than that...

H9110 has a range that covers 1 KHz (a bit more), so CGA range is included inside H9110 range. You can move that 1 KHz range up and down a little bit using a potenciometer, so if I set it so it can synchronize at 16.7 KHz (256 lines@60 Hz), then the lowest frequency it will admit is more or less 15.62 KHz. I can adjust the potenciometer down so I can use frequencies like 15.5 KHz, but then it will only admit 16.5 Khz or so on the upper side.

[Calamity]

So sounds like probably the modelines are ok, I'm going to change them though or add these new ones I think and maybe make 320x240 default since we don't need a big console for the menu for now (and I'm hopefully going to move that into X Windows I think, at least seems like it's possible to just check and use the same modeline we booted with at the menu prompt and a 640x480 interlaced default should in theory work for everyone except TV users and I'd check for that).

640x480i is perfect for TV users also, no problem with that. 

Does X fix the console though, to look normal, that would be something somewhat hopeful seeing that it's just the DRM layer not getting the ATOM bios programmed right for the frame buffer (although it's odd since it in theory is programming the X Windows modelines too), and on the other card the 4850 maybe if X started up on boot perhaps that'd also fix it if the DRM layer isn't breaking. 

I believe DRM is not crashing with HD4350 as even with no video I was typing random stuff through your menus and could hear the cd spinning and stopping when doing that. It's just turning the video off, as when I boot in Windows with the cable connected to the vga output.

[bitbytebit]

So sounds like probably the modelines are ok, I'm going to change them though or add these new ones I think and maybe make 320x240 default since we don't need a big console for the menu for now (and I'm hopefully going to move that into X Windows I think, at least seems like it's possible to just check and use the same modeline we booted with at the menu prompt and a 640x480 interlaced default should in theory work for everyone except TV users and I'd check for that).

640x480i is perfect for TV users also, no problem with that. 

Does X fix the console though, to look normal, that would be something somewhat hopeful seeing that it's just the DRM layer not getting the ATOM bios programmed right for the frame buffer (although it's odd since it in theory is programming the X Windows modelines too), and on the other card the 4850 maybe if X started up on boot perhaps that'd also fix it if the DRM layer isn't breaking. 

I believe DRM is not crashing with HD4350 as even with no video I was typing random stuff through your menus and could hear the cd spinning and stopping when doing that. It's just turning the video off, as when I boot in Windows with the cable connected to the vga output.

Ah cool, that's good to know it's not crashing at least, so can get dmesg output's and those should partly help clear it up I think.  Next version of the .iso will have more debug information output about DRM for dmesg to show, so that might even be better but it should probably say something interesting in the logs/dmesg still.  I need to enable the first ethernet interface I guess by default to make it easier to get into the system remotely in situations like this, that blind menu thing is definitely a pain, and of course maybe it's fixed in the newer linux kernel since I do see they yet again have done more changes to the atom bios stuff.  I'll hopefully have new .iso images by later tonight that may help make it easier to diagnose the issue, and probably will boot straight into X Windows if I find that easy to implement quickly.

[bitbytebit]

I have a theory about the AVGA card, what it's doing.  Seems it always doubles the Hfreq when trying to actually program the thing through the ATOM bios with the DRM layer.  Would the hacks to make the BIOS do all the modelines in Windows and the bootup BIOS at 15Khz be possibly some kind of thing where he's taking the values given and doing some calculations with them, like it seems to be twice as much and when given this 640x480 15khz mode it's like you see and when I gave it the 640x480 31.5 Khz mode I think it was again way higher than that plus was oddly blurry too.  If we only could figure out the actual calculations to feed the card to get the actual output we want, I get the feeling it's some kind of algorithm, I guess it'd be in the clock stuff in the DRM part of the kernel where it'd need different programming values.  It worked in the old X Windows somewhat probably because it didn't really work with the ATOM bios there ever, now it does, and seems those clocks are needing to have different program methods than the normal ATI bios ones.  I would guess the Windows drivers might be able to listen to the bios better and know what it wants, while the Linux stuff probably isn't that mature to know what the bios wants and a lot of hardcoding of values seem to still be in the linux kernel drm stuff for the radeon. 

Again this might explain the other card too, I know that the x850 card I have doesn't show the console either, but when I start X Windows it does.  So that gives some hope for getting X Windows to startup automatically, might solve the problem.  Interesting that your card shows this issue too, I thought that was just the x850 being an oddball and having that strange cable requirement for the crossfire stuff plus having only one actual output since the others a proprietary cable connector.

[Calamity]

I have a theory about the AVGA card, what it's doing.  Seems it always doubles the Hfreq when trying to actually program the thing through the ATOM bios with the DRM layer.  Would the hacks to make the BIOS do all the modelines in Windows and the bootup BIOS at 15Khz be possibly some kind of thing where he's taking the values given and doing some calculations with them, like it seems to be twice as much and when given this 640x480 15khz mode it's like you see and when I gave it the 640x480 31.5 Khz mode I think it was again way higher than that plus was oddly blurry too.  If we only could figure out the actual calculations to feed the card to get the actual output we want, I get the feeling it's some kind of algorithm, I guess it'd be in the clock stuff in the DRM part of the kernel where it'd need different programming values.  It worked in the old X Windows somewhat probably because it didn't really work with the ATOM bios there ever, now it does, and seems those clocks are needing to have different program methods than the normal ATI bios ones.  I would guess the Windows drivers might be able to listen to the bios better and know what it wants, while the Linux stuff probably isn't that mature to know what the bios wants and a lot of hardcoding of values seem to still be in the linux kernel drm stuff for the radeon.

I hadn't thought much about that, but are those consoles using by chance text modes? Text modes have a different nature than graphic modes. All the modeline stuff we've been discussing here is valid for graphic modes. However, text modes might follow a different path within the drivers. Windows drivers are only capable of graphic modes, as far as I know. AVGA Bios (at least the older one) is ignored when the Windows drivers take control, so there's no need for them to care about its patches. But the BIOS text modes are indeed invoked when we set a DOS text console to full screen.

Again this might explain the other card too, I know that the x850 card I have doesn't show the console either, but when I start X Windows it does.  So that gives some hope for getting X Windows to startup automatically, might solve the problem.  Interesting that your card shows this issue too, I thought that was just the x850 being an oddball and having that strange cable requirement for the crossfire stuff plus having only one actual output since the others a proprietary cable connector.

That sounds possible in fact.

[bitbytebit]

I have a theory about the AVGA card, what it's doing.  Seems it always doubles the Hfreq when trying to actually program the thing through the ATOM bios with the DRM layer.  Would the hacks to make the BIOS do all the modelines in Windows and the bootup BIOS at 15Khz be possibly some kind of thing where he's taking the values given and doing some calculations with them, like it seems to be twice as much and when given this 640x480 15khz mode it's like you see and when I gave it the 640x480 31.5 Khz mode I think it was again way higher than that plus was oddly blurry too.  If we only could figure out the actual calculations to feed the card to get the actual output we want, I get the feeling it's some kind of algorithm, I guess it'd be in the clock stuff in the DRM part of the kernel where it'd need different programming values.  It worked in the old X Windows somewhat probably because it didn't really work with the ATOM bios there ever, now it does, and seems those clocks are needing to have different program methods than the normal ATI bios ones.  I would guess the Windows drivers might be able to listen to the bios better and know what it wants, while the Linux stuff probably isn't that mature to know what the bios wants and a lot of hardcoding of values seem to still be in the linux kernel drm stuff for the radeon.

I hadn't thought much about that, but are those consoles using by chance text modes? Text modes have a different nature than graphic modes. All the modeline stuff we've been discussing here is valid for graphic modes. However, text modes might follow a different path within the drivers. Windows drivers are only capable of graphic modes, as far as I know. AVGA Bios (at least the older one) is ignored when the Windows drivers take control, so there's no need for them to care about its patches. But the BIOS text modes are indeed invoked when we set a DOS text console to full screen.

Again this might explain the other card too, I know that the x850 card I have doesn't show the console either, but when I start X Windows it does.  So that gives some hope for getting X Windows to startup automatically, might solve the problem.  Interesting that your card shows this issue too, I thought that was just the x850 being an oddball and having that strange cable requirement for the crossfire stuff plus having only one actual output since the others a proprietary cable connector.

That sounds possible in fact.

The older Linux console uses text mode, 80x24 or something like that.  I think grub actually is either doing that or it's using a VESA BIOS mode number, newer grub versions like in ubuntu do the gfx or graphics boot I guess but I think this older on in gentoo does text mode till it hits the DRM layer. 

So an NTSC TV and PAL one, don't they require a different version of the 640x480@60i modeline or would that supposidly work on everything?  Since booting into X Windows would be much simpler if that were true, else I have to figure out which type of monitor is in use to get the Xorg modeline setup.  Then at the grub prompt it'd have to choose by which one is picked there, which really all I have to go by is what resolution is chosen so it'd have to be a different one per monitor type in hxw.  Then if they can't see that grub prompt, although I suspect all TV users would? but maybe not, well then if not seen there's a problem there since it'll default to CGA mode in grub since for an arcade monitor that'll make it work mostly.  If there was one single modeline that worked on everything, that would be nice, since I can't see how to know what monitor they are using other than guessing it's an arcade one and the TV then might not be able to get chosen interactively. 

[Calamity]

I'd bet that 640x480@60i modeline should work on any tv, either ntsc or pal. It might happen that some old pal tvs might only sync at 50Hz but we shouldn't care about that now, think that AVGA only has that 640x480 mode and is supposed to work with any tv.

[bitbytebit]

I'd bet that 640x480@60i modeline should work on any tv, either ntsc or pal. It might happen that some old pal tvs might only sync at 50Hz but we shouldn't care about that now, think that AVGA only has that 640x480 mode and is supposed to work with any tv.

Should all arcade monitors/TV's work with text mode of 80x25?  Is that something to try and get at the grub prompt, seems it probably is going into a VESA mode at the prompt and sounds like there might be a way to get it to use text mode.

[Calamity]

Don't think so, BIOS text modes are usually high resolution modes unless you use a real CGA text mode with 8x8 pixels size characters (640x200), but even then the BIOS would activate doublescan in order to achieve a VGA compatible frequency I believe, so you may need low level patching (I suppose that's what AVGA does). You have to deal with characters height in order to program a text mode, graphic mode's characters are 1 pixel high.

[bitbytebit]

Don't think so, BIOS text modes are usually high resolution modes unless you use a real CGA text mode with 8x8 pixels size characters (640x200), but even then the BIOS would activate doublescan in order to achieve a VGA compatible frequency I believe, so you may need low level patching (I suppose that's what AVGA does). You have to deal with characters height in order to program a text mode, graphic mode's characters are 1 pixel high.

So I guess the best approach is to use the 640x480 interlaced modeline, boot up into the framebuffer and then start X Windows using that same modeline too.  From there present the setup menu in an xterm, then launch the window manager.  Sounds like I can use that 640x480 interlaced resolution then, and if the user picks another monitor possibly tune xorg.conf to use that type instead and optimize the modeline perhaps.

[Calamity]

Sure, that would make a rather universal stuff for lowres/multisync crts, and then on a second boot you could have it set up for other monitors. BTW, where's that configuration data supposed to be stored if I have a single NTFS partition in my hd? Will it create its own directory somewhere won't it?

[bitbytebit]

Sure, that would make a rather universal stuff for lowres/multisync crts, and then on a second boot you could have it set up for other monitors. BTW, where's that configuration data supposed to be stored if I have a single NTFS partition in my hd? Will it create its own directory somewhere won't it?

Well in Linux the NTFS file system isn't writable, it's read only because of dangers writing to NTFS from another operating system other than Windows.  So it'd not be able to do it, normally if a partition is chosen to mount to home I'm (in this newest version not up yet) using a .gentooarcade/config file and store config files in that directory.  The drive/partition could be a usb stick or drive, anything, but needs to be a Linux one like ext4 fs right now to allow writing to it.  I still need to make an option in the menu to actually partition and format if wanting to use an unsetup drive without a partition or the partition not being ext4 fs yet.  It can be a very tiny partition of course, just really will hold text based config files, while the ROMS partition could be NTFS or anything that Linux supports for read access.  A 50 megabyte partition would be more than enough for it for example, but of course the whole user interface isn't there yet to setup such a thing unless you know about using fdisk and running the ext2fs tools on the command line.

I think I have the kernel patch improved a bit to actually be a bit more arcade monitor friendly in how it acts without an EDID, so it'll do the arcade resolutions if no EDID exists no matter what.  In theory it negates the need for the kernel command line option and makes it easier to mix/match monitor types without having to tell the video= parameter what each one is.  Need to test it though and see, takes awhile to compile so I can start looking at getting X Windows to start automatically.  Should be able to have the menu config happen, then restart X automatically with the new modeline, and go on into the window manager.  Shouldn't need a reboot at all .

[bitbytebit]

I'm uploading new .iso images now, should be a few hours before they are up there, will be livecd32_12-03-2010_1291434263.iso and livecd64_12-03-2010_1291434978.iso.  These should boot directly into X Windows and use the newest kernel, more statefull saving of configured information if there's a home directory.   Also the enable the ethernet interface by default when booted the first time and in configuration mode, so should be able to get into them easier if they don't work and see what the logs say.  There's definitely a few rough edges still but should be good hopefully to test the theory that X Windows may work while the DRM console doesn't. 

[bitbytebit]

I'm uploading new .iso images now, should be a few hours before they are up there, will be livecd32_12-03-2010_1291434263.iso and livecd64_12-03-2010_1291434978.iso.  These should boot directly into X Windows and use the newest kernel, more statefull saving of configured information if there's a home directory.   Also the enable the ethernet interface by default when booted the first time and in configuration mode, so should be able to get into them easier if they don't work and see what the logs say.  There's definitely a few rough edges still but should be good hopefully to test the theory that X Windows may work while the DRM console doesn't. 

Ah found a bug in the new one, well a couple :/.  Will let you know when I get them fixed, had restricted the xorg.conf hsync too tightly for the generic modeline used to setup, and the kernel changes seem to have totally allowed the frame buffer to be way too free with what modelines it used too.

[bitbytebit]

Sure, that would make a rather universal stuff for lowres/multisync crts, and then on a second boot you could have it set up for other monitors. BTW, where's that configuration data supposed to be stored if I have a single NTFS partition in my hd? Will it create its own directory somewhere won't it?

I've found something interesting, from the changes I made to the newer .iso which had problems it's led me to see a little more of how the DRM stuff works with the modelines.  I realized that the default modelines are all basically divided by 1000, so 6000 is 6Mhz actually.  Well looking through the code more I see that what they are doing is in the DRM layer having it all the value divided by 1000 so the precision of course is never better than that and when we have anything more precise it's probably being rounded/aligned to 1000 for the pixel clock.  I see they then multiply that value by 1000 again to grow it back to the right amount before directly feeding the hardware, so it's not like the hardware wants it like this and they do it generically for all drivers using the DRM layer. 

So is it worth it to go through and make this accept the Mhz correctly and not divided by 1000, how much is that going to be an issue in being exact?  I'm guessing this goes on from the top to bottom, from the X server possibly although I'm not sure if it's input is divided by 1000 when hitting the DRM layer, and then throughout the DRM layer and into each individual DRM driver.  So it'd all have to be overhauled, quite irritating they chose to be so rough with the calculations but then again I guess those CVT calculations always do similar stuff it seems and that seems to be all they have really counted on getting else an EDID modeline from the display.

I do think the way I'm doing the setup should be good now, but I changed the kernel somewhat and it allowed the crazy modelines back in and didn't for some reason take my custom ones on the FB (which wouldn't have mattered now if the extra modelines didn't creep in).  I at least know what to fix and am fixing it, and it's showing me more insight into how the DRM stuff works too.  Hopefully have a good working ISO up here later today.

[Calamity]

I've tried your second liveCD in my HD4350 cab. I still can't get into X Windows, I just get stuck with the black screen. So I've returned to your first liveCD, to try to follow the sequence you posted. However I can't get into X Windows either, so I'm trying to access it by ssh at least. I have my HD4350 cab plugged to the router, I'm seeing it as 192.168.0.100 arcade in my laptop, but when I try to ssh it (OpenSSH) I'm getting this:

ssh root@192.168.0.100
ssh: connect to host 192.168.0.100 port 22: Connection refused

[Calamity]

Sure, that would make a rather universal stuff for lowres/multisync crts, and then on a second boot you could have it set up for other monitors. BTW, where's that configuration data supposed to be stored if I have a single NTFS partition in my hd? Will it create its own directory somewhere won't it?

I've found something interesting, from the changes I made to the newer .iso which had problems it's led me to see a little more of how the DRM stuff works with the modelines.  I realized that the default modelines are all basically divided by 1000, so 6000 is 6Mhz actually.  Well looking through the code more I see that what they are doing is in the DRM layer having it all the value divided by 1000 so the precision of course is never better than that and when we have anything more precise it's probably being rounded/aligned to 1000 for the pixel clock.  I see they then multiply that value by 1000 again to grow it back to the right amount before directly feeding the hardware, so it's not like the hardware wants it like this and they do it generically for all drivers using the DRM layer. 

So is it worth it to go through and make this accept the Mhz correctly and not divided by 1000, how much is that going to be an issue in being exact?  I'm guessing this goes on from the top to bottom, from the X server possibly although I'm not sure if it's input is divided by 1000 when hitting the DRM layer, and then throughout the DRM layer and into each individual DRM driver.  So it'd all have to be overhauled, quite irritating they chose to be so rough with the calculations but then again I guess those CVT calculations always do similar stuff it seems and that seems to be all they have really counted on getting else an EDID modeline from the display.

I do think the way I'm doing the setup should be good now, but I changed the kernel somewhat and it allowed the crazy modelines back in and didn't for some reason take my custom ones on the FB (which wouldn't have mattered now if the extra modelines didn't creep in).  I at least know what to fix and am fixing it, and it's showing me more insight into how the DRM stuff works too.  Hopefully have a good working ISO up here later today.

Interesting... but which of the values are being divided by 1000, dotclocks only or the other stuff too??? This is similar of what happens in Windows, where if you need to have, say 6.596345 MHz for the dotclock, then the most accurate you can be is the integer 659 figure, are you able to be more accurate there?

[bitbytebit]

I've tried your second liveCD in my HD4350 cab. I still can't get into X Windows, I just get stuck with the black screen. So I've returned to your first liveCD, to try to follow the sequence you posted. However I can't get into X Windows either, so I'm trying to access it by ssh at least. I have my HD4350 cab plugged to the router, I'm seeing it as 192.168.0.100 arcade in my laptop, but when I try to ssh it (OpenSSH) I'm getting this:

ssh root@192.168.0.100
ssh: connect to host 192.168.0.100 port 22: Connection refused

Yeah the second was a flop it turns out but helped me figure some things out.  I've got another about to upload as  soon as the ISO images are done, this one looks pretty good at being able to boot directly into X to setup, then it restarts with the new settings and on future reboots if there was a home directory used it'll boot straight into X windows with the pre-configured setup.   It'll be a good test at least, should be able to get your system into X Windows whether or not the frame buffer works, and see what happens then.  Now basically the frame buffer isn't ever really used, so doesn't matter if it doesn't show up.  There's no real way to get into this one remotely before a setup is done, but hopefully we won't need to anyways.  Setting up remote access hopefully won't be necessary, I *think* once we get into X Windows we're safe, at least hopefully so.

I'll post again when it's uploaded, probably be a few hours at most.

[bitbytebit]

Sure, that would make a rather universal stuff for lowres/multisync crts, and then on a second boot you could have it set up for other monitors. BTW, where's that configuration data supposed to be stored if I have a single NTFS partition in my hd? Will it create its own directory somewhere won't it?

I've found something interesting, from the changes I made to the newer .iso which had problems it's led me to see a little more of how the DRM stuff works with the modelines.  I realized that the default modelines are all basically divided by 1000, so 6000 is 6Mhz actually.  Well looking through the code more I see that what they are doing is in the DRM layer having it all the value divided by 1000 so the precision of course is never better than that and when we have anything more precise it's probably being rounded/aligned to 1000 for the pixel clock.  I see they then multiply that value by 1000 again to grow it back to the right amount before directly feeding the hardware, so it's not like the hardware wants it like this and they do it generically for all drivers using the DRM layer. 

So is it worth it to go through and make this accept the Mhz correctly and not divided by 1000, how much is that going to be an issue in being exact?  I'm guessing this goes on from the top to bottom, from the X server possibly although I'm not sure if it's input is divided by 1000 when hitting the DRM layer, and then throughout the DRM layer and into each individual DRM driver.  So it'd all have to be overhauled, quite irritating they chose to be so rough with the calculations but then again I guess those CVT calculations always do similar stuff it seems and that seems to be all they have really counted on getting else an EDID modeline from the display.

I do think the way I'm doing the setup should be good now, but I changed the kernel somewhat and it allowed the crazy modelines back in and didn't for some reason take my custom ones on the FB (which wouldn't have mattered now if the extra modelines didn't creep in).  I at least know what to fix and am fixing it, and it's showing me more insight into how the DRM stuff works too.  Hopefully have a good working ISO up here later today.

Interesting... but which of the values are being divided by 1000, dotclocks only or the other stuff too??? This is similar of what happens in Windows, where if you need to have, say 6.596345 MHz for the dotclock, then the most accurate you can be is the integer 659 figure, are you able to be more accurate there?

Just the dotclock, and that value in Linux it seems to turn into 6596 * 1000, so it's a little more accurate but just not exact.  I emailed the Alex guy that does the DRM ATI stuff and hopefully he helps at least give some idea of the amount of work it is to change this, and if he'll at all help or if they care at all.  I definitely looks like a big job to go through the whole DRM layer and change this calculation, there's so much stuff there unfortunately that's very complex and hard to fully understand since it's been pulled probably from datasheets and not fully explained in the code or wanting people to understand it since it's from proprietary companies stuff/intellectual property just given out to let Linux work.  At least it's making me look closer at the clock and pll calculations, but they are definitely crazy and complex, and I just get the feeling it's like most chip stuff where the things they are doing aren't going to make much sense unless you saw the secret datasheets and then it's usually filled with workarounds for all the bugs in the asic they have to avoid, so not easy to go through and just alter values to what seems like it'd be correct and to change the divide by 1000 part I'm probably going to have to try and understand a lot of the obfuscated code. I guess it's working pretty well as it is, but I do see some oddness in the frame buffer modelines at least, I think this at least explains why it's just slightly off always and like 99.999% correct but missing that .1 percent, how pacman runs at 60.599 probably instead of 60.606... or something.  It does explain something though, when I had the code doing the checks for the vertical refresh I saw that aligning everything to 1000 seemed to somewhat work well, I do remember that was a good number.  The only thing was I didn't like how lines were added to do so and then it always seemed like it took longer and I don't know if my calculations were really as good as yours were.  I need to revisit that possibly, although the best solution of course is to go through the DRM code and make it use the exact dotclocks we give it, but I'm worried that'll end up needing to change xrandr and Xorg too, which hopefully the Alex guy can answer those questions and maybe give more information on why it's done.  I think it's just an age old way that the framebuffer always worked in Linux, they just used the reduced values from what I can tell, and seems no one thought to ever make it more precise.

[bitbytebit]

The 32bit version has uploaded to test.

Also here's the reply back from the Alex guy, seems like he's saying it doesn't matter?


                    The pixel clock is stored in khz units in the mode structs in the
                   |kernel and in X.  We expand it to hz in the pll divider calculations.
                   |Then it's reduced to 10 Khz units for the atom methods, but at this
                   |point it doesn't matter as the pll dividers have already been
                   |calculated, so I don't think it's an issue.

[Calamity]

The 32bit version has uploaded to test.

Also here's the reply back from the Alex guy, seems like he's saying it doesn't matter?


                    The pixel clock is stored in khz units in the mode structs in the
                   |kernel and in X.  We expand it to hz in the pll divider calculations.
                   |Then it's reduced to 10 Khz units for the atom methods, but at this
                   |point it doesn't matter as the pll dividers have already been
                   |calculated, so I don't think it's an issue.

I don't understand what 'atom methods' would require dotclock values once the pll dividers have been worked out, however we could check if we can add the extra digits when it's expanded into hz, right before the pll divider is calculated, and see if it makes any difference.

I'll test the new version in a while.

UPDATE: I've tested new version of liveCD 32, with HD4350, unfortunately with same results (black screen), have tested also 320x240 init mode but makes no difference. I can't see the arcade machine in the network now either. I'm starting to think that it's related to the card, not for it being faulty as it's working well, but for some reason the video is turned off when it reaches that point (DRM?), maybe for not detecting any monitor or whatever else, but it's interesting that the same code was more or less working with old AVGA 9250 (I tested liveCD 32 version 1) and same monitor. So I definitely need to test this stuff with the HD4350 plugged to a pc monitor to check if I have video with it. Unfortunately I don't have one around at this place where the cab is but will try to get one here soon.

[bitbytebit]

The 32bit version has uploaded to test.

Also here's the reply back from the Alex guy, seems like he's saying it doesn't matter?


                    The pixel clock is stored in khz units in the mode structs in the
                   |kernel and in X.  We expand it to hz in the pll divider calculations.
                   |Then it's reduced to 10 Khz units for the atom methods, but at this
                   |point it doesn't matter as the pll dividers have already been
                   |calculated, so I don't think it's an issue.

I don't understand what 'atom methods' would require dotclock values once the pll dividers have been worked out, however we could check if we can add the extra digits when it's expanded into hz, right before the pll divider is calculated, and see if it makes any difference.

I'll test the new version in a while.

UPDATE: I've tested new version of liveCD 32, with HD4350, unfortunately with same results (black screen), have tested also 320x240 init mode but makes no difference. I can't see the arcade machine in the network now either. I'm starting to think that it's related to the card, not for it being faulty as it's working well, but for some reason the video is turned off when it reaches that point (DRM?), maybe for not detecting any monitor or whatever else, but it's interesting that the same code was more or less working with old AVGA 9250 (I tested liveCD 32 version 1) and same monitor. So I definitely need to test this stuff with the HD4350 plugged to a pc monitor to check if I have video with it. Unfortunately I don't have one around at this place where the cab is but will try to get one here soon.

Very odd that it isn't showing up even after X Windows starts, seems like the card is either only outputting video on one output or none of them after the DRM stuff kicks in.  Yeah I took out the network startup actually for now since it slows down startup without it connected and also forces the network interface on in the config, I need to think more of a better way to enable that for the first config.  It definitely would be good to see with a normal monitor what is going on, I am pretty sure what is happening has to do with the driver/card interaction and output video is possibly thinking the monitor isn't there, probably good otherwise if it'd only see the monitor connection.  It is interesting, the log will most likely show the issue and I'm guessing the monitor detection for the connectors is for some reason not saying anything is attached.  I'm working a newer .iso which I'll try to make sure there is  a network setup for the ethernet interface, to ssh into the box and grab /var/log/messages and /var/log/dmesg and output for the `dmesg` command. 

The next .iso I'm hopefully getting to do a few things, like have it ask you where the roms are, which you can now use one single home/data drive and it'll ask where each rom/snap directory is actually located and link it to the expected default location and do that on future boots.  Also looking into being able to install this onto the hard drive, I think it might not be that difficult so it'll be both a liveCD and installation CD too.  Need to make a menu option when unformatted drives are seen to actually partition and format them, so can really get the partitions setup from scratch.

There's something interesting too, the page flipping support for all Radeon cards is coming very soon, in 2.6.38 but is already in the GIT stuff and the Alex guy showed me the places to get that so I'll hopefully be able to build that in soon too...


  http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?h=kms-pflip&id=69639ef377a9d6701cdef902f8a1c5e0b58cf833


Is that monitor any different with the VGA connection than possibly the d9800?   It seems that what is going on, I suspect, is the DRM connector checking doesn't see it and turns it off.  We could in theory force it on, with xrandr possibly or at the linux boot prompt I can specify it to always be on too for DRM outputs.  Actually once I get a version up with ssh access enabled, you can do this from another system and send me those files...

scp -rC root@arcadesystem:/var/log/messages messages
scp -rC root@arcadesystem:/var/log/dmesg dmesg
ssh root@arcadesystem (then when in type dmesg > dmesg.log)
scp -rC root@arcadesystem:/root/dmesg.log dmesg.log

Using `arcade` as the password.

Also the person using the PAL TV seemed to not be able to use the 640x480 default we had, but it does work with the PAL DRM modeline I put in there, so something interesting, I think I have it now setup where it'll go into X Windows to setup also using that same modeline if the PAL option is chosen at the boot prompt (odd that the boot prompt shows up, not sure why that is for sure).

[Calamity]

Is that monitor any different with the VGA connection than possibly the d9800?

My cab uses a jamma connector for the monitor + control panel, so I'm using a Jpac board to interface it with the vga connection.

It seems that what is going on, I suspect, is the DRM connector checking doesn't see it and turns it off.

Yes I think so too, it seems Jpac is not being noticed by DRM and it's turning the video off. It may be this issue:

http://forum.arcadecontrols.com/index.php?topic=66402.msg982901#msg982901

If you get a black screen after windows starts up with the J-PAC, try using the OTHER port on the Radeon. You may need a DVI-to-VGA dongle.
Modern cards "sense" monitors via the RGB-to-Ground resistors (usually 75 Ohms), but the J-PAC doesn't have these.
Soft-15kHz enforces detection of BOTH VGA ports and on newer cards, the primary is "in" the DVI port.

[Calamity]

I'll try it with a pc monitor as soon as I can. Good news also those new options for roms paths, possible installation and that. I'll be patient.

[bitbytebit]

I'll try it with a pc monitor as soon as I can. Good news also those new options for roms paths, possible installation and that. I'll be patient.

We can force all connectors to on with the option on the linux command line like this 'video=640x480ec' where the 'e' part tells it to force each video output to be on even if nothing is detected.  Hopefully this works, it makes some sense actually I think to just do that and so each interface that doesn't detect EDID will basically be ready for an arcade monitor to connect at any time even if not present at bootup.  I'll test that option some, looking like I should have something rather good in a day or less, am working on having a graphical partition manager to partition/format the drives if needed and the method of taking the liveCD and writing it out to a partition to permanently install it.  The install thing is probably not going to be fully ready but the improvements other than that hopefully should make things work with the jpac and your monitor.  So I suspect it's not seeing the arcade monitor just on the one card because of possibly the either the arcade VGA card having something done to the vbios different or your using either DVI on one and VGA on the other, possibly with an adaptor?

Hopefully this rom path thing is easy to understand and works right, basically it's logic is that there's a /home/arcade/ directory and you can say /data is just a link to that.  Then it'll ask you for every path's actual location, like /data/roms might be /home/arcade/Mame/ROMS for you so you type that when it asks and it'll link the /data/roms directory to /home/arcade/Mame/ROMS.  The /data directory though if using an NTFS partition for rom locations might have an issue I can see that it'll not be able to make links into /data/ so I think I need to have another actual directory to map the NTFS partition onto like /data1 instead and then link everything from /data1/Roms to /data/roms on the fly each bootup.  So it's half way thought out and operational but I can now see the NTFS case needs some work.  I did get it though were I should be able to startup the ethernet interface on install and not have it permanently enable it unless setup by command line.  This is definitely interesting figuring out all the issues with an installation, but hopefully will be bare bones enough to be specifically for mame and other emulators plus utilized the most newest Linux kernel features and X Windows ones too.

[Calamity]

So I suspect it's not seeing the arcade monitor just on the one card because of possibly the either the arcade VGA card having something done to the vbios different or your using either DVI on one and VGA on the other, possibly with an adaptor?

My testing has been HD4350 through DVI (DVI-VGA adapter) and ArcadeVGA 9250 through VGA. It could also happen that this detecting feature is only implemented by DRM for the newer BIOS 

[bitbytebit]

So I suspect it's not seeing the arcade monitor just on the one card because of possibly the either the arcade VGA card having something done to the vbios different or your using either DVI on one and VGA on the other, possibly with an adaptor?

My testing has been HD4350 through DVI (DVI-VGA adapter) and ArcadeVGA 9250 through VGA. It could also happen that this detecting feature is only implemented by DRM for the newer BIOS 

Hopefully it's either the ArcadeVGA has something different with the vbios tricking the card into saying a monitor is always connected, or  it is a difference in chips and how the DRM layer treats them.  At least will have this next version of the .iso have the network connection, if it doesn't work still then that'll be the way to really see what is going on with it.  Also of course having another monitor connected I'm guessing will be interesting and might tell just as much. 

[bitbytebit]

In a few hours there's going to be new .iso images uploaded, named livecd32_12-06-2010_1291689634.iso and livecd64_12-06-2010_1291690462.iso, which have the 'always on' setting for the video outputs.  Also have gparted graphical partition/formatting and better setup for the /data/ drive making all the links and asking about locations of Roms.  I have a sort of experimental option in the menu, and should have all the stuff there to allow in theory installing to a partition and setup of it for a real installation.  That's not complete, there's probably some extra stuff needed, I need to work on that more  still to completely setup an installation that isn't a liveCD altered installation to a hard drive partition and get it to boot up properly.  Also this version will have the ssh access working when first started and in setup mode, so should be able to access it remotely if things are still not working right.

[bitbytebit]

Calamity:

Found an interesting thing about generating TV modelines or mainly ones with a single fixed Horizontal frequency.  This also duplicates LRMC behavior in generating the vtotal lines too...

Code: [Select]


diff --git a/src/SwitchResC/modeline.c b/src/SwitchResC/modeline.c
index 6e0a55a..485d24f 100644
--- a/src/SwitchResC/modeline.c
+++ b/src/SwitchResC/modeline.c
@@ -175,13 +175,16 @@ int ModelineCreate(ConfigSettings *cs, GameInfo *game, MonitorMode *monitor, Mod
        mode->vtotal = round(mode->hfreq / mode->vfreq);
        if (interlace == 2)
                mode->vtotal += 0.5;
-       while ((mode->vfreq * mode->vtotal) < monitor->HfreqMin) {
+       while ((mode->vfreq * mode->vtotal) < monitor->HfreqMin && (mode->vfreq * (mode->vtotal+1.0)) < monitor->HfreqMax) {
                if (monitor->cs->verbose > 1)
                        fprintf(stderr, "Increasing 1 line from horizontal freq %.3f to %.3f\n",
                                (mode->vfreq * mode->vtotal), (mode->vfreq * (mode->vtotal+1)));
-               mode->vtotal++;
+               mode->vtotal = mode->vtotal + 1.0;
        }

+       while (((mode->vfreq+0.001) * mode->vtotal) < monitor->HfreqMin)
+               mode->vfreq += 0.001;
+
        /* calculate new horizontal frequency */
        mode->hfreq = mode->vfreq * mode->vtotal;


This is switchres vs. lrmc now with this change... (before it was creating a 15.650Khz horizontal refresh for PAL modelines sometimes)

Switchres:

Code: [Select]

MonitorLimits 15624.99-15625.00,50.00-50.00,2.000,4.700,8.000,0.064,0.192,1.024,0,0,312.5,576
Setup monitor limits min=184x148 max=0x592
Decreased vertical frequency to 50.000
Starting with Horizontal freq of 15.385 and Vertical refresh of 50.00
Increased horizontal frequency from 15.385 to 15.625
Original Vref 60.606061 != 50.079995
Using 4 lines padding
# 15.625Khz -> 15.625Khz: ( | Hfreq Change | Vref Change | Vpad +4 lines | )
# pacman [3] 384x288@50.08 15.6250Khz
     "384x288x50.08" 7.874979 384 400 440 504 288 291 294 312 -HSync -VSync

# pacman 384x288@50.08 15.6250Khz
        ModeLine          "384x288x50.08" 7.874979 384 400 440 504 288 291 294 312 -HSync -VSync

LRMC:

Code: [Select]

arcade src # lrmc 384 288 50 -pal -v -v -v -v -v -n

        # 384x288x50.00 @ 15.625kHz
        Modeline "416x288x50.08"  8.000000  416 432 472 512  288 293 296 312  -HSync -VSync


What do you think, is this the right way to do this in the diff above, or is there possibly a problem with checking  we don't go above hfreqMax and then afterwards altering vfreq by .01 increments till we find the exact hfreq we need?

[Calamity]

I sometimes wondered how would it behave when introducing a very narrow hfreq interval, like the TV case, I'll have a look at it though it seems that change will be harmless. I'm curious about the TV tolerance and ranges, I was surprised of your reporting that PAL TV not accepting 640x480, this seems to be very highly dependant on each TV chassis, as I know of a friend's Sony Trinitron 29" being able to accept nearly the same continuous range as my arcade monitor.

I'm testing a new way to deal with the integer vfreq issue, now that I'm having problems with the xres increment trick. It's about storing vfreq x10, so 57.55 would be 576. I still have to test it but it seems to work. Another digit of precision was too much, raising the label to 4 figures made the system ignore those modes.

[bitbytebit]

I sometimes wondered how would it behave when introducing a very narrow hfreq interval, like the TV case, I'll have a look at it though it seems that change will be harmless. I'm curious about the TV tolerance and ranges, I was surprised of your reporting that PAL TV not accepting 640x480, this seems to be very highly dependant on each TV chassis, as I know of a friend's Sony Trinitron 29" being able to accept nearly the same continuous range as my arcade monitor.

I'm testing a new way to deal with the integer vfreq issue, now that I'm having problems with the xres increment trick. It's about storing vfreq x10, so 57.55 would be 576. I still have to test it but it seems to work. Another digit of precision was too much, raising the label to 4 figures made the system ignore those modes.

It's interesting that the 'e' addition to force all outputs on seems to have possibly caused some issue with multiple monitors connected and xrandr functionality.  I'm going to have to test it more, but need to do some sort of different approach to choosing the xrandr output when all are forced on like that.  Will be interesting to see though if that fixes your system with Jpac and the newer radeon card. 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.

I think I fixed it so should be able to have usb stick support for booting instead of a CD, and the install part is improving but still need to test it.  Unfortunately my easier way to test the general working part  of the scripts, using the qemu program (similar to VMWare) to boot it virtually, doesn't seem to allow installing greater than 1.6 Gig onto the virtual hard drive files (whole installation decompressed is about 1.7 Gig).

[Calamity]

We're getting closer! Now I have video right after the first mode switching (it was black before), I can see it detecting the network and stuff. But then when it performs the second mode switching I get out of video again. I've tested this same cd today with AVGA 9250 and at that point it was showing a blue line box prompting questions inside, really nice... but I can't reach there with my HD4350 cab yet, but definitely the issue is related with monitor not being detected.

Now... I need some help with ssh as this is new to me. I can see the files you need: dmesg.log and messages are at this moment in what seems to be the main path of the arcade system, but I don't know what to type to bring those files to my notebook!

[bitbytebit]

We're getting closer! Now I have video right after the first mode switching (it was black before), I can see it detecting the network and stuff. But then when it performs the second mode switching I get out of video again. I've tested this same cd today with AVGA 9250 and at that point it was showing a blue line box prompting questions inside, really nice... but I can't reach there with my HD4350 cab yet, but definitely the issue is related with monitor not being detected.

Now... I need some help with ssh as this is new to me. I can see the files you need: dmesg.log and messages are at this moment in what seems to be the main path of the arcade system, but I don't know what to type to bring those files to my notebook!

Interesting, so it's X Windows which is failing it seems at that point.  One thing you can do at that point is type Ctl+Atl+F2 and it'll bring you to a console on the system which sounds like it should work and will be easier to work from there possibly than remotely.  You can type `/root/startup.pl -rs` to run the menu system from there too, if wanting to try to run through the setup that way.

With the network running, which hopefully it is (can use the setup otherwise), you'll want an ssh client on another system and then get them from the arcade system by running `scp -rC root@arcadesystem:/path/to/log C:\localdir\` and that will copy them over, using arcade as the password.  I need to put an ftp client on the CD because that'll make this easier, could have just ftp'd them from the system to somewhere that way. 

At the console though hopefully you can see if the /etc/X11/xorg.conf file exists and what it exactly contains, using `less /etc/X11/xorg.conf` to page through it, make sure it has at the top the right monitor 'generic' listed and at the bottom has the modeline generated for it.  It's weird, because I thought the DRM layer would be the only part that didn't like the connectionless Jpac thing but maybe Xorg also is having an issue with it and might need a flag to force it on too.  I will have to research that, but the /var/log/Xorg.0.log file might be very important, combined in checking that /etc/X11/xorg.conf is as expected with the right modeline generated in it.  Using the 'less' command can view these files at least, you might be able to see something in them and hopefully can get scp to copy them from the server.  Look for OpenSSH, a Windows build, and you might be able to install an exe for that and use it from a dos prompt. 

This might be a good client compile of it...

http://sourceforge.net/projects/sshwindows/files/OpenSSH%20for%20Windows%20-%20Release/3.8p1-1%2020040709%20Build/

[Calamity]

Hi bitbytebit, I'll try that right now. However I'm already using OpenSSH for Windows and have an open console on arcade ~ #, I've run the scp commands you had posted some posts before and seeing the files when doing dir, it's just that I don't know what to write for destination back to my notebook, 192.168.0.101?? Anyway I'll try from the cab instead.

[Calamity]

The console is working on the cab! I've run startup.pl, gone through the menu and finally pressed 1 to get into X-Windows, interesting, it reports: /bin/bash: usr/bin/startx: Input/output error

[bitbytebit]

The console is working on the cab! I've run startup.pl, gone through the menu and finally pressed 1 to get into X-Windows, interesting, it reports: /bin/bash: usr/bin/startx: Input/output error

Try to type at the console...

killall startup.pl
killall startup.pl
killall xterm
su - arcade
startx


See what that says then, and the the log file might be interesting too and give more information, /var/log/Xorg.0.log

I think that what is happening is X is already running on console1, so you'll need to first kill off startup.pl (takes 2 times actually) then the xterm which will stop X.  Although it seems to me that most likely X will still startup the same most likely (unless perhaps the xorg.conf is better after manually configuring it). 

[bitbytebit]

Also try the other output of the card too, possibly X is showing up on the other input since with both turned on and it not knowing which is actually real, I get the feeling it might just output on one interface.

Update:

Also this might be an option...

Option "Enable"  "True"

Which would be right below the Option "DefaultModes" "False" line in /etc/X11/xorg.conf

That might force it to be on even if not seen as connected.

Past this we might then run into xrandr not knowing it's connected, definitely multiple layers to go through it seems.

[Calamity]

This is rather weird. I do the killall stuff above and still get that i/o error all the time, *even* when running less. I can explore the file system through the console and see the files you're saying, though it's distressing as I can't do anything useful like sending those files to my laptop (it's my fault, had never used this stuff), it's the trivial things like figuring out how to address network paths what's blocking me... 

But, I've seen interesting things. First it doesn't work to switch cables on the fly, you must restart the system with the cable plugged to be able to use that connection. And when I start with VGA connection, it's funny but I get no video after first mode switching but then I have it back at second and can see the blue box with the setup! But then again, it goes black when entering X Windows. But now, I go out to the console and do the killall sequence (by the way, it says it cannot find xterm process, the same happened before with DVI connection). But now when I run startx I'm getting this:

startx

[...]

Fatal server error:
Server is already active for display 0
  If this server is no longer running, remove /tmp/.X0-lock and start again

[...]

XIO Fatal IO error 11 (Resource temporaly unavailable) on X server ":0"

[bitbytebit]

This is rather weird. I do the killall stuff above and still get that i/o error all the time, *even* when running less. I can explore the file system through the console and see the files you're saying, though it's distressing as I can't do anything useful like sending those files to my laptop (it's my fault, had never used this stuff), it's the trivial things like figuring out how to address network paths what's blocking me... 

But, I've seen interesting things. First it doesn't work to switch cables on the fly, you must restart the system with the cable plugged to be able to use that connection. And when I start with VGA connection, it's funny but I get no video after first mode switching but then I have it back at second and can see the blue box with the setup! But then again, it goes black when entering X Windows. But now, I go out to the console and do the killall sequence (by the way, it says it cannot find xterm process, the same happened before with DVI connection). But now when I run startx I'm getting this:

startx

[...]

Fatal server error:
Server is already active for display 0
  If this server is no longer running, remove /tmp/.X0-lock and start again

[...]

XIO Fatal IO error 11 (Resource temporaly unavailable) on X server ":0"

What kind of processor is on the system, I'm wondering if possibly the i/o error is something to do with the processor.  It seems odd, not sure why that's not working for those commands but others, but may be something to do with being compiled with flags wrong for that processor.

It definitely needs to have things connected like they will be from boot up, otherwise it'll not know for sure what to setup for the output, the dynamic stuff seems to not work well right now for the DRM stuff.  The odd thing is that the blue box/setup screen is booted up into X so it seems that after that it fails when restarting X.  So it'll work, but I'm not sure why but it's turning off sometimes.  From what I can tell that option "Enable" for xorg.conf might help make it always be on, it's possibly meant for situations like this.

Yeah the whole switch into Linux from Windows has some odd little things that all add up to make it rather confusing, I know how that is from mostly always have used Linux but learned Windows later.  Basically for the most part in Linux you use / instead of C:\ for the root and slashes are the same in each system as the root one.  I'll have lftp in the next .iso which may help since you'll be able to just ftp files from the system.  Also that "Enable" option setup in xorg.conf too, although I am also confused why the i/o error is happening exactly.  That part is the oddest, not sure if it's some compile/processor support issue but strange that some programs are working but others aren't.

[Calamity]

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.