Hybrid graphics - "radeon" driver unloaded, "modesetting" loaded?

[Lennert Van Alboom]

On Fri, Feb 05, 2016 at 11:24:12AM +0900, Michel Dänzer wrote:
> On 04.02.2016 19:05, Lennert Van Alboom wrote:
> > Hello. I've got a HP Elitebook 850g1 with hybrid graphics:
> > 
> > 	$ lspci | grep VGA
> > 	00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b)
> > 	03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Mars [Radeon HD 8730M] (rev ff)
> > 
> >     $ sudo cat /sys/kernel/debug/vgaswitcheroo/switch 
> >     0:IGD:+:Pwr:0000:00:02.0
> >     1:DIS-Audio: :Off:0000:03:00.1
> >     2:DIS: :DynOff:0000:03:00.0
> > 
> > I'm running Debian (sid, x86_64) with kernel 4.4.0-trunk-amd64 (same happens with the 4.3.0-1-amd64 kernel) and Xorg 1:7.7+13 (1.18.0).
> > I'm having an odd issue where Xorg loads the correct "radeon" driver, but after a split second, unloads it again and loads "modesetting":
> > 
> > 	[    13.688] (II) config/udev: removing GPU device /sys/devices/pci0000:00/0000:00:1c.4/0000:03:00.0/drm/card1 /dev/dri/card1
> > 	[    13.688] xf86: remove device 1 /sys/devices/pci0000:00/0000:00:1c.4/0000:03:00.0/drm/card1
> > 	[    13.693] (II) UnloadModule: "radeon"
> > 	[    13.693] (II) UnloadSubModule: "fb"
> > 	[    13.693] (II) Unloading fb
> > 	[    13.693] (II) UnloadSubModule: "glamoregl"
> > 	[    13.693] (II) Unloading glamoregl
> > 	[    13.693] (II) config/udev: Adding drm device (/dev/dri/card1)
> > 	[    13.693] (II) xfree86: Adding drm device (/dev/dri/card1)
> > 	[    13.693] (II) LoadModule: "modesetting"
> > 	[    13.693] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
> > 
> > Full Xorg log at http://ziff.soleus.nu/Xorg.0.log.txt. I don't have a xorg.conf, and no snippets in xorg.conf.d either.
> > 
> > This results in two providers in xrandr, Intel and modesetting (as opposed to radeon, as I had before):
> > 
> > 	$ xrandr --listproviders
> > 	Providers: number : 2
> > 	Provider 0: id: 0x7d cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 6 associated providers: 0 name:Intel
> > 	Provider 1: id: 0x140 cap: 0x3, Source Output, Sink Output crtcs: 2 outputs: 2 associated providers: 0 name:modesetting
> > 
> > I can't set an offload sink:
> > 
> > 	$ xrandr --setprovideroffloadsink modesetting Intel
> > 	X Error of failed request:  BadValue (integer parameter out of range for operation)
> > 	Major opcode of failed request:  140 (RANDR)
> > 	Minor opcode of failed request:  34 (RRSetProviderOffloadSink)
> > 	Value in failed request:  0x140
> > 	Serial number of failed request:  16
> > 	Current serial number in output stream:  17
> > 
> > And, I suppose this is normal because of the above, DRI_PRIME doesn't do much:
> > 
> > 	$ glxinfo | grep "OpenGL renderer"
> > 	OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile 
> > 	$ DRI_PRIME=1 glxinfo | grep "OpenGL renderer"
> > 	OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile 
> > 
> > Strangely enough, the /sys device link for "card1", as mentioned in the Xorg log, still points to the "correct" ATI device:
> > 
> > 	$ ls -l /sys/class/drm/card1/device
> > 	lrwxrwxrwx 1 root root 0 Feb  3 21:14 /sys/class/drm/card1/device -> ../../../0000:03:00.0
> > 
> > 
> > I'm a bit stumped here. How can I get my radeon device back in the xrandr providers and working via DRI_PRIME?
> 
> I can see two problems here: Xorg unloads the radeon driver and loads
> the modesetting driver instead, and the modesetting driver doesn't
> advertise PRIME render offloading capability. I don't think either is a
> radeon driver issue though, so the xorg-devel list seems more
> appropriate. Moving there.
> 
> 
> -- 
> Earthling Michel Dänzer               |               http://www.amd.com
> Libre software enthusiast             |             Mesa and X developer


Okay. The second problem isn't much of a problem (for me, personally) if the
first gets resolved, so I suppose it makes sense to look at that first. 

Why would Xorg unload a valid driver for a card and load another instead? And,
more to the point, is there a way of preventing it from happening? 



Lennert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.x.org/archives/xorg-devel/attachments/20160210/52026be8/attachment.sig>