Interesting Arch startx Issue (again)

[Xires]

Too bad he is wrong, if you have hybrid graphics it won't work.
(Not that I dont appreciate it)

Whom and about what?  If I am incorrect, which I believe you meant to imply, I'd certainly like to know where and for what reason.  If I can correct myself for the future, I'd like to do so.

[proxx]

Whom and about what?  If I am incorrect, which I believe you meant to imply, I'd certainly like to know where and for what reason.  If I can correct myself for the future, I'd like to do so.

Code: [Select]

00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)

Due to this it is very likely that he has an 'optimus'/hybrid graphics box.
https://en.wikipedia.org/wiki/AMD_Hybrid_Graphics
https://wiki.archlinux.org/index.php/hybrid_graphics

ATI Dynamic Switchable Graphics

This is a new technology similar to the one of Nvidia as it uses no hardware multiplexer.
Current Problems

The Dynamic Switch needs Xorg support for the discrete videocard assigned for rendering to work [1]. So, rendering on the discrete gpu will not work until the Xorg team adds support for it.

This means that with a muxless intel+ati design, you cannot use your discrete card by simply modprobing the radeon module.

As of now, there are 3 choices:

- Disable the discrete card and use only the intel igpu. This is not needed for kernels version >= 3.12 with radeon DPM enabled; the open source graphics driver manages the card automatically. For kernels older than 3.12, see the solution below.

- Test and improve some virtualGL based program to make the switch, like the common-amd branch of bumblebee project. Check the project repository and this useful post.

- Use the proprietary driver with powerxpress (a.k.a. pxp) support maintained by Vi0l0 (remember to check for xorg compatibility).
Solution for kernels < 3.12 or without radeon dynamic power management enabled
Warning: This method, on a mux-less system, works only to shutdown the radeon card. This will not enable rendering on the radeon gpu. See Current Problems section above for detail.

This solution is not needed on kernel version >= 3.12 because the opensource driver automatically manages the power of the radeon gpu, so there is no need to manage the cards from userspace.

This means that on kernels >= 3.12, vgaswitcheroo is not needed anymore to turn off the discrete gpu, only if you wish to verify the power state.

If you have kernel >= 3.12 with vgaswitcheroo enabled, you can verify if the driver automatically shut down the discrete gpu

# cat /sys/kernel/debug/vgaswitcheroo/switch

The output should be similar to this, where DIS is the radeon discrete gpu and IGD the intel gpu. DynOff means the radeon driver automatically powered off the discrete gpu.

0:DIS: :DynOff:0000:01:00.0
1:IGD:+:Pwr:0000:00:02.0

If you are using kernels older than 3.12 then you can use vga_switcheroo with a combination of opensource drivers to disable the radeon card from userspace at boot.

To do this, follow the instructions below.

    Preliminaries

Make sure you have installed the drivers. Run in terminal:

$ pacman -Q | grep -E "xf86-video-ati|xf86-video-intel"

In case you get output similar to this:

xf86-video-ati 6.14.1-1
xf86-video-intel 2.15.0-2

you are good to go. In other case install drivers:

# pacman -S xf86-video-ati xf86-video-intel

In order to be able to access vgaswitcheroo add this line to your fstab:

none            /sys/kernel/debug debugfs defaults 0 0

Note: KMS must be activated for both cards, otherwise there will be no vgaswitcheroo in /sys/kernel/debug/

    Automatic radeon shutdown

Systemd can use tmpfiles to shutdown the discrete gpu at boot.

Important: Make sure the video drivers are loaded in initramfs before systemd calls vga_switcheroo, otherwise a kernel oops/panic may occur.

First add the drivers to MODULES array in /etc/mkinitcpio.conf. Adding radeon and i915 yields

/etc/mkinitcpio.conf

MODULES="radeon i915"

Next rebuild initramfs (details at initramfs)

# mkinitcpio -p linux

Then create the systemd tmpfile at /etc/tmpfiles.d/vgaswitcheroo.conf

/etc/tmpfiles.d/vgaswitcheroo.conf

w /sys/kernel/debug/vgaswitcheroo/switch - - - - OFF

Reboot and the discrete gpu should be off by default. It can be powered back on using the manual method described below.

    Manual method

To verify the state of the dgpu

# cat /sys/kernel/debug/vgaswitcheroo/switch

Power off the dgpu

# echo OFF > /sys/kernel/debug/vgaswitcheroo/switch

Power on

# echo ON > /sys/kernel/debug/vgaswitcheroo/switch

At lot of things changed so I have to admit that I don't know the current status of this whole shit.

[Xires]

At least this tells me pretty definitively that this is not an AMD APU system.  That's fantastic because those suck for getting proper video support running.  However, being that this is a laptop, it is possible that the laptop screen's interface is connected directly to an Intel graphics array and the Radeon card is primarily connected to an external HDMI/DVI/DP/VGA port.  This can lead to some confusion as it is an architecture design that is heavily dependent upon proprietary Windows drivers meant to use the rendering & feature support of both cards in tandem.

That was with specific regard to the lspci output.  The system is not an AMD APU system but it does indeed have dual display, as noted.  That is why I mentioned the interface connection specifics.  This means it may still be possible to do a multihead configuration.  I'm sure the OP will appreciate you providing the wiki links & other information.  At current, the architecture is still only properly supported by binary Windows driver releases and details are insufficient to permit proper support for other platforms without reverse engineering of those drivers.  This, sadly, means that the architecture support is heavily dependent upon Windows drivers.  As there currently exists no 'ndiswrapper' type option for graphics use, this makes support and configuration quite difficult.

I don't think I was 'wrong', precisely, but I definitely didn't provide enough clear information and so I thank you for pointing it out.

[proxx]

That was with specific regard to the lspci output.  The system is not an AMD APU system but it does indeed have dual display, as noted.  That is why I mentioned the interface connection specifics.  This means it may still be possible to do a multihead configuration.  I'm sure the OP will appreciate you providing the wiki links & other information.  At current, the architecture is still only properly supported by binary Windows driver releases and details are insufficient to permit proper support for other platforms without reverse engineering of those drivers.  This, sadly, means that the architecture support is heavily dependent upon Windows drivers.  As there currently exists no 'ndiswrapper' type option for graphics use, this makes support and configuration quite difficult.

I don't think I was 'wrong', precisely, but I definitely didn't provide enough clear information and so I thank you for pointing it out.

Wrong is a bit over the edge