Bug 36256 - Return to tty after leaving X problematic if using multiple cards since 2.6.32
Summary: Return to tty after leaving X problematic if using multiple cards since 2.6.32
Status: RESOLVED WORKSFORME
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-15 00:33 UTC by Connor Behan
Modified: 2011-05-01 08:46 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Dmesg output (46.14 KB, application/octet-stream)
2011-04-15 00:33 UTC, Connor Behan
no flags Details

Description Connor Behan 2011-04-15 00:33:17 UTC
Created attachment 45653 [details]
Dmesg output

This bug affects me on every kernel from 2.6.38 to 2.6.32 inclusive. It is NOT present in 2.6.31. I have two video cards, my primary card is an r128 and my secondary card is a radeon. I have X setup to *only use the radeon*. Everything works perfectly before I startx, but once I start X and then leave it, every console on the primary r128 driven monitor is unusable. It does not seem to matter how I leave X. Logging out via xfce, "sudo killall X", Ctrl+Alt+Bksp, Ctrl+Alt+F1, all of these prevent me from using VTs on the primary monitor. When I say that these VTs are unusable, I mean that no text on them is ever shown to update. I can still technically use them by silently typing commands but I cannot see myself type.

Now there are four different scenarios I've tried and they suggest that this bug is not caused by KMS:

1. No framebuffer on primary r128, modeset=0 on secondary radeon:

The consoles stay on the primary monitor and once I start X and kill X, all these consoles are unusable.

2. No framebuffer on primary r128, modeset=1 on secondary radeon making it /dev/fb0:

As soon as the radeon module gets loaded, the framebuffer on my secondary video card steals all the consoles so that they show up on the secondary monitor. Starting X and killing X is then OK for me because the focus returns to consoles that are on the same video card. Even though this "works" it means my r128 card that I like to use for consoles is just idling this is obviously not the optimal solution.

3. Uvesafb on primary r128 making it /dev/fb0, modeset=0 on secondary radeon:

The framebuffer consoles appear on the primary monitor and once I start X and kill X, all these consoles are unusable.

4. Uvesafb on primary r128 making it /dev/fb0, modeset=1 on secondary radeon making it /dev/fb1:

I can now freely move ttys between the two framebuffers using the "con2fb" tool. If I start X and then kill X, I can switch between these consoles with Alt+Fn and all the ones on /dev/fb1 work while all the ones on /dev/fb0 fail to update.

I hope I'm explaining this well. Attached is my dmesg. Tell me if you need anything else.
Comment 1 Connor Behan 2011-04-16 06:42:01 UTC
I can make the consoles work if I delete /dev/vga_arbiter before starting X. This explains why 2.6.32 was the first kernel where I had this problem. Can you go back to making vga_arb a module so people can solve this properly?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.