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
Created attachment 61752 [details] dmesg
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.
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 ?
(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.
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.
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.
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)
(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.
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