Looks like AMD released a legacy driver for the cards that were dropped in the 12.6 release and to add to the confusion, they also call this one 12.6. http://support.amd.com/us/kbarticles/Pages/catalyst126legacyproducts.aspx

I'm working on an XRANDR plugin for CrystalSpace to replace the XFREE86VideoMode extensions plugin. Is there anything I'd have to do to get it to work with PlaneShift?

To give you a bit more detail, I started working from inside CrystalSpace's XF86VM plugin and wrote the code in there and tested it, and it worked. I was able to get PlaneShift to run in fullscreen hassle free without any of the dreaded error messages that we would normally see with the XF86VM plugin. I then moved the code out into its own plugin, keeping the same API as the XF86VM plugin, just with a different class and plugin name. I swapped out the "xf86vm" references in CS's xwindow.cpp and xwindow.h for refrences to the XRANDR plugin. The only references to "xf86vm" I could find in PlaneShift were in a couple of the Jam files. If you'd like, I can throw the plugin files as well as the modified CS files up on a pastebin. I know this seems like more of a CS issue than PS, but as far as I can tell, the plugin is building fine, but isn't being loaded by PlaneShift, as I only get a windowed version when trying to load fullscreen and my numerous print messages aren't showing up.

Edit: the references in PlaneShift are "xext86vm" not "xf86vm"

I'd like to thank you all that tried to help, but I just never could get the fullscreen mode working as intended. Personally, I think it's because the Crystal Space code that uses XF86VideoMode extensions hasn't been touched since 2003, while most Linux distros moved from XFree86 to Xorg not long after that and the XF86 mode extensions for Xorg haven't really been maintained.

Regardless of the reasons fullscreen mode doesn't work right, I've decided to try to experiment with adding XRANDR support to the CS code rather than giving up on playing PlaneShift in fullscreen. I'm not skilled enough to consider myself a programmer, but I have already managed to get some xrandr test functions working from inside of the CS code.

There appears to be some conflicting information about when drivers will be released and what devices are going to be supported. There were rumors that AMD was going to drop support for cards older than the RadeonHD 5000, while AMD refuted that saying they were going to release quarterly updates for those devices. There was also talk that they were going to do an as-needed release schedule.

However, after looking at the AMD Catalystâ„¢ 12.6 Beta Driver ( http://support.amd.com/us/kbarticles/Pages/AMDCatalyst126beta.aspx ), it appears the initial rumors could have been correct after all, meaning if you have a card from just a couple years ago, you could be out of luck, and those of us with AGP devices (yes these are still being sold) are definitely out of luck. For Windows users this may not be that big of an issue, but for Linux users, this could be a disaster. And yes, I did actually install that driver to test it and my card (RadeonHD 3450 AGP) was not supported. I realize there's the need to drop support for older devices, but some of the devices being dropped are currently still being sold or were only sold a couple (less than 5) years ago. I don't know how many of you this will effect, but I can't see this having a positive impact on the PS community. 

I've been experimenting still and seems every time I go to respond to this I have another idea half way through and lose my train of thought. This idea here:

Yes, I first call xrandr to desired resolution, and then call psclient. Works without any issues (I put that to a script). In the end the script sets resolution back to normal.

My method:

Code: [Select]

xrandr -s 11
/opt/Games/PlaneShift/psclient
xrandr -s 0

Here 0 and 11 are indexes of the modes which are listed when you run "xrandr".

that I found earlier on was what inspired me to experiment with this in the first place. Originally, I was just going to test different settings to what settings most dramatically effected performance, and what specific settings made those corridors between map transitions dark and impossible to see. 

I need to play with this a bit:

Maybe you test the following (which I regularly use):

Code: [Select]

cd /home/franz/Planeshift/PlaneShift/
xinit ./pslaunch -- :1 &

This allows to run fullscreen in an unmodified X, and to switch between the screens by Alt-F7 and Alt-F8.
The only drawback I see is a slightly increased amount of the "disco"-bug, which I usually account for by night mushroom abuse .

Right now I have that bug where VT7 is lost in limbo (Could not write bytes: broken pipe) and my x server is running on VT8, so I guess I would use xinit ./pslaunch -- :2 & to run on VT9.

I have managed to build PS (guide needs an update for Ubuntu 12.04) without issue, but the results are the same so installed libxxf86vm1_1.1.2-1_amd64.deb from Ubuntu Quanta and I'm going to try building with libxxf86vm-dev_1.1.2-1_amd64.deb. However, I think the problem is in the CS source, and my best guess is with the xextf86vm plugin, but unfortunately I don't have the programming skills to test that idea.

Tried LXDE, XFCE, Mate 1.2, Unity, and Gnome Shell, all with the same results on Ubuntu 12.04 with the fglrx and fglrx-updates packages. I can get 800x600 working full screen, but not 640x480 (does anyone still use this??) and not 1024x768. Oh well, time to go back to Mint and try to compile from source.

About that experimentation...
I'm still not that far along, still playing with packages on my current system, but since XFree86-VidModeExtension and XF86VidModeSwitchToMode are related to the package libxxf86vm, I decided to take the risk and use the 1_1.1.2-1_amd64.deb and 1_1.1.2-1_amd64.deb packages from Debian Wheezy. Certainly not the most sane or elegant solution but it worked. Well, back to experimenting to see what else works or doesn't.

Edit: So far I can only get 800x600 working. Still experimenting though.