Ubuntu 12.10 - Dual monitors, move Gnome Shell (also, broken virtual termin

[Rablet]

I've been trying Ubuntu again for roughly a week, I like it so far but have run into a couple of issues, hopefully someone here can help me resolve some of them!

My graphics card is Radeon HD 5850 and I'm using the 13.1 Catalyst drivers, other than that my specs are: ASRock Extreme4, Intel Core i5-3570k.

1) I'm using Gnome Shell (had a weird flicker issue with Unity, I tried the workaround in https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1070275 to no avail) but I'd like to move Gnome Shell to my secondary monitor - while keeping the current primary monitor as the primary so full screen programs still start on it. How can I do this? I have tried https://extensions.gnome.org/extension/323/multiple-monitor-panels/ and it's almost what I want - I'd just like the Top menu & HUD moved from my primary to my secondary monitor and not cloned.

2) Plymouth isn't working, it's not showing at boot - I get to the GRUB menu, but after that I just see a blank purple screen - and at shut down I simply get a yellow screen. I have tried http://debianandi.blogspot.se/2012/11/how-to-fix-plymouth-on-ubuntu-1210-with.html but it made no difference for me

3) My virtual terminals (TTY1-6) are broken, switching to them just gives a blank screen, commands still work as they should however (echo "why is this broken" > sillyTTY makes the file for example). I have tried several different fixes for this, for example http://askubuntu.com/questions/162535/why-does-switching-to-the-tty-give-me-a-blank-screen but the only difference that made was giving me a blinking cursor instead of a blank screen.

Any ideas?

[medhunter]

Weird, I have no problem like this, it might be driver related (though, we share the AMD GPU brand),I am not a pro.

[Karl L.]

The first and third problems, at least, are most likely a result of the proprietary AMD graphics drivers. I would highly recommend purging them and using the open-source radeon driver instead. Your video card is very well supported by radeon, and you will almost certainly have fewer problems with it.

Edit: I recommend that you read through this thread. It has lots of interesting details that you may find helpful.

[Rablet]

Thanks for the replies!

Weird, I have no problem like this, it might be driver related (though, we share the AMD GPU brand),I am not a pro.

What driver are you using? I am/was using the 13.1 driver from AMD's website.

The first and third problems, at least, are most likely a result of the proprietary AMD graphics drivers. I would highly recommend purging them and using the open-source radeon driver instead. Your video card is very well supported by radeon, and you will almost certainly have fewer problems with it.

Edit: I recommend that you read through this thread. It has lots of interesting details that you may find helpful.

I removed fglrx and it did indeed fix the flicker & virtual terminal issues, it seems to have fixed my issue with resuming from suspend as well.

The only downside with what I'm using now is the performance in games is bad. My output from glxinfo | grep renderer is OpenGL renderer string: Gallium 0.4 on AMD CYPRESS, is that correct?

I chucked together two scripts, one to install fglrx (when I game) and one to swap back to radeon (when I'm not), I'm guessing I'd need a reboot in-between but that's not really an issue. Would this be a sensible solution or would it cause issues in the long run?

[Karl L.]

I removed fglrx and it did indeed fix the flicker & virtual terminal issues, it seems to have fixed my issue with resuming from suspend as well.

The only downside with what I'm using now is the performance in games is bad. My output from glxinfo | grep renderer is OpenGL renderer string: Gallium 0.4 on AMD CYPRESS, is that correct?

Gallium 0.4 is the 3D rendering component of the Radeon driver. CYPRESS is the code-name of your GPU architecture. That is the correct OpenGL renderer string.

I chucked together two scripts, one to install fglrx (when I game) and one to swap back to radeon (when I'm not), I'm guessing I'd need a reboot in-between but that's not really an issue. Would this be a sensible solution or would it cause issues in the long run?

That is an absolutely terrible idea! I strongly recommend that you don't swap drivers on a regular basis. If you really feel like you MUST swap drivers when you game, the least-bad idea is probably to install fglrx from the repository, generate a xorg.conf to force X11 to use radeon when you start your computer, then create a script to stop X11, load X11 with fglrx (and maybe a low-resource, non-compositing window manager, such as Openbox, to get higher framerates) so that you can game. Your script should probably be capable of switching back as well.

[Rablet]

That is an absolutely terrible idea! I strongly recommend that you don't swap drivers on a regular basis. If you really feel like you MUST swap drivers when you game, the least-bad idea is probably to install fglrx from the repository, generate a xorg.conf to force X11 to use radeon when you start your computer, then create a script to stop X11, load X11 with fglrx (and maybe a low-resource, non-compositing window manager, such as Openbox, to get higher framerates) so that you can game. Your script should probably be capable of switching back as well.

Would that not be problematic due to the issue mentioned here? https://wiki.ubuntu....er#How_It_Works

Another potential option would be using the integrated Intel graphics in the CPU for non-gaming and then activate fglrx when gaming, but how would I go about doing that if it's possible?

Would it be as simple as installing fglrx, making two different xorg.conf files and essentially just swap the driver name in one of them to 'intel', and then when I want to change which driver to use I simply change the names of the xorg.conf-files and restart lightdm?

[Karl L.]

I forgot that the proprietary NVIDIA and AMD graphics drivers install hacked-together versions of the OpenGL libraries to replace the version used by open-source drivers. You're right: my suggestion above probably wouldn't work for that reason.

It might be possible to move each version of the conflicting libraries to a different location and create a script to soft-link only the version you need at the moment. Debian's alternatives infrastructure (man update-alternatives) may be able to handle the same thing with a little more automation (and the blessing of dpkg). In short, it will be a nasty hack at best and I still strongly recommend against it.

[Rablet]

Adding nomodeset to GRUB_CMDLINE_LINUX_DEFAULT seems to have fixed the problem with virtual consoles and Plymouth, and doing the workaround for the Unity flicker in my first post may have worked with nomodeset, fingers crossed!