Bug 37362

Summary: vgaswitcheroo : switch from intel to ati impossible
Product: Drivers Reporter: pub
Component: Video(DRI - non Intel)Assignee: drivers_video-dri
Status: RESOLVED WILL_FIX_LATER    
Severity: normal CC: alan, alexdeucher, dalingrin, persson
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.38 and 2.6.39 Subsystem:
Regression: No Bisected commit-id:
Attachments: lspci -vv
dmesg

Description pub 2011-06-12 22:45:59 UTC
Created attachment 61732 [details]
lspci -vv

When i use the command "echo DIS > /sys/kernel/debug/vgaswitcheroo/switch", the screen of my laptop (HP Pavilion dv7) freeze. Impossible to switch to another tty and if i write a command in the console nothing appears.

If i write "echo IGD > /sys/kernel/debug/vgaswitcheroo/swith", the screen refreshes and i can use normally my laptop.

I can't disable the intel card in the bios.

the result of the command "cat /sys/kernel/debug/vgaswitcheroo/swith" :
0:DIS: :Pwr:0000:01:00.0
1:IGD:+:Pwr:0000:00:02.0

The log (/var/log/messages) when i want switch to ATI :
Jun 12 22:11:17 ackak-hp kernel: [  133.005729] fbcon: Remapping primary device, fb0, to tty 1-63
Jun 12 22:11:17 ackak-hp kernel: [  133.005976] i915: switched off
Comment 1 pub 2011-06-12 22:47:13 UTC
Created attachment 61752 [details]
dmesg
Comment 2 Alex Deucher 2011-06-13 14:13:46 UTC
Is there an option in your bios setup to select the discrete graphics? Try selecting that. vgaswitcheroo only supports hybrid GPUs with display MUXes. Some new laptops are MUX-less (which yours appears to be) which means the display hardware is only attached to the integrated GPU and the other one is strictly used for rendering. Unfortunately, the X server needs a lot of work to support that scenario so it work be supported any time soon in the open source drivers.
Comment 3 pub 2011-06-13 16:31:20 UTC
Thanks for your response.

I don't have an option in the bios to select the graphic card.

How can I check if the GPU is MUXes or MUX-less ?

I make the test, without running the X server.

Should I do more tests or wait ?
Comment 4 Alex Deucher 2011-06-13 16:37:27 UTC
(In reply to comment #3)
> How can I check if the GPU is MUXes or MUX-less ?

Double check with your OEM, but being that your radeon card has no displays listed in its configuration, I'm pretty sure it's MUX-less.

> Should I do more tests or wait ?

There's not much else you can do until the X server gets support for split display and rendering.
Comment 5 pub 2011-06-13 16:55:17 UTC
I have format the disk, so I don't have OEM :)

> There's not much else you can do until the X server gets support for split
> display and rendering.

Ok, thanks.
Comment 6 Alex Deucher 2011-06-13 21:08:49 UTC
This bug can probably be closed.  This isn't really a kernel bug.  The X server needs a major amount of work before MUX-less systems can be supported.
Comment 7 pub 2011-06-13 21:34:29 UTC
I don't understand. When I make the test, the X server isn't running. I write the command directly in the tty with the framebuffer.

The server X can't use this graphic card, ok, but i have a problem directly in console. So i don't why it isn't a problem with the kernel.

(sorry for my english)
Comment 8 Alex Deucher 2011-06-13 21:49:40 UTC
(In reply to comment #7)
> I don't understand. When I make the test, the X server isn't running. I write
> the command directly in the tty with the framebuffer.
> 
> The server X can't use this graphic card, ok, but i have a problem directly
> in
> console. So i don't why it isn't a problem with the kernel.

On a MUX-less systems, the displays are not connected to the discrete card at all.  There is no way to switch the displays to the discrete card thus, there is no way to use the discrete card for the console.  The only way to utilize the discrete card is for offscreen rendering via X or some other GUI an in order to do that, the X server needs a major amount of work.
Comment 9 Erik Hardesty 2011-07-16 06:31:08 UTC
FWIW, I also have a DV7, specifically, I have a DV7t-6000. This model supposedly uses a MUX. Despite having a MUX I have the exact same symptoms as this bug report. This is true for kernels 2.6.38 - 3.0rc7