[opensuse-factory] nouveau xorg.conf.d
Hi *, I'm still trying to switch somehow automatically between the nvidia and the nouveau driver, but I ran into a quite annoying problem on both openSuSE Leap 42.2 (even with the latest kernel from the kernel stable repository) and also with the latest Tumbleweed snapshot. I don't have problems, running the nouveau driver if I don't have an xorg.conf.d structure at all, but even with a very tiny structure the X server won't start anymore, and I can't figure out, what I might be missing here. There are three scenarios: 1. No xorg.conf.d structure at all -> nouveau gets loaded, X is starting. Same behaviour with Leap 42.2 ad with Tumbleweed. 2. Tiny xorg.conf.d structure as shown below with a driver entry for nouveau, i.e. Driver "nouveau" -> X server is not starting with an entry "Unknown chipset: NV117" at the end of Xorg.0.log. Same behaviour with Leap 42.2 ad with Tumbleweed. 3. Tiny xorg.conf.d structure as shown below without a driver entry for nouveau -> X server is starting and one can logon via sddm, but a few program starts later, the nouveau driver is crashing with errors like "nouveau 0000:01:00.0: fifo: PBDMA0: 00040000 [PBENTRY] ch 15 [007e351000 X[1413]] subc 0 mthd 0000 data 00000000". This happens with Leap 42.2 only, not with Tumbleweed - with the exact same modules from kernel 4.8.9-1. This is my xorg.conf.d structure: # 00-keyboard.conf: # ................. Section "InputClass" Identifier "system-keyboard" MatchIsKeyboard "on" Option "XkbLayout" "de" Option "XkbModel" "pc105" Option "XkbOptions" "terminate:ctrl_alt_bksp" EndSection # ----------------------------- # 50-device.conf: # ............... Section "Device" Identifier "NVidia_GTX750" Driver "nouveau" EndSection # ----------------------------- # 50-module.conf: # ............... Section "Module" # Disable "glx" EndSection # ----------------------------- # 50-monitor.conf: # ................ Section "Monitor" Identifier "DELL_U2715H" EndSection # ----------------------------- # 50-screen.conf: # ............... Section "Screen" Identifier "Screen_0" Device "NVidia_GTX750" Monitor "DELL_U2715H" EndSection # ----------------------------- # 99-serverlayout.conf: # ..................... Section "ServerLayout" Identifier "SingleHead_Layout" Screen "Screen_0" EndSection # ----------------------------- Any idea, what might be going on here? Thx! Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Montag, 21. November 2016, 19:30:00 schrieb Michael Hirmke:
1. No xorg.conf.d structure at all -> nouveau gets loaded, X is starting. Same behaviour with Leap 42.2 ad with Tumbleweed.
Have you checked that Xorg is really using nouveau? (in the Xorg log e.g) If nouveau fails to load, Xorg will fall back to a different driver, likely "modesetting" which will still use the nouveau kernel module.
2. Tiny xorg.conf.d structure as shown below with a driver entry for nouveau, i.e. Driver "nouveau" -> X server is not starting with an entry "Unknown chipset: NV117" at the end of Xorg.0.log. Same behaviour with Leap 42.2 ad with Tumbleweed.
Well, apparently the nouveau Xorg driver doesn't support your chipset. As you told Xorg to use nouveau, it fails to start because nouveau cannot be loaded.
3. Tiny xorg.conf.d structure as shown below without a driver entry for nouveau -> X server is starting and one can logon via sddm, but a few program starts later, the nouveau driver is crashing with errors like "nouveau 0000:01:00.0: fifo: PBDMA0: 00040000 [PBENTRY] ch 15 [007e351000 X[1413]] subc 0 mthd 0000 data 00000000". This happens with Leap 42.2 only, not with Tumbleweed - with the exact same modules from kernel 4.8.9-1.
Tumbleweed has a newer kernel (and a newer nouveau kernel module), this may be the difference. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Wolfgang,
Am Montag, 21. November 2016, 19:30:00 schrieb Michael Hirmke:
1. No xorg.conf.d structure at all -> nouveau gets loaded, X is starting. Same behaviour with Leap 42.2 ad with Tumbleweed.
Have you checked that Xorg is really using nouveau? (in the Xorg log e.g)
yes, the log clearly shows this.
If nouveau fails to load, Xorg will fall back to a different driver, likely "modesetting" which will still use the nouveau kernel module.
I know, but this isn't the case here.
2. Tiny xorg.conf.d structure as shown below with a driver entry for nouveau, i.e. Driver "nouveau" -> X server is not starting with an entry "Unknown chipset: NV117" at the end of Xorg.0.log. Same behaviour with Leap 42.2 ad with Tumbleweed.
Well, apparently the nouveau Xorg driver doesn't support your chipset. As you told Xorg to use nouveau, it fails to start because nouveau cannot be loaded.
According to the nouveau page, NV117 is supported.
3. Tiny xorg.conf.d structure as shown below without a driver entry for nouveau -> X server is starting and one can logon via sddm, but a few program starts later, the nouveau driver is crashing with errors like "nouveau 0000:01:00.0: fifo: PBDMA0: 00040000 [PBENTRY] ch 15 [007e351000 X[1413]] subc 0 mthd 0000 data 00000000". This happens with Leap 42.2 only, not with Tumbleweed - with the exact same modules from kernel 4.8.9-1.
Tumbleweed has a newer kernel (and a newer nouveau kernel module), this may be the difference.
As I wrote - I use exactly the same kernel.
Kind Regards, Wolfgang
Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Donnerstag, 24. November 2016, 20:39:00 schrieben Sie:
Have you checked that Xorg is really using nouveau? (in the Xorg log e.g)
yes, the log clearly shows this.
If nouveau fails to load, Xorg will fall back to a different driver, likely "modesetting" which will still use the nouveau kernel module.
I know, but this isn't the case here.
But that's the only explanation I would have. Just to be sure: Xorg will try to load nouveau in any case (and you will see this in the log), but that doesn't mean that it's actually used.
Well, apparently the nouveau Xorg driver doesn't support your chipset. As you told Xorg to use nouveau, it fails to start because nouveau cannot be loaded.
According to the nouveau page, NV117 is supported.
Ok, but the question is since when. The driver clearly states that it doesn't support it, and I doubt that is related to specifying nouveau in the xorg.conf... Actually it seems they *removed* the support again nearly a year ago (in 1.0.12 and 1.0.13): https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=3e2e0faa2... It's been added back in git master a month ago, but there's been no new release yet. https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=a24ded627...
Tumbleweed has a newer kernel (and a newer nouveau kernel module), this may be the difference.
As I wrote - I use exactly the same kernel.
Sorry, overlooked that detail. Well, did you upgrade the kernel-firmware too? Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Wolfgang, thx for your patience :) [...]
If nouveau fails to load, Xorg will fall back to a different driver, likely "modesetting" which will still use the nouveau kernel module.
I know, but this isn't the case here.
But that's the only explanation I would have.
Just to be sure: Xorg will try to load nouveau in any case (and you will see this in the log), but that doesn't mean that it's actually used.
Yes, but the driver module and all of its dependend modules are loaded. And running Yast's hardware info, it says "Kernel driver: nouveau". And whats more: There are journal entries about crashes and errors regarding the nouveau driver.
Well, apparently the nouveau Xorg driver doesn't support your chipset. As you told Xorg to use nouveau, it fails to start because nouveau cannot be loaded.
According to the nouveau page, NV117 is supported.
Ok, but the question is since when. The driver clearly states that it doesn't support it, and I doubt that is related to specifying nouveau in the xorg.conf...
I understand your doubts, I share them, but what I see differs from what I believe :)
Actually it seems they *removed* the support again nearly a year ago (in 1.0.12 and 1.0.13): https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=3e2e0faa2... e1cce9c1bb5c7ad80d0592460f3edc
Ooops. That may explain, why zypper on Tumbleweed shows a warning regarding stability when you install the nouveau X server.
It's been added back in git master a month ago, but there's been no new release yet. https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=a24ded627... 42d453546c553d609edc073f59cd57
But a new kernel in the kernel stable repo, where I get my kernels from.
Tumbleweed has a newer kernel (and a newer nouveau kernel module), this may be the difference.
As I wrote - I use exactly the same kernel.
Sorry, overlooked that detail.
np.
Well, did you upgrade the kernel-firmware too?
Yes.
Kind Regards, Wolfgang
Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Michael Hirmke composed on 2016-11-25 19:23 (UTC+0100):
Wolfgang Bauer composed: ...
Just to be sure: Xorg will try to load nouveau in any case (and you will see this in the log), but that doesn't mean that it's actually used.
Yes, but the driver module and all of its dependend modules are loaded. And running Yast's hardware info, it says "Kernel driver: nouveau". And whats more: There are journal entries about crashes and errors regarding the nouveau driver.
Have you tried using the integrated FOSS driver? (aka modeset(0) in Xorg.0.log) Easy way to try is simply zypper rm xf86-video-nouveau and restart server (though I suppose there may be related loaded modules most easily unloaded via reboot). ... -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Felix, [...]
Yes, but the driver module and all of its dependend modules are loaded. And running Yast's hardware info, it says "Kernel driver: nouveau". And whats more: There are journal entries about crashes and errors regarding the nouveau driver.
Have you tried using the integrated FOSS driver? (aka modeset(0) in Xorg.0.log) Easy way to try is simply zypper rm xf86-video-nouveau and restart server (though I suppose there may be related loaded modules most easily unloaded via reboot).
I never heard about a FOSS driver besides nouveau (vs. nvidia). Do you mean the "nv" driver? [...]
Felix Miata *** http://fm.no-ip.com/
Thx and bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Michael Hirmke composed on 2016-11-26 09:14 (UTC+0100):
[...]
Yes, but the driver module and all of its dependend modules are loaded. And running Yast's hardware info, it says "Kernel driver: nouveau". And whats more: There are journal entries about crashes and errors regarding the nouveau driver.
Have you tried using the integrated FOSS driver? (aka modeset(0) in Xorg.0.log) Easy way to try is simply zypper rm xf86-video-nouveau and restart server (though I suppose there may be related loaded modules most easily unloaded via reboot).
I never heard about a FOSS driver besides nouveau (vs. nvidia). Do you mean the "nv" driver?
No, I meant exactly what I wrote. Try removing xf86-video-nouveau to see if it helps. It doesn't seem like many users are aware of it, even though it seems to be a consolidated focus of recent and current FOSS video driver development regardless of gfxchip[1], and may be a significant if not the primary reason why there has been no Intel video driver "release" in over three years (only git snapshots since). Before server 1.17.x, it came from a separate package xf86-video-modesetting (e.g. in 13.2 & 13.1), but since it has been integrated into the server, and when used in Leap or TW it shows up, instead of radeon, nouveau or intel, as modeset(0) in Xorg.0.log: ... [ 6482.514] (II) modeset(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 6482.514] (==) modeset(0): Depth 24, (==) framebuffer bpp 32 [ 6482.514] (==) modeset(0): RGB weight 888 [ 6482.514] (==) modeset(0): Default visual is TrueColor [ 6482.514] (II) Loading sub module "glamoregl" ... [1] http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Debian-Abandon-Intel-DDX -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Felix, [...]
I never heard about a FOSS driver besides nouveau (vs. nvidia). Do you mean the "nv" driver?
No, I meant exactly what I wrote. Try removing xf86-video-nouveau to see if it helps.
ok, I'll try it. Thx!
It doesn't seem like many users are aware of it, even though it seems to be a consolidated focus of recent and current FOSS video driver development regardless of gfxchip[1], and may be a significant if not the primary reason why there has been no Intel video driver "release" in over three years (only git snapshots since). Before server 1.17.x, it came from a separate package xf86-video-modesetting (e.g. in 13.2 & 13.1), but since it has been integrated into the server, and when used in Leap or TW it shows up, instead of radeon, nouveau or intel, as modeset(0) in Xorg.0.log:
... [ 6482.514] (II) modeset(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 6482.514] (==) modeset(0): Depth 24, (==) framebuffer bpp 32 [ 6482.514] (==) modeset(0): RGB weight 888 [ 6482.514] (==) modeset(0): Default visual is TrueColor [ 6482.514] (II) Loading sub module "glamoregl" ...
[...]
Felix Miata *** http://fm.no-ip.com/
Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi again, [...]
No, I meant exactly what I wrote. Try removing xf86-video-nouveau to see if it helps.
ok, I'll try it. Thx!
I uninstalled everything regarding nouveau, nv and nvidia drivers, but the driver you mentioned wasn't loaded. The X server tried to load something named "modesettings", but didn't succeed without telling the exact reason. After that the fbdevhw driver was loaded, which still failed on my Leap 42.2 system - as described in my original mail. I updated to the latest kernel from the kernel stable repo (4.8.11), but that didn't work either. Adding a Driver entry to xorg.conf.d also wasn't successful. So I don't have any clue what to do next. [...]
[...]
Felix Miata *** http://fm.no-ip.com/
Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Michael Hirmke composed on 2016-11-27 19:30 (UTC+0100):
No, I meant exactly what I wrote. Try removing xf86-video-nouveau to see if it helps.
ok, I'll try it. Thx!
I uninstalled everything regarding nouveau, nv and nvidia drivers, but
Possibly you may need to detail your meaning of "everything" uninstalled. Are you sure everything in /etc/X11* is as the installer left it, neither an xorg.conf file nor any modified files in xorg.conf.d/?
the driver you mentioned wasn't loaded. The X server tried to load something named "modesettings", but didn't succeed without telling the exact reason. After that the fbdevhw driver was loaded, which still failed on my Leap 42.2 system - as described in my original mail. I updated to the latest kernel from the kernel stable repo (4.8.11), but that didn't work either. Adding a Driver entry to xorg.conf.d also wasn't successful. So I don't have any clue what to do next.
Show us an entire Xorg.0.log. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Felix, [...]
I uninstalled everything regarding nouveau, nv and nvidia drivers, but
Possibly you may need to detail your meaning of "everything" uninstalled. Are
every packge named nouveau, nv or nvidia except a few libraries with many dependencies.
you sure everything in /etc/X11* is as the installer left it, neither an xorg.conf file nor any modified files in xorg.conf.d/?
I explicitly removed xorg.conf.d completely. [...]
So I don't have any clue what to do next.
Show us an entire Xorg.0.log.
Ok - I forgot to save it, so I have to repeat the tests. [...]
Felix Miata *** http://fm.no-ip.com/
Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Montag, 28. November 2016, 11:46:00 schrieb Michael Hirmke:
I uninstalled everything regarding nouveau, nv and nvidia drivers, but
Possibly you may need to detail your meaning of "everything" uninstalled. Are every packge named nouveau, nv or nvidia except a few libraries with many dependencies.
Shouldn't be necessary. The only thing would have been xf86-video-nouveau, that's the "nouveau" Xorg driver. Xorg will fall back to "modesetting" if xf86-video-nouveau is not installed (or it fails to load/refuses to run). Then there's also Mesa-dri-nouveau, which contains the "nouveau" OpenGL driver which is also used by "modesetting" as mentioned. You should probably keep it if it doesn't cause you problems, otherwise Mesa's software renderer is used for OpenGL which will be much slower.
you sure everything in /etc/X11* is as the installer left it, neither an xorg.conf file nor any modified files in xorg.conf.d/?
I explicitly removed xorg.conf.d completely.
The whole directory? That's not a good idea, there are other things in there unrelated to the graphics driver. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Wolfgang,
Am Montag, 28. November 2016, 11:46:00 schrieb Michael Hirmke:
I uninstalled everything regarding nouveau, nv and nvidia drivers, but
Possibly you may need to detail your meaning of "everything" uninstalled. Are every packge named nouveau, nv or nvidia except a few libraries with many dependencies.
Shouldn't be necessary.
I tried it step by step ...
The only thing would have been xf86-video-nouveau, that's the "nouveau" Xorg driver.
... with xf86-video-nouveau first. But because that didn't seem to be sufficient I uninstalled them one by one.
Xorg will fall back to "modesetting" if xf86-video-nouveau is not installed (or it fails to load/refuses to run).
Then there's also Mesa-dri-nouveau, which contains the "nouveau" OpenGL driver which is also used by "modesetting" as mentioned. You should probably keep it if it doesn't cause you problems, otherwise Mesa's software renderer is used for OpenGL which will be much slower.
Ok. Next time I give it a try, I will keep the dri module.
you sure everything in /etc/X11* is as the installer left it, neither an xorg.conf file nor any modified files in xorg.conf.d/?
I explicitly removed xorg.conf.d completely.
The whole directory? That's not a good idea, there are other things in there unrelated to the graphics driver.
I know, but there is nothing in it I need. Everything *in my environment* works as expected even without xorg.conf or xorg.conf.d.
Kind Regards, Wolfgang
Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
2016-11-26 11:07 GMT+01:00 Felix Miata:
Michael Hirmke composed on 2016-11-26 09:14 (UTC+0100):
[...]
Yes, but the driver module and all of its dependend modules are loaded. And running Yast's hardware info, it says "Kernel driver: nouveau". And whats more: There are journal entries about crashes and errors regarding the nouveau driver.
Have you tried using the integrated FOSS driver? (aka modeset(0) in Xorg.0.log) Easy way to try is simply zypper rm xf86-video-nouveau and restart server (though I suppose there may be related loaded modules most easily unloaded via reboot).
I never heard about a FOSS driver besides nouveau (vs. nvidia). Do you mean the "nv" driver?
No, I meant exactly what I wrote. Try removing xf86-video-nouveau to see if it helps.
It doesn't seem like many users are aware of it, even though it seems to be a consolidated focus of recent and current FOSS video driver development regardless of gfxchip[1], and may be a significant if not the primary reason why there has been no Intel video driver "release" in over three years (only git snapshots since). Before server 1.17.x, it came from a separate package xf86-video-modesetting (e.g. in 13.2 & 13.1), but since it has been integrated into the server, and when used in Leap or TW it shows up, instead of radeon, nouveau or intel, as modeset(0) in Xorg.0.log:
... [ 6482.514] (II) modeset(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 6482.514] (==) modeset(0): Depth 24, (==) framebuffer bpp 32 [ 6482.514] (==) modeset(0): RGB weight 888 [ 6482.514] (==) modeset(0): Default visual is TrueColor [ 6482.514] (II) Loading sub module "glamoregl" ...
[1] http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Debian-Abandon-Intel-DDX
Hi Felix, to speak for me, I'm aware of the modesetting driver, but for NVidia graphics hardware there are limits, can be obviously used just for GeFore 8 chipsets (and newer). As an example, I have a HP ZBook 15 G2 with a K610M (GK208, Kepler 2.0 architecture) chipset (released in summer 2013), which isn't supported according to the official sources (see below). Because my notebook supports Hybrid Graphics there is an additional, integrated Intel HD graphics 4600. My tests with the xf86-video-modesetting driver confirmed this, it just failed here however I set this hardware up in the BIOS. Although I'd appreciate this trend, xf86-video-modesetting requires very new NVidia graphics chipsets and thus cannot be enabled by default for all. [1] http://www.phoronix.com/scan.php?page=news_item&px=Nouveau-Vs-Modesetting [2] https://bugs.freedesktop.org/show_bug.cgi?id=94844 [3] https://www.techpowerup.com/gpudb/2431/quadro-k610m René -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Freitag, 25. November 2016, 20:23:00 schrieb Michael Hirmke:
Yes, but the driver module and all of its dependend modules are loaded.
As I wrote, the nouveau Xorg driver will be loaded anyway, but that doesn't mean it's actually used. All the evidence I see tells me that it refuses to run and Xorg is using the generic "modesetting" driver instead, this is the one Felix Miata is talking about too btw.
And running Yast's hardware info, it says "Kernel driver: nouveau". And whats more: There are journal entries about crashes and errors regarding the nouveau driver.
Don't confuse the Xorg driver with the kernel module. The nouveau kernel module (kernel driver) is still loaded, even if you uninstall the nouveu Xorg driver, and "modesetting" depends on it/requires it too.
I understand your doubts, I share them, but what I see differs from what I believe :)
Well, you may be misinterpretung what you see. To prove that the nouveau *Xorg* driver is used, please provide the Xorg.0.log. ;-)
Ooops. That may explain, why zypper on Tumbleweed shows a warning regarding stability when you install the nouveau X server.
No, that's about the Mesa OpenGL nouveau driver, another part that's quite unrelated to the Xorg driver, and also used by "modesetting" if installed.
It's been added back in git master a month ago, but there's been no new release yet. https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=a24ded62 7e 42d453546c553d609edc073f59cd57
But a new kernel in the kernel stable repo, where I get my kernels from.
Again, this is completely unrelated to the kernel module, support for your GPU is apparently missing from the nouveau Xorg driver, not the kernel module.
Well, did you upgrade the kernel-firmware too?
Yes.
Hm. Maybe try to run "mkinitrd" then to make sure the new firmware is part of the initrd. It is normally loaded before the root filesystem is mounted. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Wolfgang,
Am Freitag, 25. November 2016, 20:23:00 schrieb Michael Hirmke:
Yes, but the driver module and all of its dependend modules are loaded.
As I wrote, the nouveau Xorg driver will be loaded anyway, but that doesn't mean it's actually used.
even if there was no "module unloaded" message in the Xorg.0.log?
All the evidence I see tells me that it refuses to run and Xorg is using the generic "modesetting" driver instead, this is the one Felix Miata is talking about too btw.
After uninstalling nvidia, nv and nouveau this driver indeed is loadead and later unloaded, as the log states. The next one is fbdevhw which seems to be the one the X server is finally using.
And running Yast's hardware info, it says "Kernel driver: nouveau". And whats more: There are journal entries about crashes and errors regarding the nouveau driver.
Don't confuse the Xorg driver with the kernel module. The nouveau kernel module (kernel driver) is still loaded, even if you uninstall the nouveu Xorg driver, and "modesetting" depends on it/requires it too.
Ok, I didn't know that, but see above ...
I understand your doubts, I share them, but what I see differs from what I believe :)
Well, you may be misinterpretung what you see. To prove that the nouveau *Xorg* driver is used, please provide the Xorg.0.log. ;-)
Ok, The next time I have the time to test, I'll provide logs, I promise :)
Ooops. That may explain, why zypper on Tumbleweed shows a warning regarding stability when you install the nouveau X server.
No, that's about the Mesa OpenGL nouveau driver, another part that's quite unrelated to the Xorg driver, and also used by "modesetting" if installed.
Ok. [...]
But a new kernel in the kernel stable repo, where I get my kernels from.
Again, this is completely unrelated to the kernel module, support for your GPU is apparently missing from the nouveau Xorg driver, not the kernel module.
Uh, slowly but steadily I get the pieces together - thx!
Well, did you upgrade the kernel-firmware too?
Yes.
Hm. Maybe try to run "mkinitrd" then to make sure the new firmware is part of the initrd.
Doesn't kernel installation always trigger a mkinitrd?
It is normally loaded before the root filesystem is mounted.
Kind Regards, Wolfgang
Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Montag, 28. November 2016, 21:09:00 schrieb Michael Hirmke:
After uninstalling nvidia, nv and nouveau this driver indeed is loadead and later unloaded, as the log states. The next one is fbdevhw which seems to be the one the X server is finally using.
Various drivers (that are installed) are loaded. But only one is used. And if nouveau doesn't support your card, it will be loaded, but not used. Anyway, I see no point in discussing this further. Xorg.0.log would show what really happens/happened.
Hm. Maybe try to run "mkinitrd" then to make sure the new firmware is part of the initrd.
Doesn't kernel installation always trigger a mkinitrd?
The kernel installation does, yes. But I don't think the installation of kernel-firmware does, so there may still be the older version in the initrd after you update kernel-firmware. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
29.11.2016 00:03, Wolfgang Bauer пишет:
Doesn't kernel installation always trigger a mkinitrd?
The kernel installation does, yes.
But I don't think the installation of kernel-firmware does,
It does, at lest current TW version. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Michael Hirmke composed on 2016-11-21 19:30 (UTC+0100):
I'm still trying to switch somehow automatically between the nvidia and the nouveau driver, but I ran into a quite annoying problem on both openSuSE Leap 42.2 (even with the latest kernel from the kernel stable repository) and also with the latest Tumbleweed snapshot.
I don't have problems, running the nouveau driver if I don't have an xorg.conf.d structure at all, but even with a very tiny structure the X server won't start anymore, and I can't figure out, what I might be missing here. ... An xorg.conf.d/ that looks as follows should work in any event as long as there is no interference from installation of and subsequent incomplete removal of a
Neither modesetting nor nouveau will function if nomodeset or nouveau.modeset=0 is present on kernel's cmdline, while either of the latter two is required for any nvidia proprietary driver to function. Thus, I'd be surprised to learn that there is any practical way to make an automatic switch between FOSS and proprietary with any NVidia gfxchip. proprietary NVidia driver: -rw-r--r-- 1 root root 232 Dec 11 2015 00-keyboard.conf -rw-r--r-- 1 root root 1099 Oct 7 19:52 10-evdev.conf -rw-r--r-- 1 root root 488 Nov 3 07:16 10-libvnc.conf -rw-r--r-- 1 root root 1350 Oct 18 17:00 10-quirks.conf -rw-r--r-- 1 root root 484 Oct 7 19:52 11-evdev.conf -rw-r--r-- 1 root root 529 Jul 1 2011 50-device.conf -rw-r--r-- 1 root root 264 Oct 18 17:00 50-extensions.conf -rw-r--r-- 1 root root 527 Jul 1 2011 50-monitor.conf -rw-r--r-- 1 root root 491 Jul 1 2011 50-screen.conf The three OEM 2011 files are nothing but comments, so whether they are present or not doesn't matter, unless they are present and have been modified in a manner incompatible with the FOSS drivers. All but one of the others have no impact on video. 50-extensions.conf looks like is there for some kind of ancient hardware, so also shouldn't matter with your NV117. Its presence is new post-42.1. With an xorg.conf.d/ as above and no xorg.conf file at all, video regardless of gfxchip should work automagically, unless the gfxchip is too new for FOSS support to be included, or its support is broken. Also new post-42.1 is /etc/X11/xorg_pci_ids/modesetting.ids. Check to see of the ID of your NV117 matches anything in it. Possibly your NV117 may be either missing and need to be there, or included but should not be. It's something else you might want to test as a possible reason why the modesetting driver tried to load but failed.
# 99-serverlayout.conf: # ..................... Section "ServerLayout" Identifier "SingleHead_Layout" Screen "Screen_0" EndSection
That file is not present on any of my 42.2 or TW installations. Could it be a leftover from trying a proprietary nvidia driver, and the root of your scenario #2 and/or #3 failing? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2016-11-28 01:19, Felix Miata wrote:
Neither modesetting nor nouveau will function if nomodeset or nouveau.modeset=0 is present on kernel's cmdline, while either of the latter two is required for any nvidia proprietary driver to function. Thus, I'd be surprised to learn that there is any practical way to make an automatic switch between FOSS and proprietary with any NVidia gfxchip.
This paragraph is confusing to me. You say that for the nvidia proprietary driver to work, one needs either "nomodeset" or "nouveau.modeset=0" in the kernel command line? Well, I use neither: Isengard:~ # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.4.27-2-default root=UUID=0d457df1-b43d-4587-aa5a-6c919bcbedb8 ro resume=/dev/sda2 splash=verbose showopts Isengard:~ # -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. composed on 2016-11-28 02:03 (UTC+0100):
On 2016-11-28 01:19, Felix Miata wrote:
Neither modesetting nor nouveau will function if nomodeset or nouveau.modeset=0 is present on kernel's cmdline, while either of the latter two is required for any nvidia proprietary driver to function. Thus, I'd be surprised to learn that there is any practical way to make an automatic switch between FOSS and proprietary with any NVidia gfxchip.
This paragraph is confusing to me.
You say that for the nvidia proprietary driver to work, one needs either "nomodeset" or "nouveau.modeset=0" in the kernel command line? Well, I use neither:
Isengard:~ # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.4.27-2-default root=UUID=0d457df1-b43d-4587-aa5a-6c919bcbedb8 ro resume=/dev/sda2 splash=verbose showopts Isengard:~ #
Well then NVidia must finally have brought its driver into the KMS era. With what version(s) of its driver did this first occur? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2016-11-28 02:59, Felix Miata wrote:
Carlos E. R. composed on 2016-11-28 02:03 (UTC+0100):
On 2016-11-28 01:19, Felix Miata wrote:
Neither modesetting nor nouveau will function if nomodeset or nouveau.modeset=0 is present on kernel's cmdline, while either of the latter two is required for any nvidia proprietary driver to function. Thus, I'd be surprised to learn that there is any practical way to make an automatic switch between FOSS and proprietary with any NVidia gfxchip.
This paragraph is confusing to me.
You say that for the nvidia proprietary driver to work, one needs either "nomodeset" or "nouveau.modeset=0" in the kernel command line? Well, I use neither:
Isengard:~ # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.4.27-2-default root=UUID=0d457df1-b43d-4587-aa5a-6c919bcbedb8 ro resume=/dev/sda2 splash=verbose showopts Isengard:~ #
Well then NVidia must finally have brought its driver into the KMS era. With what version(s) of its driver did this first occur?
I don't know. I use "NVIDIA-Linux-x86_64-340.96.run", the machine is still on 13.1. The trick this file: Telcontar:~ # cat /etc/modprobe.d/nvidia-installer-disable-nouveau.conf # generated by nvidia-installer blacklist nouveau options nouveau modeset=0 Telcontar:~ # It is the same settings you mention, but done in a separate file that is read after booting and loading the kernel, although it is possible that the file is replicated in the initrd ramdisk, so it is read early enough. Doesn't look as if it is using KMS. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. composed on 2016-11-28 04:19 (UTC+0100):
Felix Miata wrote:
Carlos E. R. composed on 2016-11-28 02:03 (UTC+0100):
On 2016-11-28 01:19, Felix Miata wrote:
Neither modesetting nor nouveau will function if nomodeset or nouveau.modeset=0 is present on kernel's cmdline, while either of the latter two is required for any nvidia proprietary driver to function. Thus, I'd be surprised to learn that there is any practical way to make an automatic switch between FOSS and proprietary with any NVidia gfxchip.
This paragraph is confusing to me.
You say that for the nvidia proprietary driver to work, one needs either "nomodeset" or "nouveau.modeset=0" in the kernel command line? Well, I use neither:
Isengard:~ # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.4.27-2-default root=UUID=0d457df1-b43d-4587-aa5a-6c919bcbedb8 ro resume=/dev/sda2 splash=verbose showopts Isengard:~ #
Well then NVidia must finally have brought its driver into the KMS era. With what version(s) of its driver did this first occur?
I don't know. I use "NVIDIA-Linux-x86_64-340.96.run", the machine is still on 13.1.
The trick this file:
Telcontar:~ # cat /etc/modprobe.d/nvidia-installer-disable-nouveau.conf # generated by nvidia-installer blacklist nouveau options nouveau modeset=0 Telcontar:~ #
It is the same settings you mention, but done in a separate file that is read after booting and loading the kernel, although it is possible that the file is replicated in the initrd ramdisk, so it is read early enough.
Doesn't look as if it is using KMS.
So it would seem as a non-user of proprietary drivers I have oversimplified the possible mechanics by which proprietary driver installation can defeat KMS in order for the proprietary Xorg driver to be employed. Presence of either modeset defeat parameter on cmdline, if present, thus represents a readily available clue to KMS defeat, rather than being necessary to its defeat. Nevertheless, it remains that as long as KMS is blocked, neither nouveau nor modesetting Xorg driver can be used, so it seems that OP's stated goal of automatic switching between proprietary and FOSS for driving his NV117 may be unreachable. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Montag, 28. November 2016, 00:04:54 schrieb Felix Miata:
Nevertheless, it remains that as long as KMS is blocked, neither nouveau nor modesetting Xorg driver can be used
That is correct. nv may be used then, but as it's quite old it probably doesn't work in this case either.
, so it seems that OP's stated goal of automatic switching between proprietary and FOSS for driving his NV117 may be unreachable.
I concur. There's the other problem that Mesa will not work when the proprietary nvidia driver is installed (because nvidia replaces some libraries, libglx and libGL in particular, with its own incompatible versions, so not even Mesa's software OpenGL renderer will work. In other words, OpenGL will be broken completely unless you uninstall nvidia, which in turn will not allow desktops like Plasma or GNOME to even start, and of course every other application that uses OpenGL. This may be solvable too by heavy tricks, but definitely not easily. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Montag, 28. November 2016 14:24:51 CET Wolfgang Bauer wrote:
Am Montag, 28. November 2016, 00:04:54 schrieb Felix Miata:
Nevertheless, it remains that as long as KMS is blocked, neither nouveau nor modesetting Xorg driver can be used
That is correct. nv may be used then, but as it's quite old it probably doesn't work in this case either.
, so it seems that OP's stated goal of automatic switching between proprietary and FOSS for driving his NV117 may be unreachable.
I concur. There's the other problem that Mesa will not work when the proprietary nvidia driver is installed (because nvidia replaces some libraries, libglx and libGL in particular, with its own incompatible versions, so not even Mesa's software OpenGL renderer will work.
In other words, OpenGL will be broken completely unless you uninstall nvidia, which in turn will not allow desktops like Plasma or GNOME to even start, and of course every other application that uses OpenGL.
This may be solvable too by heavy tricks, but definitely not easily.
This may have changed recently: https://www.x.org/wiki/Events/XDC2016/Program/xdc-2016-glvnd-status.pdf Maybe time to create a testing repo with glvnd enabled? Kind regards, Stefan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Wolfgang, [...]
There's the other problem that Mesa will not work when the proprietary nvidia driver is installed (because nvidia replaces some libraries, libglx and libGL in particular, with its own incompatible versions, so not even Mesa's software OpenGL renderer will work.
don't know for libGL, but for libglx one can use update-alternatives to switch between the nouveau and the nvidia implementation. In my script for switching I use this command. [...]
Kind Regards, Wolfgang
Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 2016-11-28 21:12, Michael Hirmke wrote:
Hi Wolfgang,
[...]
There's the other problem that Mesa will not work when the proprietary nvidia driver is installed (because nvidia replaces some libraries, libglx and libGL in particular, with its own incompatible versions, so not even Mesa's software OpenGL renderer will work.
don't know for libGL, but for libglx one can use update-alternatives to switch between the nouveau and the nvidia implementation.
You don't really need u-a. Place all the nvidia system libraries into a separate directory (/usr/lib/nvidia or what) and prioritize it via ld.so.conf. For the Xorg plugins, there is already a dedicated directory one can use, /usr/lib/xorg/extensions/updates. That way, nvidia does not collide with Mesa, yet both can be installed at the same time (to satisfy rpm's solver). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Montag, 28. November 2016, 21:12:00 schrieb Michael Hirmke:
don't know for libGL, but for libglx one can use update-alternatives to switch between the nouveau and the nvidia implementation.
Yes, since 13.2 at least. Switching libGL is more difficult though, as there is no update-alternatives in effect for it. The nvidia rpms work around that by installing the nvidia libraries to a different location and add a file to /etc/ld.so.conf.d/ to prefer that one. The .run install just overwrites Mesa's files though AFAIK. The glvnd as Stefan Brüns has mentioned may be an option, I don't know much about it. But I'm not sure what your actual goal is. Switching between nvidia and nouveau should be as easy as installing/uninstalling the nvidia driver. There's not even a need to modify the Xorg config actually (nvidia will be preferred if it is installed). If you want to switch on "runtime" without uninstalling the nvidia driver, it gets more difficult of course. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Wolfgang, [...]
But I'm not sure what your actual goal is.
one goal was to understand what is going on under the surface. And I am very pleased about your and Felix' explanations. I learnt a lot about the backgounds.
Switching between nvidia and nouveau should be as easy as installing/uninstalling the nvidia driver. There's not even a need to modify the Xorg config actually (nvidia will be preferred if it is installed). If you want to switch on "runtime" without uninstalling the nvidia driver, it gets more difficult of course.
This is one of the things I learnt :) Whats more: - I learnt, that not nouveau but modesetting is the driver I can use instead of nvidia. - I succeeded in loading the modesetting driver. - I learnt the differences between kernel modules and X drivers. - And I had a lot of fun testing all those things ;)
Kind Regards, Wolfgang
Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
28.11.2016 03:19, Felix Miata пишет:
Neither modesetting nor nouveau will function if nomodeset or nouveau.modeset=0 is present on kernel's cmdline, while either of the latter two is required for any nvidia proprietary driver to function.
That's wrong. You can simply prevent automatic loading of nouveau.
Thus, I'd be surprised to learn that there is any practical way to make an automatic switch between FOSS and proprietary with any NVidia gfxchip.
Even if nouveau was loaded, it still may be possible to do rmmod nouveau; modprobe nvidia. You may need to do more (like switching console away from framebuffer), someone has to do a bit of experimenting. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Felix,
Michael Hirmke composed on 2016-11-21 19:30 (UTC+0100):
I'm still trying to switch somehow automatically between the nvidia and the nouveau driver, but I ran into a quite annoying problem on both openSuSE Leap 42.2 (even with the latest kernel from the kernel stable repository) and also with the latest Tumbleweed snapshot.
Neither modesetting nor nouveau will function if nomodeset or nouveau.modeset=0 is present on kernel's cmdline, while either of the latter two is required for any nvidia proprietary driver to function. Thus, I'd be surprised to learn that there is any practical way to make an automatic switch between FOSS and proprietary with any NVidia gfxchip.
I wrote a script, that - modifies /etc/X11/xorg.conf.d - modifies /etc/default/grub and runs grub2-mkconfig - modifies /etc/modprobe.d/99-local.conf and nvidia-*.conf - calls updates-alternatives -set libglx.so <path> The files are looking correct afterwards and a reboot shows that everything is in place. Neverthelesse nouveau won't load, while nvidia and nv do it. [...]
An xorg.conf.d/ that looks as follows should work in any event as long as there is no interference from installation of and subsequent incomplete removal of a proprietary NVidia driver:
-rw-r--r-- 1 root root 232 Dec 11 2015 00-keyboard.conf -rw-r--r-- 1 root root 1099 Oct 7 19:52 10-evdev.conf -rw-r--r-- 1 root root 488 Nov 3 07:16 10-libvnc.conf -rw-r--r-- 1 root root 1350 Oct 18 17:00 10-quirks.conf -rw-r--r-- 1 root root 484 Oct 7 19:52 11-evdev.conf -rw-r--r-- 1 root root 529 Jul 1 2011 50-device.conf -rw-r--r-- 1 root root 264 Oct 18 17:00 50-extensions.conf -rw-r--r-- 1 root root 527 Jul 1 2011 50-monitor.conf -rw-r--r-- 1 root root 491 Jul 1 2011 50-screen.conf
I know, I create all files with my script. And again, they seem to be sufficient for nvidia and nv, but not for nouveau. [...]
With an xorg.conf.d/ as above and no xorg.conf file at all, video regardless of gfxchip should work automagically, unless the gfxchip is too new for FOSS support to be included, or its support is broken.
It tried to load it, but also unloaded it afterwards without giving any reason.
Also new post-42.1 is /etc/X11/xorg_pci_ids/modesetting.ids. Check to see of the ID of your NV117 matches anything in it. Possibly your NV117 may be either missing and need to be there, or included but should not be. It's something else you might want to test as a possible reason why the modesetting driver tried to load but failed.
Uh, didn't know that. I'll check it.
# 99-serverlayout.conf: # ..................... Section "ServerLayout" Identifier "SingleHead_Layout" Screen "Screen_0" EndSection
That file is not present on any of my 42.2 or TW installations. Could it be a leftover from trying a proprietary nvidia driver, and the root of your scenario #2 and/or #3 failing?
No, I create it explicitly - see above. [...] Btw. - thx a lot for your hints!
Felix Miata *** http://fm.no-ip.com/
Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2016-11-28 11:59, Michael Hirmke wrote:
I wrote a script, that - modifies /etc/X11/xorg.conf.d - modifies /etc/default/grub and runs grub2-mkconfig - modifies /etc/modprobe.d/99-local.conf and nvidia-*.conf - calls updates-alternatives -set libglx.so <path>
The files are looking correct afterwards and a reboot shows that everything is in place. Neverthelesse nouveau won't load, while nvidia and nv do it.
You probably need "mkinitrd" and reboot. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Hi Carlos, [...]
I wrote a script, that - modifies /etc/X11/xorg.conf.d - modifies /etc/default/grub and runs grub2-mkconfig - modifies /etc/modprobe.d/99-local.conf and nvidia-*.conf - calls updates-alternatives -set libglx.so <path> =20 The files are looking correct afterwards and a reboot shows that everything is in place. Neverthelesse nouveau won't load, while nvidia and nv do it.
You probably need "mkinitrd" and reboot.
I left out these small details :) Yes, of course you are right!
--=20 Cheers / Saludos,
Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi *, I finally succeeded in loading the modesetting driver as Felix suggested. @Felix: Is that the output one can expect? Is it enough or do you need the complete log? ------------------------< snip snip snip >----------------------------- [...] [ 18.930] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration [ 18.931] (II) xfree86: Adding drm device (/dev/dri/card0) [ 18.933] (--) PCI:*(0:1:0:0) 10de:1381:1043:8517 rev 162, Mem @ 0xf6000000/16777216, 0xe0000000/268435456, 0xf0000000/33554432, I/O @ 0x0000e000/128, BIOS @ 0x????????/524288 [ 18.933] (II) LoadModule: "glx" [ 18.935] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so [ 18.944] (II) Module glx: vendor="X.Org Foundation" [ 18.944] compiled for 1.18.3, module version = 1.0.0 [ 18.944] ABI class: X.Org Server Extension, version 9.0 [ 18.944] (==) AIGLX enabled [ 18.945] (II) Scanning /etc/X11/xorg_pci_ids directory for additional PCI ID's supported by the drivers [ 18.945] (II) Scanning /etc/X11/xorg_pci_ids directory for additional PCI ID's supported by the drivers [ 18.945] (==) Matched nvidia as autoconfigured driver 0 [ 18.945] (==) Matched nouveau as autoconfigured driver 1 [ 18.945] (==) Matched nv as autoconfigured driver 2 [ 18.945] (==) Matched nvidia as autoconfigured driver 3 [ 18.945] (==) Matched nouveau as autoconfigured driver 4 [ 18.945] (==) Matched nv as autoconfigured driver 5 [ 18.945] (==) Matched modesetting as autoconfigured driver 6 [ 18.945] (==) Matched fbdev as autoconfigured driver 7 [ 18.945] (==) Matched vesa as autoconfigured driver 8 [ 18.945] (==) Assigned the driver to the xf86ConfigLayout [ 18.945] (II) LoadModule: "nvidia" [ 18.946] (WW) Warning, couldn't open module nvidia [ 18.946] (II) UnloadModule: "nvidia" [ 18.946] (II) Unloading nvidia [ 18.946] (EE) Failed to load module "nvidia" (module does not exist, 0) [ 18.946] (II) LoadModule: "nouveau" [ 18.947] (WW) Warning, couldn't open module nouveau [ 18.947] (II) UnloadModule: "nouveau" [ 18.947] (II) Unloading nouveau [ 18.947] (EE) Failed to load module "nouveau" (module does not exist, 0) [ 18.947] (II) LoadModule: "nv" [ 18.947] (WW) Warning, couldn't open module nv [ 18.947] (II) UnloadModule: "nv" [ 18.947] (II) Unloading nv [ 18.947] (EE) Failed to load module "nv" (module does not exist, 0) [ 18.947] (II) LoadModule: "modesetting" [ 18.947] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so [ 18.947] (II) Module modesetting: vendor="X.Org Foundation" [ 18.947] compiled for 1.18.3, module version = 1.18.3 [ 18.947] Module class: X.Org Video Driver [ 18.947] ABI class: X.Org Video Driver, version 20.0 [ 18.947] (II) LoadModule: "fbdev" [ 18.948] (II) Loading /usr/lib64/xorg/modules/drivers/fbdev_drv.so [ 18.948] (II) Module fbdev: vendor="X.Org Foundation" [ 18.948] compiled for 1.18.3, module version = 0.4.4 [ 18.948] Module class: X.Org Video Driver [ 18.948] ABI class: X.Org Video Driver, version 20.0 [ 18.948] (II) LoadModule: "vesa" [ 18.948] (II) Loading /usr/lib64/xorg/modules/drivers/vesa_drv.so [ 18.948] (II) Module vesa: vendor="X.Org Foundation" [ 18.948] compiled for 1.18.3, module version = 2.3.4 [ 18.948] Module class: X.Org Video Driver [ 18.948] ABI class: X.Org Video Driver, version 20.0 [ 18.948] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 18.948] (II) FBDEV: driver for framebuffer: fbdev [ 18.948] (II) VESA: driver for VESA chipsets: vesa [ 18.951] (II) modeset(0): using drv /dev/dri/card0 [ 18.951] (WW) Falling back to old probe method for fbdev [ 18.951] (II) Loading sub module "fbdevhw" [ 18.951] (II) LoadModule: "fbdevhw" [ 18.951] (II) Loading /usr/lib64/xorg/modules/libfbdevhw.so [ 18.951] (II) Module fbdevhw: vendor="X.Org Foundation" [ 18.951] compiled for 1.18.3, module version = 0.0.2 [ 18.951] ABI class: X.Org Video Driver, version 20.0 [ 18.951] (WW) Falling back to old probe method for vesa [ 18.965] (II) modeset(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 18.965] (==) modeset(0): Depth 24, (==) framebuffer bpp 32 [ 18.965] (==) modeset(0): RGB weight 888 [ 18.965] (==) modeset(0): Default visual is TrueColor [ 18.965] (II) Loading sub module "glamoregl" [ 18.965] (II) LoadModule: "glamoregl" [ 18.965] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so [ 18.973] (II) Module glamoregl: vendor="X.Org Foundation" [ 18.973] compiled for 1.18.3, module version = 1.0.0 [ 18.973] ABI class: X.Org ANSI C Emulation, version 0.4 [ 18.973] (II) glamor: OpenGL accelerated X.org driver based. [ 19.166] (II) glamor: EGL version 1.4 (DRI2): [ 19.171] (II) modeset(0): glamor initialized [ 19.182] (II) modeset(0): Output DVI-I-1 has no monitor section [ 19.184] (II) modeset(0): Output HDMI-1 has no monitor section [ 19.195] (II) modeset(0): Output DP-1 has no monitor section [ 19.207] (II) modeset(0): EDID for output DVI-I-1 [ 19.208] (II) modeset(0): EDID for output HDMI-1 [ 19.219] (II) modeset(0): EDID for output DP-1 [ 19.219] (II) modeset(0): Manufacturer: DEL Model: d065 Serial#: 809583180 [ 19.219] (II) modeset(0): Year: 2015 Week: 4 [ 19.219] (II) modeset(0): EDID Version: 1.4 [ 19.219] (II) modeset(0): Digital Display Input [ 19.219] (II) modeset(0): 8 bits per channel [ 19.219] (II) modeset(0): Digital interface is DisplayPort [ 19.219] (II) modeset(0): Max Image Size [cm]: horiz.: 60 vert.: 34 [ 19.219] (II) modeset(0): Gamma: 2.20 [ 19.219] (II) modeset(0): DPMS capabilities: Off [ 19.219] (II) modeset(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 YCrCb 4:2:2 [ 19.219] (II) modeset(0): Default color space is primary color space [ 19.219] (II) modeset(0): First detailed timing is preferred mode [ 19.219] (II) modeset(0): Preferred mode is native pixel format and refresh rate [ 19.219] (II) modeset(0): redX: 0.661 redY: 0.332 greenX: 0.302 greenY: 0.613 [ 19.219] (II) modeset(0): blueX: 0.149 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 [...] [ 19.221] (II) modeset(0): Output DVI-I-1 disconnected [ 19.221] (II) modeset(0): Output HDMI-1 disconnected [ 19.221] (II) modeset(0): Output DP-1 connected [ 19.221] (II) modeset(0): Using exact sizes for initial modes [ 19.221] (II) modeset(0): Output DP-1 using initial mode 2560x1440 +0+0 [ 19.221] (II) modeset(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated. [ 19.221] (==) modeset(0): DPI set to (96, 96) [ 19.221] (II) Loading sub module "fb" [ 19.221] (II) LoadModule: "fb" [ 19.221] (II) Loading /usr/lib64/xorg/modules/libfb.so [ 19.222] (II) Module fb: vendor="X.Org Foundation" [ 19.222] compiled for 1.18.3, module version = 1.0.0 [ 19.222] ABI class: X.Org ANSI C Emulation, version 0.4 [ 19.222] (II) UnloadModule: "fbdev" [ 19.222] (II) Unloading fbdev [ 19.222] (II) UnloadSubModule: "fbdevhw" [ 19.222] (II) Unloading fbdevhw [ 19.222] (II) UnloadModule: "vesa" [ 19.222] (II) Unloading vesa [ 19.222] (==) Depth 24 pixmap format is 32 bpp [ 19.277] (==) modeset(0): Backing store enabled [ 19.277] (==) modeset(0): Silken mouse enabled [ 19.277] (II) modeset(0): RandR 1.2 enabled, ignore the following RandR disabled message. [ 19.295] (==) modeset(0): DPMS enabled [ 19.295] (II) modeset(0): [DRI2] Setup complete [ 19.295] (II) modeset(0): [DRI2] DRI driver: nouveau [ 19.295] (II) modeset(0): [DRI2] VDPAU driver: nouveau [ 19.491] (--) RandR disabled [ 19.499] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer [ 19.499] (II) AIGLX: enabled GLX_ARB_create_context [ 19.499] (II) AIGLX: enabled GLX_ARB_create_context_profile [ 19.499] (II) AIGLX: enabled GLX_EXT_create_context_es{,2}_profile [ 19.499] (II) AIGLX: enabled GLX_INTEL_swap_event [ 19.499] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control [ 19.499] (II) AIGLX: enabled GLX_EXT_framebuffer_sRGB [ 19.499] (II) AIGLX: enabled GLX_ARB_fbconfig_float [ 19.499] (II) AIGLX: enabled GLX_EXT_fbconfig_packed_float [ 19.499] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects [ 19.500] (II) AIGLX: Loaded and initialized nouveau [ 19.500] (II) GLX: Initialized DRI2 GL provider for screen 0 [ 19.639] (II) modeset(0): Setting screen physical size to 677 x 381 [...] ------------------------< snip snip snip >----------------------------- So I could also complete my script for switching back and forth between nvidia and modesetting. ------------------------< snip snip snip >----------------------------- #!/bin/bash exec >/tmp/nv_switch_driver.log 2>&1 set -x TO="$1" case "$TO" in nvidia) FROM="modesetting" LIBGLX="/usr/lib64/xorg/modules/extensions/nvidia/nvidia-libglx.so" ;; modesetting) FROM="nvidia" LIBGLX="/usr/lib64/xorg/modules/extensions/xorg/xorg-libglx.so" cd /etc/modprobe.d && \ rm -f nvidia-default.conf /usr/bin/zypper rm -y xf86-video-nouveau xf86-video-nvidiaGL04 ;; esac if [ -n "$FROM" ] then cd /etc/X11 && \ rm -rf xorg.conf.d && \ ln -s xorg.conf.d.${TO} xorg.conf.d && \ cd /etc/modprobe.d && \ sed -r -e "s/^#\s+blacklist\s+${FROM}/blacklist ${FROM}/" \ -e "s/^blacklist\s+${TO}/# blacklist ${TO}/" \ 99-local.conf >99-local.conf.x && \ mv 99-local.conf.x 99-local.conf && \ cd /etc/default && \ sed -r -e "s/^GRUB_CMDLINE_LINUX_DEFAULT=/# ${FROM} _GRUB_CMDLINE_LINUX_DEFAULT=/" \ -e "s/^#\s+${TO}\s_GRUB_CMDLINE_LINUX_DEFAULT=/GRUB_CMDLINE_LINUX_DEFAULT=/" \ grub >grub.x && \ mv grub.x grub && \ cd /boot/grub2 && \ grub2-mkconfig >grub.cfg && \ update-alternatives --set libglx.so "$LIBGLX" && \ /sbin/ldconfig && \ /sbin/mkinitrd else exit 1 fi ------------------------< snip snip snip >----------------------------- Thx@all! Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (8)
-
Andrei Borzenkov -
Brüns, Stefan -
Carlos E. R. -
Felix Miata -
Jan Engelhardt -
mh＠mike.franken.de -
René Krell -
Wolfgang Bauer