Public bug reported:
This bug should be able to be reproduced on any computer with i915 +
nouveau simultaneously modesetting, booting to stock gdm3 (wayland by
default). My main example is a MacBookPro6,2 with the infamous GT 330m
on 20.04 with -proposed enabled and booting with the following grub
manipulations to set gmux to the integrated LVDS:
outb 0x710 2 - switch LVDS to intel
outb 0x728 1 - switch internal DDC to intel
outb 0x740 2 - switch displayport out to intel
I am not using outb 0x750 0, so that the 330m remains powered on. It
still works just fine-- the only thing broken is the LVDS connection to
the internal panel. I disable it with video=LVDS-2:d.
--> NOTE: This mod is only for the convenience of not having to deal
with a phantom second screen once booted (both GPU's have the LVDS and
edid of the internal screen hooked up). The computer boots fine and the
bug reproduces exactly the same with or without it.
I tested with all these modifications disabled, and this still occurred
- it's not specific to my configuration. A user booting stock Ubuntu on
this laptop, or as I discovered later, any nouveau + i915 hardware
combination will run into this as well.
Anyways, I'm keeping the 330m enabled to use DRI_PRIME to run
applications on the 330m for good reason- it supports OpenGL 3.3 while
HD Graphics (arrandale aka Ironlake) is the only HD Graphics iGPU stuck
on OpenGL 2.1, thus otherwise vastly restricting the modern graphics
workloads of the system.
When explicitly booting with gdm3 WaylandEnable=false (login and desktop
both xorg), everything works as expected - single screen driven by the
i915's KMS, nouveau with DRI_PRIME working, returning NVA5 stats and
functional with OpenGL 3 apps as well.
On GDM3 wayland, however (by default-- which is why I think this bug is
rather important), gdm3 starts to a black screen with cursor. The login
screen and shell still seem to be running-- I can type my password
blindly and press enter and the cursor freezes briefly as it does during
a non-broken login. After a few seconds, I can press the volume up/down
keys and I hear the volume sound. Pressing the app grid shortcut makes
the cursor lag, just as it does when I disable the nvidia at the pcie
link level and rendering works on i915. Backlight control also works on
the login screen and once logged in. It's as if everything except the
actual rendering to the screen is working.
The minute I pass nouveau.modeset=0 in cmdline, or cut the power to the
330m at the hardware level with outb 0x750, Wayland starts working
again. The issue has something to do with GDM3's handling of a KMS-
enabled nouveau GPU, whether it is headless or not (no difference with
video=LVDS-2:d or not).
To confirm my suspicions that it is not specific to the macbook pro
line, this exact same issue (Xorg works wayland doesn't) also occurred
on a desktop dual-gpu setup, with a GTX 760 (kepler) on nouveau tandem
with a Haswell HD Graphics G3258-- with any combination of displays, all
on the Intel, mixed on nvidia and intel, or all on nvidia, as long as
both cards were modesetting, a black screen with cursor but blindly
working gnome followed.
This bug has existed since at least 19.04, if not earlier-- I replaced
the nvidia gpu in that system with a Radeon 7870 when it ran that
release due to this bug, as a matter of fact.
** Affects: gdm3 (Ubuntu)
Importance: Undecided
Status: New
** Tags: gdm3 kms nouveau.i915
** Description changed:
- MacBookPro6,2 with the infamous GT 330m and booting with the following
- grub manipulations to set gmux to the integrated LVDS:
+ MacBookPro6,2 with the infamous GT 330m on 20.04 with -proposed enabled
+ and booting with the following grub manipulations to set gmux to the
+ integrated LVDS:
outb 0x710 2 - switch LVDS to intel
outb 0x728 1 - switch internal DDC to intel
outb 0x740 2 - switch displayport out to intel
I am not using outb 0x750 0, so that the 330m remains powered on. It
still works just fine headless - I accomplished that by setting
video=LVDS-2:d (disabling the non-functioning LVDS link from the nvidia
to the internal screen).
*I tested with all these modifications disabled, and this still
occurred* - it's not specific to my configuration. A user booting stock
Ubuntu on this laptop, or as I discovered later, any nouveau + i915
hardware combination will run into this as well.
Anyways, I'm disabling the LVDS purely out of convenience so I can use
DRI_PRIME to run applications on the 330m for good reason- it supports
OpenGL 3.3 while HD Graphics (arrandale aka Ironlake) is the only HD
Graphics iGPU stuck on OpenGL 2.1, thus vastly restricting the modern
graphics workloads of the system.
When booting with gdm3 WaylandEnable=false (login and desktop both
xorg), everything works as expected - single screen driven by the i915's
KMS, headless nouveau with DRI_PRIME working, returning NVA5 stats and
functional with OpenGL 3 apps as well.
On GDM3 wayland, however (waylandenable=true), gdm3 starts to a black
screen with cursor. The login screen and shell still seem to be
running-- I can type my password blindly and press enter and the cursor
freezes briefly as it does during a non-broken login. After a few
seconds, I can press the volume up/down keys and I hear the volume
sound. Pressing the app grid shortcut makes the cursor lag, just as it
does when I disable the nvidia and rendering works on i915. Backlight
control also works on the login screen and once logged in. It's as if
everything except the actual rendering to the screen is working.
The minute I pass nouveau.modeset=0 in cmdline, Wayland starts working
again. The issue has something to do with GDM3's handling of a nouveau
GPU, whether it is headless or not (no difference with video=LVDS-2:d or
not).
This exact same issue (Xorg works wayland doesn't) also occurred on a
desktop dual-gpu setup, with a GTX 760 (kepler) on nouveau tandem with a
Haswell HD Graphics G3258-- with any combination of displays, all on the
Intel, mixed on nvidia and intel, or all on nvidia, as long as both
cards were modesetting, a black screen with cursor but blindly working
gnome followed.
** Description changed:
+ Any computer on i915 + nouveau with dual modesetting, my example is a
MacBookPro6,2 with the infamous GT 330m on 20.04 with -proposed enabled
and booting with the following grub manipulations to set gmux to the
integrated LVDS:
outb 0x710 2 - switch LVDS to intel
outb 0x728 1 - switch internal DDC to intel
outb 0x740 2 - switch displayport out to intel
I am not using outb 0x750 0, so that the 330m remains powered on. It
still works just fine headless - I accomplished that by setting
video=LVDS-2:d (disabling the non-functioning LVDS link from the nvidia
to the internal screen).
*I tested with all these modifications disabled, and this still
occurred* - it's not specific to my configuration. A user booting stock
Ubuntu on this laptop, or as I discovered later, any nouveau + i915
hardware combination will run into this as well.
Anyways, I'm disabling the LVDS purely out of convenience so I can use
DRI_PRIME to run applications on the 330m for good reason- it supports
OpenGL 3.3 while HD Graphics (arrandale aka Ironlake) is the only HD
Graphics iGPU stuck on OpenGL 2.1, thus vastly restricting the modern
graphics workloads of the system.
When booting with gdm3 WaylandEnable=false (login and desktop both
xorg), everything works as expected - single screen driven by the i915's
KMS, headless nouveau with DRI_PRIME working, returning NVA5 stats and
functional with OpenGL 3 apps as well.
On GDM3 wayland, however (waylandenable=true), gdm3 starts to a black
screen with cursor. The login screen and shell still seem to be
running-- I can type my password blindly and press enter and the cursor
freezes briefly as it does during a non-broken login. After a few
seconds, I can press the volume up/down keys and I hear the volume
sound. Pressing the app grid shortcut makes the cursor lag, just as it
does when I disable the nvidia and rendering works on i915. Backlight
control also works on the login screen and once logged in. It's as if
everything except the actual rendering to the screen is working.
The minute I pass nouveau.modeset=0 in cmdline, Wayland starts working
again. The issue has something to do with GDM3's handling of a nouveau
GPU, whether it is headless or not (no difference with video=LVDS-2:d or
not).
This exact same issue (Xorg works wayland doesn't) also occurred on a
desktop dual-gpu setup, with a GTX 760 (kepler) on nouveau tandem with a
Haswell HD Graphics G3258-- with any combination of displays, all on the
Intel, mixed on nvidia and intel, or all on nvidia, as long as both
cards were modesetting, a black screen with cursor but blindly working
gnome followed.
** Description changed:
Any computer on i915 + nouveau with dual modesetting, my example is a
MacBookPro6,2 with the infamous GT 330m on 20.04 with -proposed enabled
and booting with the following grub manipulations to set gmux to the
integrated LVDS:
outb 0x710 2 - switch LVDS to intel
outb 0x728 1 - switch internal DDC to intel
outb 0x740 2 - switch displayport out to intel
I am not using outb 0x750 0, so that the 330m remains powered on. It
- still works just fine headless - I accomplished that by setting
+ still works just fine blindly-- I accomplished that by setting
video=LVDS-2:d (disabling the non-functioning LVDS link from the nvidia
to the internal screen).
+
+ This mod is only for the convenience of not having to deal with a
+ phantom second screen once booted (both GPU's have the LVDS and edid of
+ the internal screen hooked up).
*I tested with all these modifications disabled, and this still
occurred* - it's not specific to my configuration. A user booting stock
Ubuntu on this laptop, or as I discovered later, any nouveau + i915
hardware combination will run into this as well.
Anyways, I'm disabling the LVDS purely out of convenience so I can use
DRI_PRIME to run applications on the 330m for good reason- it supports
OpenGL 3.3 while HD Graphics (arrandale aka Ironlake) is the only HD
Graphics iGPU stuck on OpenGL 2.1, thus vastly restricting the modern
graphics workloads of the system.
- When booting with gdm3 WaylandEnable=false (login and desktop both
- xorg), everything works as expected - single screen driven by the i915's
- KMS, headless nouveau with DRI_PRIME working, returning NVA5 stats and
- functional with OpenGL 3 apps as well.
+ When explicitly booting with gdm3 WaylandEnable=false (login and desktop
+ both xorg), everything works as expected - single screen driven by the
+ i915's KMS, headless nouveau with DRI_PRIME working, returning NVA5
+ stats and functional with OpenGL 3 apps as well.
- On GDM3 wayland, however (waylandenable=true), gdm3 starts to a black
- screen with cursor. The login screen and shell still seem to be
- running-- I can type my password blindly and press enter and the cursor
- freezes briefly as it does during a non-broken login. After a few
- seconds, I can press the volume up/down keys and I hear the volume
- sound. Pressing the app grid shortcut makes the cursor lag, just as it
- does when I disable the nvidia and rendering works on i915. Backlight
- control also works on the login screen and once logged in. It's as if
- everything except the actual rendering to the screen is working.
+ On GDM3 wayland, however (by default-- which is why I think this bug is
+ rather important), gdm3 starts to a black screen with cursor. The login
+ screen and shell still seem to be running-- I can type my password
+ blindly and press enter and the cursor freezes briefly as it does during
+ a non-broken login. After a few seconds, I can press the volume up/down
+ keys and I hear the volume sound. Pressing the app grid shortcut makes
+ the cursor lag, just as it does when I disable the nvidia and rendering
+ works on i915. Backlight control also works on the login screen and once
+ logged in. It's as if everything except the actual rendering to the
+ screen is working.
The minute I pass nouveau.modeset=0 in cmdline, Wayland starts working
again. The issue has something to do with GDM3's handling of a nouveau
GPU, whether it is headless or not (no difference with video=LVDS-2:d or
not).
This exact same issue (Xorg works wayland doesn't) also occurred on a
desktop dual-gpu setup, with a GTX 760 (kepler) on nouveau tandem with a
Haswell HD Graphics G3258-- with any combination of displays, all on the
Intel, mixed on nvidia and intel, or all on nvidia, as long as both
cards were modesetting, a black screen with cursor but blindly working
gnome followed.
** Description changed:
Any computer on i915 + nouveau with dual modesetting, my example is a
MacBookPro6,2 with the infamous GT 330m on 20.04 with -proposed enabled
and booting with the following grub manipulations to set gmux to the
integrated LVDS:
outb 0x710 2 - switch LVDS to intel
outb 0x728 1 - switch internal DDC to intel
outb 0x740 2 - switch displayport out to intel
I am not using outb 0x750 0, so that the 330m remains powered on. It
still works just fine blindly-- I accomplished that by setting
video=LVDS-2:d (disabling the non-functioning LVDS link from the nvidia
to the internal screen).
This mod is only for the convenience of not having to deal with a
phantom second screen once booted (both GPU's have the LVDS and edid of
the internal screen hooked up).
*I tested with all these modifications disabled, and this still
occurred* - it's not specific to my configuration. A user booting stock
Ubuntu on this laptop, or as I discovered later, any nouveau + i915
hardware combination will run into this as well.
Anyways, I'm disabling the LVDS purely out of convenience so I can use
DRI_PRIME to run applications on the 330m for good reason- it supports
OpenGL 3.3 while HD Graphics (arrandale aka Ironlake) is the only HD
Graphics iGPU stuck on OpenGL 2.1, thus vastly restricting the modern
graphics workloads of the system.
When explicitly booting with gdm3 WaylandEnable=false (login and desktop
both xorg), everything works as expected - single screen driven by the
i915's KMS, headless nouveau with DRI_PRIME working, returning NVA5
stats and functional with OpenGL 3 apps as well.
On GDM3 wayland, however (by default-- which is why I think this bug is
rather important), gdm3 starts to a black screen with cursor. The login
screen and shell still seem to be running-- I can type my password
blindly and press enter and the cursor freezes briefly as it does during
a non-broken login. After a few seconds, I can press the volume up/down
keys and I hear the volume sound. Pressing the app grid shortcut makes
- the cursor lag, just as it does when I disable the nvidia and rendering
- works on i915. Backlight control also works on the login screen and once
- logged in. It's as if everything except the actual rendering to the
- screen is working.
+ the cursor lag, just as it does when I disable the nvidia at the pcie
+ link level and rendering works on i915. Backlight control also works on
+ the login screen and once logged in. It's as if everything except the
+ actual rendering to the screen is working.
The minute I pass nouveau.modeset=0 in cmdline, Wayland starts working
again. The issue has something to do with GDM3's handling of a nouveau
GPU, whether it is headless or not (no difference with video=LVDS-2:d or
not).
This exact same issue (Xorg works wayland doesn't) also occurred on a
desktop dual-gpu setup, with a GTX 760 (kepler) on nouveau tandem with a
Haswell HD Graphics G3258-- with any combination of displays, all on the
Intel, mixed on nvidia and intel, or all on nvidia, as long as both
cards were modesetting, a black screen with cursor but blindly working
gnome followed.
** Description changed:
Any computer on i915 + nouveau with dual modesetting, my example is a
MacBookPro6,2 with the infamous GT 330m on 20.04 with -proposed enabled
and booting with the following grub manipulations to set gmux to the
integrated LVDS:
outb 0x710 2 - switch LVDS to intel
outb 0x728 1 - switch internal DDC to intel
outb 0x740 2 - switch displayport out to intel
I am not using outb 0x750 0, so that the 330m remains powered on. It
still works just fine blindly-- I accomplished that by setting
video=LVDS-2:d (disabling the non-functioning LVDS link from the nvidia
to the internal screen).
This mod is only for the convenience of not having to deal with a
phantom second screen once booted (both GPU's have the LVDS and edid of
the internal screen hooked up).
*I tested with all these modifications disabled, and this still
occurred* - it's not specific to my configuration. A user booting stock
Ubuntu on this laptop, or as I discovered later, any nouveau + i915
hardware combination will run into this as well.
Anyways, I'm disabling the LVDS purely out of convenience so I can use
DRI_PRIME to run applications on the 330m for good reason- it supports
OpenGL 3.3 while HD Graphics (arrandale aka Ironlake) is the only HD
Graphics iGPU stuck on OpenGL 2.1, thus vastly restricting the modern
graphics workloads of the system.
When explicitly booting with gdm3 WaylandEnable=false (login and desktop
both xorg), everything works as expected - single screen driven by the
i915's KMS, headless nouveau with DRI_PRIME working, returning NVA5
stats and functional with OpenGL 3 apps as well.
On GDM3 wayland, however (by default-- which is why I think this bug is
rather important), gdm3 starts to a black screen with cursor. The login
screen and shell still seem to be running-- I can type my password
blindly and press enter and the cursor freezes briefly as it does during
a non-broken login. After a few seconds, I can press the volume up/down
keys and I hear the volume sound. Pressing the app grid shortcut makes
the cursor lag, just as it does when I disable the nvidia at the pcie
link level and rendering works on i915. Backlight control also works on
the login screen and once logged in. It's as if everything except the
actual rendering to the screen is working.
- The minute I pass nouveau.modeset=0 in cmdline, Wayland starts working
- again. The issue has something to do with GDM3's handling of a nouveau
- GPU, whether it is headless or not (no difference with video=LVDS-2:d or
- not).
+ The minute I pass nouveau.modeset=0 in cmdline, or cut the power to the
+ 330m with outb 0x750, Wayland starts working again. The issue has
+ something to do with GDM3's handling of a nouveau GPU, whether it is
+ headless or not (no difference with video=LVDS-2:d or not).
This exact same issue (Xorg works wayland doesn't) also occurred on a
desktop dual-gpu setup, with a GTX 760 (kepler) on nouveau tandem with a
Haswell HD Graphics G3258-- with any combination of displays, all on the
Intel, mixed on nvidia and intel, or all on nvidia, as long as both
cards were modesetting, a black screen with cursor but blindly working
gnome followed.
** Description changed:
Any computer on i915 + nouveau with dual modesetting, my example is a
MacBookPro6,2 with the infamous GT 330m on 20.04 with -proposed enabled
and booting with the following grub manipulations to set gmux to the
integrated LVDS:
outb 0x710 2 - switch LVDS to intel
outb 0x728 1 - switch internal DDC to intel
outb 0x740 2 - switch displayport out to intel
I am not using outb 0x750 0, so that the 330m remains powered on. It
still works just fine blindly-- I accomplished that by setting
video=LVDS-2:d (disabling the non-functioning LVDS link from the nvidia
to the internal screen).
This mod is only for the convenience of not having to deal with a
phantom second screen once booted (both GPU's have the LVDS and edid of
the internal screen hooked up).
*I tested with all these modifications disabled, and this still
occurred* - it's not specific to my configuration. A user booting stock
Ubuntu on this laptop, or as I discovered later, any nouveau + i915
hardware combination will run into this as well.
Anyways, I'm disabling the LVDS purely out of convenience so I can use
DRI_PRIME to run applications on the 330m for good reason- it supports
OpenGL 3.3 while HD Graphics (arrandale aka Ironlake) is the only HD
Graphics iGPU stuck on OpenGL 2.1, thus vastly restricting the modern
graphics workloads of the system.
When explicitly booting with gdm3 WaylandEnable=false (login and desktop
both xorg), everything works as expected - single screen driven by the
i915's KMS, headless nouveau with DRI_PRIME working, returning NVA5
stats and functional with OpenGL 3 apps as well.
On GDM3 wayland, however (by default-- which is why I think this bug is
rather important), gdm3 starts to a black screen with cursor. The login
screen and shell still seem to be running-- I can type my password
blindly and press enter and the cursor freezes briefly as it does during
a non-broken login. After a few seconds, I can press the volume up/down
keys and I hear the volume sound. Pressing the app grid shortcut makes
the cursor lag, just as it does when I disable the nvidia at the pcie
link level and rendering works on i915. Backlight control also works on
the login screen and once logged in. It's as if everything except the
actual rendering to the screen is working.
The minute I pass nouveau.modeset=0 in cmdline, or cut the power to the
330m with outb 0x750, Wayland starts working again. The issue has
something to do with GDM3's handling of a nouveau GPU, whether it is
headless or not (no difference with video=LVDS-2:d or not).
- This exact same issue (Xorg works wayland doesn't) also occurred on a
- desktop dual-gpu setup, with a GTX 760 (kepler) on nouveau tandem with a
- Haswell HD Graphics G3258-- with any combination of displays, all on the
- Intel, mixed on nvidia and intel, or all on nvidia, as long as both
- cards were modesetting, a black screen with cursor but blindly working
- gnome followed.
+ To confirm my suspicions that it is not specific to the macbook pro
+ line, this exact same issue (Xorg works wayland doesn't) also occurred
+ on a desktop dual-gpu setup, with a GTX 760 (kepler) on nouveau tandem
+ with a Haswell HD Graphics G3258-- with any combination of displays, all
+ on the Intel, mixed on nvidia and intel, or all on nvidia, as long as
+ both cards were modesetting, a black screen with cursor but blindly
+ working gnome followed.
** Description changed:
- Any computer on i915 + nouveau with dual modesetting, my example is a
- MacBookPro6,2 with the infamous GT 330m on 20.04 with -proposed enabled
- and booting with the following grub manipulations to set gmux to the
- integrated LVDS:
+ This bug should be able to be reproduced on any computer with i915 +
+ nouveau simultaneously modesetting. My main example is a MacBookPro6,2
+ with the infamous GT 330m on 20.04 with -proposed enabled and booting
+ with the following grub manipulations to set gmux to the integrated
+ LVDS:
outb 0x710 2 - switch LVDS to intel
outb 0x728 1 - switch internal DDC to intel
outb 0x740 2 - switch displayport out to intel
I am not using outb 0x750 0, so that the 330m remains powered on. It
still works just fine blindly-- I accomplished that by setting
video=LVDS-2:d (disabling the non-functioning LVDS link from the nvidia
to the internal screen).
This mod is only for the convenience of not having to deal with a
phantom second screen once booted (both GPU's have the LVDS and edid of
the internal screen hooked up).
*I tested with all these modifications disabled, and this still
occurred* - it's not specific to my configuration. A user booting stock
Ubuntu on this laptop, or as I discovered later, any nouveau + i915
hardware combination will run into this as well.
Anyways, I'm disabling the LVDS purely out of convenience so I can use
DRI_PRIME to run applications on the 330m for good reason- it supports
OpenGL 3.3 while HD Graphics (arrandale aka Ironlake) is the only HD
Graphics iGPU stuck on OpenGL 2.1, thus vastly restricting the modern
graphics workloads of the system.
When explicitly booting with gdm3 WaylandEnable=false (login and desktop
both xorg), everything works as expected - single screen driven by the
i915's KMS, headless nouveau with DRI_PRIME working, returning NVA5
stats and functional with OpenGL 3 apps as well.
On GDM3 wayland, however (by default-- which is why I think this bug is
rather important), gdm3 starts to a black screen with cursor. The login
screen and shell still seem to be running-- I can type my password
blindly and press enter and the cursor freezes briefly as it does during
a non-broken login. After a few seconds, I can press the volume up/down
keys and I hear the volume sound. Pressing the app grid shortcut makes
the cursor lag, just as it does when I disable the nvidia at the pcie
link level and rendering works on i915. Backlight control also works on
the login screen and once logged in. It's as if everything except the
actual rendering to the screen is working.
The minute I pass nouveau.modeset=0 in cmdline, or cut the power to the
330m with outb 0x750, Wayland starts working again. The issue has
something to do with GDM3's handling of a nouveau GPU, whether it is
headless or not (no difference with video=LVDS-2:d or not).
To confirm my suspicions that it is not specific to the macbook pro
line, this exact same issue (Xorg works wayland doesn't) also occurred
on a desktop dual-gpu setup, with a GTX 760 (kepler) on nouveau tandem
with a Haswell HD Graphics G3258-- with any combination of displays, all
on the Intel, mixed on nvidia and intel, or all on nvidia, as long as
both cards were modesetting, a black screen with cursor but blindly
working gnome followed.
** Description changed:
This bug should be able to be reproduced on any computer with i915 +
nouveau simultaneously modesetting. My main example is a MacBookPro6,2
with the infamous GT 330m on 20.04 with -proposed enabled and booting
with the following grub manipulations to set gmux to the integrated
LVDS:
outb 0x710 2 - switch LVDS to intel
outb 0x728 1 - switch internal DDC to intel
outb 0x740 2 - switch displayport out to intel
I am not using outb 0x750 0, so that the 330m remains powered on. It
- still works just fine blindly-- I accomplished that by setting
- video=LVDS-2:d (disabling the non-functioning LVDS link from the nvidia
- to the internal screen).
+ still works just fine-- the only thing broken is the LVDS connection to
+ the internal panel. I disable it with video=LVDS-2:d.
- This mod is only for the convenience of not having to deal with a
- phantom second screen once booted (both GPU's have the LVDS and edid of
- the internal screen hooked up).
+ --> NOTE: This mod is only for the convenience of not having to deal
+ with a phantom second screen once booted (both GPU's have the LVDS and
+ edid of the internal screen hooked up). It boots fine without disabling
+ the 330m's LVDS.
- *I tested with all these modifications disabled, and this still
- occurred* - it's not specific to my configuration. A user booting stock
- Ubuntu on this laptop, or as I discovered later, any nouveau + i915
- hardware combination will run into this as well.
+ I tested with all these modifications disabled, and this still occurred
+ - it's not specific to my configuration. A user booting stock Ubuntu on
+ this laptop, or as I discovered later, any nouveau + i915 hardware
+ combination will run into this as well.
- Anyways, I'm disabling the LVDS purely out of convenience so I can use
- DRI_PRIME to run applications on the 330m for good reason- it supports
- OpenGL 3.3 while HD Graphics (arrandale aka Ironlake) is the only HD
- Graphics iGPU stuck on OpenGL 2.1, thus vastly restricting the modern
- graphics workloads of the system.
+ Anyways, I'm keeping the 330m enabled to use DRI_PRIME to run
+ applications on the 330m for good reason- it supports OpenGL 3.3 while
+ HD Graphics (arrandale aka Ironlake) is the only HD Graphics iGPU stuck
+ on OpenGL 2.1, thus otherwise vastly restricting the modern graphics
+ workloads of the system.
When explicitly booting with gdm3 WaylandEnable=false (login and desktop
both xorg), everything works as expected - single screen driven by the
- i915's KMS, headless nouveau with DRI_PRIME working, returning NVA5
- stats and functional with OpenGL 3 apps as well.
+ i915's KMS, nouveau with DRI_PRIME working, returning NVA5 stats and
+ functional with OpenGL 3 apps as well.
On GDM3 wayland, however (by default-- which is why I think this bug is
rather important), gdm3 starts to a black screen with cursor. The login
screen and shell still seem to be running-- I can type my password
blindly and press enter and the cursor freezes briefly as it does during
a non-broken login. After a few seconds, I can press the volume up/down
keys and I hear the volume sound. Pressing the app grid shortcut makes
the cursor lag, just as it does when I disable the nvidia at the pcie
link level and rendering works on i915. Backlight control also works on
the login screen and once logged in. It's as if everything except the
actual rendering to the screen is working.
The minute I pass nouveau.modeset=0 in cmdline, or cut the power to the
330m with outb 0x750, Wayland starts working again. The issue has
something to do with GDM3's handling of a nouveau GPU, whether it is
headless or not (no difference with video=LVDS-2:d or not).
To confirm my suspicions that it is not specific to the macbook pro
line, this exact same issue (Xorg works wayland doesn't) also occurred
on a desktop dual-gpu setup, with a GTX 760 (kepler) on nouveau tandem
with a Haswell HD Graphics G3258-- with any combination of displays, all
on the Intel, mixed on nvidia and intel, or all on nvidia, as long as
both cards were modesetting, a black screen with cursor but blindly
working gnome followed.
** Description changed:
This bug should be able to be reproduced on any computer with i915 +
nouveau simultaneously modesetting. My main example is a MacBookPro6,2
with the infamous GT 330m on 20.04 with -proposed enabled and booting
with the following grub manipulations to set gmux to the integrated
LVDS:
outb 0x710 2 - switch LVDS to intel
outb 0x728 1 - switch internal DDC to intel
outb 0x740 2 - switch displayport out to intel
I am not using outb 0x750 0, so that the 330m remains powered on. It
still works just fine-- the only thing broken is the LVDS connection to
the internal panel. I disable it with video=LVDS-2:d.
--> NOTE: This mod is only for the convenience of not having to deal
with a phantom second screen once booted (both GPU's have the LVDS and
- edid of the internal screen hooked up). It boots fine without disabling
- the 330m's LVDS.
+ edid of the internal screen hooked up). It boots fine and the bug
+ reproduces exactly the same without it.
I tested with all these modifications disabled, and this still occurred
- it's not specific to my configuration. A user booting stock Ubuntu on
this laptop, or as I discovered later, any nouveau + i915 hardware
combination will run into this as well.
Anyways, I'm keeping the 330m enabled to use DRI_PRIME to run
applications on the 330m for good reason- it supports OpenGL 3.3 while
HD Graphics (arrandale aka Ironlake) is the only HD Graphics iGPU stuck
on OpenGL 2.1, thus otherwise vastly restricting the modern graphics
workloads of the system.
When explicitly booting with gdm3 WaylandEnable=false (login and desktop
both xorg), everything works as expected - single screen driven by the
i915's KMS, nouveau with DRI_PRIME working, returning NVA5 stats and
functional with OpenGL 3 apps as well.
On GDM3 wayland, however (by default-- which is why I think this bug is
rather important), gdm3 starts to a black screen with cursor. The login
screen and shell still seem to be running-- I can type my password
blindly and press enter and the cursor freezes briefly as it does during
a non-broken login. After a few seconds, I can press the volume up/down
keys and I hear the volume sound. Pressing the app grid shortcut makes
the cursor lag, just as it does when I disable the nvidia at the pcie
link level and rendering works on i915. Backlight control also works on
the login screen and once logged in. It's as if everything except the
actual rendering to the screen is working.
The minute I pass nouveau.modeset=0 in cmdline, or cut the power to the
330m with outb 0x750, Wayland starts working again. The issue has
something to do with GDM3's handling of a nouveau GPU, whether it is
headless or not (no difference with video=LVDS-2:d or not).
To confirm my suspicions that it is not specific to the macbook pro
line, this exact same issue (Xorg works wayland doesn't) also occurred
on a desktop dual-gpu setup, with a GTX 760 (kepler) on nouveau tandem
with a Haswell HD Graphics G3258-- with any combination of displays, all
on the Intel, mixed on nvidia and intel, or all on nvidia, as long as
both cards were modesetting, a black screen with cursor but blindly
working gnome followed.
** Description changed:
This bug should be able to be reproduced on any computer with i915 +
nouveau simultaneously modesetting. My main example is a MacBookPro6,2
with the infamous GT 330m on 20.04 with -proposed enabled and booting
with the following grub manipulations to set gmux to the integrated
LVDS:
outb 0x710 2 - switch LVDS to intel
outb 0x728 1 - switch internal DDC to intel
outb 0x740 2 - switch displayport out to intel
I am not using outb 0x750 0, so that the 330m remains powered on. It
still works just fine-- the only thing broken is the LVDS connection to
the internal panel. I disable it with video=LVDS-2:d.
--> NOTE: This mod is only for the convenience of not having to deal
with a phantom second screen once booted (both GPU's have the LVDS and
edid of the internal screen hooked up). It boots fine and the bug
reproduces exactly the same without it.
I tested with all these modifications disabled, and this still occurred
- it's not specific to my configuration. A user booting stock Ubuntu on
this laptop, or as I discovered later, any nouveau + i915 hardware
combination will run into this as well.
Anyways, I'm keeping the 330m enabled to use DRI_PRIME to run
applications on the 330m for good reason- it supports OpenGL 3.3 while
HD Graphics (arrandale aka Ironlake) is the only HD Graphics iGPU stuck
on OpenGL 2.1, thus otherwise vastly restricting the modern graphics
workloads of the system.
When explicitly booting with gdm3 WaylandEnable=false (login and desktop
both xorg), everything works as expected - single screen driven by the
i915's KMS, nouveau with DRI_PRIME working, returning NVA5 stats and
functional with OpenGL 3 apps as well.
On GDM3 wayland, however (by default-- which is why I think this bug is
rather important), gdm3 starts to a black screen with cursor. The login
screen and shell still seem to be running-- I can type my password
blindly and press enter and the cursor freezes briefly as it does during
a non-broken login. After a few seconds, I can press the volume up/down
keys and I hear the volume sound. Pressing the app grid shortcut makes
the cursor lag, just as it does when I disable the nvidia at the pcie
link level and rendering works on i915. Backlight control also works on
the login screen and once logged in. It's as if everything except the
actual rendering to the screen is working.
The minute I pass nouveau.modeset=0 in cmdline, or cut the power to the
- 330m with outb 0x750, Wayland starts working again. The issue has
- something to do with GDM3's handling of a nouveau GPU, whether it is
- headless or not (no difference with video=LVDS-2:d or not).
+ 330m at the hardware level with outb 0x750, Wayland starts working
+ again. The issue has something to do with GDM3's handling of a KMS-
+ enabled nouveau GPU, whether it is headless or not (no difference with
+ video=LVDS-2:d or not).
To confirm my suspicions that it is not specific to the macbook pro
line, this exact same issue (Xorg works wayland doesn't) also occurred
on a desktop dual-gpu setup, with a GTX 760 (kepler) on nouveau tandem
with a Haswell HD Graphics G3258-- with any combination of displays, all
on the Intel, mixed on nvidia and intel, or all on nvidia, as long as
both cards were modesetting, a black screen with cursor but blindly
working gnome followed.
** Description changed:
This bug should be able to be reproduced on any computer with i915 +
nouveau simultaneously modesetting. My main example is a MacBookPro6,2
with the infamous GT 330m on 20.04 with -proposed enabled and booting
with the following grub manipulations to set gmux to the integrated
LVDS:
outb 0x710 2 - switch LVDS to intel
outb 0x728 1 - switch internal DDC to intel
outb 0x740 2 - switch displayport out to intel
I am not using outb 0x750 0, so that the 330m remains powered on. It
still works just fine-- the only thing broken is the LVDS connection to
the internal panel. I disable it with video=LVDS-2:d.
--> NOTE: This mod is only for the convenience of not having to deal
with a phantom second screen once booted (both GPU's have the LVDS and
edid of the internal screen hooked up). It boots fine and the bug
reproduces exactly the same without it.
I tested with all these modifications disabled, and this still occurred
- it's not specific to my configuration. A user booting stock Ubuntu on
this laptop, or as I discovered later, any nouveau + i915 hardware
combination will run into this as well.
Anyways, I'm keeping the 330m enabled to use DRI_PRIME to run
applications on the 330m for good reason- it supports OpenGL 3.3 while
HD Graphics (arrandale aka Ironlake) is the only HD Graphics iGPU stuck
on OpenGL 2.1, thus otherwise vastly restricting the modern graphics
workloads of the system.
When explicitly booting with gdm3 WaylandEnable=false (login and desktop
both xorg), everything works as expected - single screen driven by the
i915's KMS, nouveau with DRI_PRIME working, returning NVA5 stats and
functional with OpenGL 3 apps as well.
On GDM3 wayland, however (by default-- which is why I think this bug is
rather important), gdm3 starts to a black screen with cursor. The login
screen and shell still seem to be running-- I can type my password
blindly and press enter and the cursor freezes briefly as it does during
a non-broken login. After a few seconds, I can press the volume up/down
keys and I hear the volume sound. Pressing the app grid shortcut makes
the cursor lag, just as it does when I disable the nvidia at the pcie
link level and rendering works on i915. Backlight control also works on
the login screen and once logged in. It's as if everything except the
actual rendering to the screen is working.
The minute I pass nouveau.modeset=0 in cmdline, or cut the power to the
330m at the hardware level with outb 0x750, Wayland starts working
again. The issue has something to do with GDM3's handling of a KMS-
enabled nouveau GPU, whether it is headless or not (no difference with
video=LVDS-2:d or not).
To confirm my suspicions that it is not specific to the macbook pro
line, this exact same issue (Xorg works wayland doesn't) also occurred
on a desktop dual-gpu setup, with a GTX 760 (kepler) on nouveau tandem
with a Haswell HD Graphics G3258-- with any combination of displays, all
on the Intel, mixed on nvidia and intel, or all on nvidia, as long as
both cards were modesetting, a black screen with cursor but blindly
working gnome followed.
+
+ This bug has existed since at least 19.04, if not earlier-- I replaced
+ the nvidia gpu in that system with an RX 580 when it ran that release
+ due to this bug, as a matter of fact.
** Description changed:
This bug should be able to be reproduced on any computer with i915 +
- nouveau simultaneously modesetting. My main example is a MacBookPro6,2
- with the infamous GT 330m on 20.04 with -proposed enabled and booting
- with the following grub manipulations to set gmux to the integrated
- LVDS:
+ nouveau simultaneously modesetting, booting to stock gdm3 (wayland by
+ default). My main example is a MacBookPro6,2 with the infamous GT 330m
+ on 20.04 with -proposed enabled and booting with the following grub
+ manipulations to set gmux to the integrated LVDS:
outb 0x710 2 - switch LVDS to intel
outb 0x728 1 - switch internal DDC to intel
outb 0x740 2 - switch displayport out to intel
I am not using outb 0x750 0, so that the 330m remains powered on. It
still works just fine-- the only thing broken is the LVDS connection to
the internal panel. I disable it with video=LVDS-2:d.
--> NOTE: This mod is only for the convenience of not having to deal
with a phantom second screen once booted (both GPU's have the LVDS and
edid of the internal screen hooked up). It boots fine and the bug
reproduces exactly the same without it.
I tested with all these modifications disabled, and this still occurred
- it's not specific to my configuration. A user booting stock Ubuntu on
this laptop, or as I discovered later, any nouveau + i915 hardware
combination will run into this as well.
Anyways, I'm keeping the 330m enabled to use DRI_PRIME to run
applications on the 330m for good reason- it supports OpenGL 3.3 while
HD Graphics (arrandale aka Ironlake) is the only HD Graphics iGPU stuck
on OpenGL 2.1, thus otherwise vastly restricting the modern graphics
workloads of the system.
When explicitly booting with gdm3 WaylandEnable=false (login and desktop
both xorg), everything works as expected - single screen driven by the
i915's KMS, nouveau with DRI_PRIME working, returning NVA5 stats and
functional with OpenGL 3 apps as well.
On GDM3 wayland, however (by default-- which is why I think this bug is
rather important), gdm3 starts to a black screen with cursor. The login
screen and shell still seem to be running-- I can type my password
blindly and press enter and the cursor freezes briefly as it does during
a non-broken login. After a few seconds, I can press the volume up/down
keys and I hear the volume sound. Pressing the app grid shortcut makes
the cursor lag, just as it does when I disable the nvidia at the pcie
link level and rendering works on i915. Backlight control also works on
the login screen and once logged in. It's as if everything except the
actual rendering to the screen is working.
The minute I pass nouveau.modeset=0 in cmdline, or cut the power to the
330m at the hardware level with outb 0x750, Wayland starts working
again. The issue has something to do with GDM3's handling of a KMS-
enabled nouveau GPU, whether it is headless or not (no difference with
video=LVDS-2:d or not).
To confirm my suspicions that it is not specific to the macbook pro
line, this exact same issue (Xorg works wayland doesn't) also occurred
on a desktop dual-gpu setup, with a GTX 760 (kepler) on nouveau tandem
with a Haswell HD Graphics G3258-- with any combination of displays, all
on the Intel, mixed on nvidia and intel, or all on nvidia, as long as
both cards were modesetting, a black screen with cursor but blindly
working gnome followed.
This bug has existed since at least 19.04, if not earlier-- I replaced
the nvidia gpu in that system with an RX 580 when it ran that release
due to this bug, as a matter of fact.
** Description changed:
This bug should be able to be reproduced on any computer with i915 +
nouveau simultaneously modesetting, booting to stock gdm3 (wayland by
default). My main example is a MacBookPro6,2 with the infamous GT 330m
on 20.04 with -proposed enabled and booting with the following grub
manipulations to set gmux to the integrated LVDS:
outb 0x710 2 - switch LVDS to intel
outb 0x728 1 - switch internal DDC to intel
outb 0x740 2 - switch displayport out to intel
I am not using outb 0x750 0, so that the 330m remains powered on. It
still works just fine-- the only thing broken is the LVDS connection to
the internal panel. I disable it with video=LVDS-2:d.
--> NOTE: This mod is only for the convenience of not having to deal
with a phantom second screen once booted (both GPU's have the LVDS and
- edid of the internal screen hooked up). It boots fine and the bug
- reproduces exactly the same without it.
+ edid of the internal screen hooked up). The computer boots fine and the
+ bug reproduces exactly the same without it.
I tested with all these modifications disabled, and this still occurred
- it's not specific to my configuration. A user booting stock Ubuntu on
this laptop, or as I discovered later, any nouveau + i915 hardware
combination will run into this as well.
Anyways, I'm keeping the 330m enabled to use DRI_PRIME to run
applications on the 330m for good reason- it supports OpenGL 3.3 while
HD Graphics (arrandale aka Ironlake) is the only HD Graphics iGPU stuck
on OpenGL 2.1, thus otherwise vastly restricting the modern graphics
workloads of the system.
When explicitly booting with gdm3 WaylandEnable=false (login and desktop
both xorg), everything works as expected - single screen driven by the
i915's KMS, nouveau with DRI_PRIME working, returning NVA5 stats and
functional with OpenGL 3 apps as well.
On GDM3 wayland, however (by default-- which is why I think this bug is
rather important), gdm3 starts to a black screen with cursor. The login
screen and shell still seem to be running-- I can type my password
blindly and press enter and the cursor freezes briefly as it does during
a non-broken login. After a few seconds, I can press the volume up/down
keys and I hear the volume sound. Pressing the app grid shortcut makes
the cursor lag, just as it does when I disable the nvidia at the pcie
link level and rendering works on i915. Backlight control also works on
the login screen and once logged in. It's as if everything except the
actual rendering to the screen is working.
The minute I pass nouveau.modeset=0 in cmdline, or cut the power to the
330m at the hardware level with outb 0x750, Wayland starts working
again. The issue has something to do with GDM3's handling of a KMS-
enabled nouveau GPU, whether it is headless or not (no difference with
video=LVDS-2:d or not).
To confirm my suspicions that it is not specific to the macbook pro
line, this exact same issue (Xorg works wayland doesn't) also occurred
on a desktop dual-gpu setup, with a GTX 760 (kepler) on nouveau tandem
with a Haswell HD Graphics G3258-- with any combination of displays, all
on the Intel, mixed on nvidia and intel, or all on nvidia, as long as
both cards were modesetting, a black screen with cursor but blindly
working gnome followed.
This bug has existed since at least 19.04, if not earlier-- I replaced
the nvidia gpu in that system with an RX 580 when it ran that release
due to this bug, as a matter of fact.
** Description changed:
This bug should be able to be reproduced on any computer with i915 +
nouveau simultaneously modesetting, booting to stock gdm3 (wayland by
default). My main example is a MacBookPro6,2 with the infamous GT 330m
on 20.04 with -proposed enabled and booting with the following grub
manipulations to set gmux to the integrated LVDS:
outb 0x710 2 - switch LVDS to intel
outb 0x728 1 - switch internal DDC to intel
outb 0x740 2 - switch displayport out to intel
I am not using outb 0x750 0, so that the 330m remains powered on. It
still works just fine-- the only thing broken is the LVDS connection to
the internal panel. I disable it with video=LVDS-2:d.
--> NOTE: This mod is only for the convenience of not having to deal
with a phantom second screen once booted (both GPU's have the LVDS and
edid of the internal screen hooked up). The computer boots fine and the
- bug reproduces exactly the same without it.
+ bug reproduces exactly the same with or without it.
I tested with all these modifications disabled, and this still occurred
- it's not specific to my configuration. A user booting stock Ubuntu on
this laptop, or as I discovered later, any nouveau + i915 hardware
combination will run into this as well.
Anyways, I'm keeping the 330m enabled to use DRI_PRIME to run
applications on the 330m for good reason- it supports OpenGL 3.3 while
HD Graphics (arrandale aka Ironlake) is the only HD Graphics iGPU stuck
on OpenGL 2.1, thus otherwise vastly restricting the modern graphics
workloads of the system.
When explicitly booting with gdm3 WaylandEnable=false (login and desktop
both xorg), everything works as expected - single screen driven by the
i915's KMS, nouveau with DRI_PRIME working, returning NVA5 stats and
functional with OpenGL 3 apps as well.
On GDM3 wayland, however (by default-- which is why I think this bug is
rather important), gdm3 starts to a black screen with cursor. The login
screen and shell still seem to be running-- I can type my password
blindly and press enter and the cursor freezes briefly as it does during
a non-broken login. After a few seconds, I can press the volume up/down
keys and I hear the volume sound. Pressing the app grid shortcut makes
the cursor lag, just as it does when I disable the nvidia at the pcie
link level and rendering works on i915. Backlight control also works on
the login screen and once logged in. It's as if everything except the
actual rendering to the screen is working.
The minute I pass nouveau.modeset=0 in cmdline, or cut the power to the
330m at the hardware level with outb 0x750, Wayland starts working
again. The issue has something to do with GDM3's handling of a KMS-
enabled nouveau GPU, whether it is headless or not (no difference with
video=LVDS-2:d or not).
To confirm my suspicions that it is not specific to the macbook pro
line, this exact same issue (Xorg works wayland doesn't) also occurred
on a desktop dual-gpu setup, with a GTX 760 (kepler) on nouveau tandem
with a Haswell HD Graphics G3258-- with any combination of displays, all
on the Intel, mixed on nvidia and intel, or all on nvidia, as long as
both cards were modesetting, a black screen with cursor but blindly
working gnome followed.
This bug has existed since at least 19.04, if not earlier-- I replaced
the nvidia gpu in that system with an RX 580 when it ran that release
due to this bug, as a matter of fact.
** Description changed:
This bug should be able to be reproduced on any computer with i915 +
nouveau simultaneously modesetting, booting to stock gdm3 (wayland by
default). My main example is a MacBookPro6,2 with the infamous GT 330m
on 20.04 with -proposed enabled and booting with the following grub
manipulations to set gmux to the integrated LVDS:
outb 0x710 2 - switch LVDS to intel
outb 0x728 1 - switch internal DDC to intel
outb 0x740 2 - switch displayport out to intel
I am not using outb 0x750 0, so that the 330m remains powered on. It
still works just fine-- the only thing broken is the LVDS connection to
the internal panel. I disable it with video=LVDS-2:d.
--> NOTE: This mod is only for the convenience of not having to deal
with a phantom second screen once booted (both GPU's have the LVDS and
edid of the internal screen hooked up). The computer boots fine and the
bug reproduces exactly the same with or without it.
I tested with all these modifications disabled, and this still occurred
- it's not specific to my configuration. A user booting stock Ubuntu on
this laptop, or as I discovered later, any nouveau + i915 hardware
combination will run into this as well.
Anyways, I'm keeping the 330m enabled to use DRI_PRIME to run
applications on the 330m for good reason- it supports OpenGL 3.3 while
HD Graphics (arrandale aka Ironlake) is the only HD Graphics iGPU stuck
on OpenGL 2.1, thus otherwise vastly restricting the modern graphics
workloads of the system.
When explicitly booting with gdm3 WaylandEnable=false (login and desktop
both xorg), everything works as expected - single screen driven by the
i915's KMS, nouveau with DRI_PRIME working, returning NVA5 stats and
functional with OpenGL 3 apps as well.
On GDM3 wayland, however (by default-- which is why I think this bug is
rather important), gdm3 starts to a black screen with cursor. The login
screen and shell still seem to be running-- I can type my password
blindly and press enter and the cursor freezes briefly as it does during
a non-broken login. After a few seconds, I can press the volume up/down
keys and I hear the volume sound. Pressing the app grid shortcut makes
the cursor lag, just as it does when I disable the nvidia at the pcie
link level and rendering works on i915. Backlight control also works on
the login screen and once logged in. It's as if everything except the
actual rendering to the screen is working.
The minute I pass nouveau.modeset=0 in cmdline, or cut the power to the
330m at the hardware level with outb 0x750, Wayland starts working
again. The issue has something to do with GDM3's handling of a KMS-
enabled nouveau GPU, whether it is headless or not (no difference with
video=LVDS-2:d or not).
To confirm my suspicions that it is not specific to the macbook pro
line, this exact same issue (Xorg works wayland doesn't) also occurred
on a desktop dual-gpu setup, with a GTX 760 (kepler) on nouveau tandem
with a Haswell HD Graphics G3258-- with any combination of displays, all
on the Intel, mixed on nvidia and intel, or all on nvidia, as long as
both cards were modesetting, a black screen with cursor but blindly
working gnome followed.
This bug has existed since at least 19.04, if not earlier-- I replaced
- the nvidia gpu in that system with an RX 580 when it ran that release
- due to this bug, as a matter of fact.
+ the nvidia gpu in that system with a Radeon 7870 when it ran that
+ release due to this bug, as a matter of fact.
** Summary changed:
- wayland-only black screen with cursor on nouveau + i915
+ black screen with cursor and blind login working on nouveau + i915
** Summary changed:
- black screen with cursor and blind login working on nouveau + i915
+ black screen with cursor and on nouveau + i915
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gdm3 in Ubuntu.
https://bugs.launchpad.net/bugs/1873541
Title:
black screen with cursor and on nouveau + i915
Status in gdm3 package in Ubuntu:
New
Bug description:
This bug should be able to be reproduced on any computer with i915 +
nouveau simultaneously modesetting, booting to stock gdm3 (wayland by
default). My main example is a MacBookPro6,2 with the infamous GT 330m
on 20.04 with -proposed enabled and booting with the following grub
manipulations to set gmux to the integrated LVDS:
outb 0x710 2 - switch LVDS to intel
outb 0x728 1 - switch internal DDC to intel
outb 0x740 2 - switch displayport out to intel
I am not using outb 0x750 0, so that the 330m remains powered on. It
still works just fine-- the only thing broken is the LVDS connection
to the internal panel. I disable it with video=LVDS-2:d.
--> NOTE: This mod is only for the convenience of not having to deal
with a phantom second screen once booted (both GPU's have the LVDS and
edid of the internal screen hooked up). The computer boots fine and
the bug reproduces exactly the same with or without it.
I tested with all these modifications disabled, and this still
occurred - it's not specific to my configuration. A user booting stock
Ubuntu on this laptop, or as I discovered later, any nouveau + i915
hardware combination will run into this as well.
Anyways, I'm keeping the 330m enabled to use DRI_PRIME to run
applications on the 330m for good reason- it supports OpenGL 3.3 while
HD Graphics (arrandale aka Ironlake) is the only HD Graphics iGPU
stuck on OpenGL 2.1, thus otherwise vastly restricting the modern
graphics workloads of the system.
When explicitly booting with gdm3 WaylandEnable=false (login and
desktop both xorg), everything works as expected - single screen
driven by the i915's KMS, nouveau with DRI_PRIME working, returning
NVA5 stats and functional with OpenGL 3 apps as well.
On GDM3 wayland, however (by default-- which is why I think this bug
is rather important), gdm3 starts to a black screen with cursor. The
login screen and shell still seem to be running-- I can type my
password blindly and press enter and the cursor freezes briefly as it
does during a non-broken login. After a few seconds, I can press the
volume up/down keys and I hear the volume sound. Pressing the app grid
shortcut makes the cursor lag, just as it does when I disable the
nvidia at the pcie link level and rendering works on i915. Backlight
control also works on the login screen and once logged in. It's as if
everything except the actual rendering to the screen is working.
The minute I pass nouveau.modeset=0 in cmdline, or cut the power to
the 330m at the hardware level with outb 0x750, Wayland starts working
again. The issue has something to do with GDM3's handling of a KMS-
enabled nouveau GPU, whether it is headless or not (no difference with
video=LVDS-2:d or not).
To confirm my suspicions that it is not specific to the macbook pro
line, this exact same issue (Xorg works wayland doesn't) also occurred
on a desktop dual-gpu setup, with a GTX 760 (kepler) on nouveau tandem
with a Haswell HD Graphics G3258-- with any combination of displays,
all on the Intel, mixed on nvidia and intel, or all on nvidia, as long
as both cards were modesetting, a black screen with cursor but blindly
working gnome followed.
This bug has existed since at least 19.04, if not earlier-- I replaced
the nvidia gpu in that system with a Radeon 7870 when it ran that
release due to this bug, as a matter of fact.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1873541/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
