11:54 xplodwild: hey there, I have a new laptop with an Intel CPU + RTX2060 on which I installed Ubuntu. For some reasons, I can't get the HDMI output to work under Xorg. Using Wayland, everything works fine (but performance isn't great), and on the GDM login screen, both screens work. However once my session is open, the integrated panel works and the external scr
11:54 xplodwild: een is detected and proper resolution set, however it is just plain black. I can move my cursor to the screen and see it fine though.
11:54 xplodwild: oddly, if I add a Section "Device" => driver "intel", in my xorg.conf, external monitor works fine BUT the integrated display is now black. Xorg.0.log shows the eDP-1, but no config seems to make it work
11:55 xplodwild: using nouveau/i915, both with modeset on
11:56 xplodwild: also, using either USB-C or the direct HDMI port both lead to the same result. I wonder if the video output on USB-C port on newer laptops is now driven by the dGPU instead of the IGP
12:04 diogenes_: "Device" => driver "intel", in my xorg.conf when using wayland won't produce anything afaik.
12:04 xplodwild: yeah, wayland uses its own config stuff, that part was for Xorg
12:05 diogenes_: so the problem is with both xorg and wayland?
12:05 xplodwild: nope, basically, on the login screen (what does this use?) and using Wayland, both screens (even triple screen) work (integrated panel, HDMI and HDMI through USB-C)
12:06 xplodwild: but when using Xorg, all 3 displays are recognized and initialized, however they are all plain black or flickering the login background color
12:06 xplodwild: I can move my mouse cursor over to each screen fine, so they're at the proper resolution, and in the proper layout
12:06 xplodwild: it's just that somehow, Xorg can't "paint" on the external displays
12:07 diogenes_: oh i see.
12:07 xplodwild: but, using Xorg, if I set a section device with intel driver, both external displays work fine (ie. Xorg "paints" properly on them), but the integrated panel remains now black
12:07 diogenes_: but wait, if you are using optimus (intel+nouveau) then they don't even use nouveau but i915 isn't it?
12:08 xplodwild: well it's all KMS if I understood that correctly
12:08 xplodwild: so it doesn't even care much intel/i915 or nouveau, as it's all modesetting from an xorg point of view
12:08 diogenes_: nouveau only gets activated when running DRI_PRIME=1 <application name>
12:09 diogenes_: try this: glxinfo | grep "OpenGL renderer"
12:09 diogenes_: then: DRI_PRIME=1 glxinfo | grep "OpenGL renderer"
12:09 xplodwild: Without => Mesa DRI Intel(R) UHD Graphics 630 (Coffeelake 3x8 GT2)
12:10 xplodwild: with => failed to load driver: nouveau
12:10 xplodwild: and it gives again Intel UHD graphics
12:10 diogenes_: oh you see, nouveau driver is not initialized and probably because you said you used nomodeset
12:10 diogenes_: cat /etc/default/grub
12:10 diogenes_: pastebin
12:10 xplodwild: the opposite actually, I'm using modeset
12:11 diogenes_: let's see your grub CMDLINE
12:11 xplodwild: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.modeset=1 button.lid_init_state=open"
12:11 xplodwild: I also have GRUB_GFXMODE="1920x1080-32" set but I don't think that matters
12:12 xplodwild: the remaining of the file is stock ubuntu
12:12 diogenes_: try with only "quiet splash" without extra stuff
12:12 diogenes_: it's weird why nouveau isn't initialized.
12:13 xplodwild: the lid_init_state is a quirk to avoid a resume/sleep loop, shouldn't impact much to leave it there
12:14 xplodwild: removed the option, did an update-grub, and rebooted, same result
12:15 diogenes_: DRI_PRIME=1 glxinfo | grep "OpenGL renderer"
12:16 xplodwild: same as previously, libGL error: failed to create dri screen / libGL error: failed to load driver: nouveau
12:17 diogenes_: what distro?
12:17 xplodwild: Ubuntu 19.04
12:17 diogenes_: apt list --installed | grep nouveau
12:17 xplodwild: with kernel 5.2.5 (I also tried with 5.3-rc3 just out of curiosity)
12:18 xplodwild: libdrm-nouveau2/disco,now 2.4.97-1ubuntu1 amd64 [installé, automatique] nouveau-firmware/disco,disco,now 20091212-0ubuntu1 all [installé] xserver-xorg-video-nouveau/disco,now 1:1.0.16-1 amd64 [installé]
12:19 diogenes_: all the packages seems to be in place and i have no clue why it's not being initialized but i assume this is the issue that it doesn't get loaded.
12:19 xplodwild: is there some kind of verbose mode I could turn on?
12:20 diogenes_: stick around until some one notices your question and is able to come up with any ideas.
12:20 xplodwild: also, I get this in Xorg log: [ 296.186] (II) [drm] nouveau interface version: 1.3.1 [ 296.186] (EE) Unknown chipset: NV166
12:20 xplodwild: though from source code it didn't look like it was blocking
12:21 diogenes_: let's see your: lspci -nnk | grep VGA -A3
12:21 xplodwild: https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/tree/src/nv_driver.c?id=2376d1ebf2d9a96bc2ebf21d53a9f9841ce5c15b#n402
12:21 xplodwild: or is it actually
12:22 xplodwild: lspci => https://pastebin.com/ga36jMGm
12:23 xplodwild: actually that "Unknown chipset" could be the issue
12:23 xplodwild: since it leads the driver to think it's NOT in KMS mode by default
12:23 diogenes_: hmm yes and your lspci shows: Kernel driver in use: nouveau
12:23 diogenes_: i'm puzzled
12:23 diogenes_: maybe just install nvidia binary?
12:24 xplodwild: nvidia binary has poor energy management with optimus
12:24 xplodwild: nouveau handles dynamic power mgmt so well
12:24 diogenes_: i know, i like nouveau better and i use it myself, also in optimus scenario and it works great.
12:25 xplodwild: I'll try to rebuild xf86-video-nouveau with my NV166 chipset in the KMS check function
12:25 xplodwild: I have the same machine with a GTX1060 and it works just fine, so it can't be that much more
12:25 kherbst: ohh
12:25 kherbst: nv166?
12:25 xplodwild: though I'm suprised nobody had that issue since january
12:25 xplodwild: yup kherbst
12:25 kherbst: and it's a 1060?
12:25 xplodwild: 2060
12:25 kherbst: ahh
12:26 kherbst: yeah, we don't support that in mesa
12:26 kherbst: not yet at least
12:26 xplodwild: I have both Razer Blade 2018 and 2019
12:26 xplodwild: they're similar except 2018 has 8xxx Intel and 1060, 2019 has 9xxx Intel and 2060
12:26 kherbst: so the unknown chipset error is expected
12:27 kherbst: mhh
12:27 xplodwild: would upgrading and rebuilding xf86-video-nouveau help?
12:27 kherbst: I don't think so.. let me check
12:27 xplodwild: or are there similar checks at other places? though I haven't seen that error anywhere else
12:27 xplodwild: funnily enough, my 1060-machine does NOT have xserver-xorg-video-nouveau installed
12:27 xplodwild: yet DRI_PRIME=1 glxinfo returns the expected result
12:28 kherbst: yeah.. you can also use the modesetting ddx
12:28 xplodwild: (ie. OpenGL renderer string: NV136)
12:28 kherbst: which I think would be the best choice in your case anyway
12:28 kherbst: one could probably check if the nouveau ddx is working with turing cards though
12:28 kherbst: but.. nobody did so far
12:29 kherbst: xplodwild: anyway, with the modesetting driver you might just get the displays working
12:29 kherbst: turing is still ina weird state as we have no acceleration firmware from nvidia
12:29 kherbst: so we can't do anything anyway
12:29 xplodwild: I don't care much about 3D acceleration tbh
12:29 kherbst: acceleration in general
12:29 xplodwild: 2D/3D
12:29 kherbst: even 2d
12:29 kherbst: well.. then you can use the modesetting driver
12:29 xplodwild: as long as I can get my external displays to work, I'm good
12:29 kherbst: that should more or less work
12:29 xplodwild: well, in theory I'm already in modesetting
12:30 xplodwild: xrandr providers: Provider 0: id: 0x102 cap: 0x9, Source Output, Sink Offload crtcs: 3 outputs: 1 associated providers: 1 name:modesetting / Provider 1: id: 0x47 cap: 0x2, Sink Output crtcs: 4 outputs: 4 associated providers: 1 name:modesetting
12:30 xplodwild: that's why I can't wrap my head around why this is happening
12:31 xplodwild: as, if you haven't seen previous messages, external displays work perfectly using Wayland
12:31 xplodwild: but wayland performance is not super great, even for desktop usage
12:31 xplodwild: also in grub/plymouth/gdm login screen, all displays work fine
12:31 xplodwild: but as soon as I log in, external displays turn black, with only the mouse working
12:33 xplodwild: and if I put a simple `Section "Device" Driver "intel" EndSection` in my Xorg.conf
12:33 xplodwild: the integrated panel turns black/off (no backlight), but the external displays now work
12:34 xplodwild: BUT logs shows ` 1123.297] (II) intel(G0): Output eDP1 has no monitor section` so it is there somewhere
12:34 xplodwild: let me try adding a monitor section for eDP1
12:39 xplodwild: hmm so Output eDP1 using monitor section eDP1, but xrandr still doesn't show it
13:15 xplodwild: meh can't get this thing to work with X
13:15 xplodwild: I guess I'll stick with wayland for now
13:15 xplodwild: I'm guessing it's a bug in the modesetting module for Xorg
13:16 xplodwild: actually specifying the Intel driver section makes X fallback to LLVMpipe instead of the actual driver
13:28 xplodwild: hmm, Xwayland works with the Intel OpenGL rendere just fine
13:29 xplodwild: inxi -SCG returns resolution: 1920x1080~144Hz, 1920x1080~60Hz with Xwayland whereas only resolution: 1920x1080~144Hz with regular Xorg
13:29 xplodwild: though under Xorg both screens are configured with xrandr and active/connected
13:30 xplodwild: I wonder what it's actually checking to get those resolutions
13:36 xplodwild: nvm, it's just because i was running an odd test resolution, it otherwise list them fine as well
13:37 xplodwild: I'll open a bug on the bugtracker
19:58 frobos: so, I looked into the released docs but couldn't figure out their utility
19:58 frobos: will they help?
20:00 gnarface: maybe try the man pages?
20:12 airlied: frobos: dont think they contain much ghat hasnt been reverse engineerdd alreasy
20:12 kherbst: frobos: those docs are quite old already
20:12 kherbst: airlied: they help with some display related stuff
20:12 kherbst: and pure basics
20:12 kherbst: they also document tons of compute related things though
20:12 kherbst: there are some pieces which are helpful for corner cases
20:13 kherbst: but nothing which would help us to speed things up fundamentally
22:03 frobos: I see... I hoped that they would help in solving some bugs. I still have a Kepler card that freezes with nouveau after some usage
22:04 frobos: pre and post reclocking
22:04 kherbst: mhh, yeah..
22:04 kherbst: we have some weirdo bug inside the context switching firmware
22:04 kherbst: and nobody was able to figure out what exactly goes wrong
22:06 frobos: huh, it is narrowed down to context switching then?
22:11 kherbst: maybe? depends on your issue
22:11 kherbst: but we know there is some weirdo one
22:16 frobos: I would have to debug the kernel driver or mesa, right
22:43 frobos: to atleast generate a backtrace
23:06 gnarface: frobos: (kernel driver, i think)