X: how to *really* switch from nouveau to modesetting?

[D. R. Evans]

This is a follow-on to the thread that started with:
https://lists.debian.org/debian-user/2023/05/msg00657.html

Following the upgrade to bookworm that I recently performed, I was hoping that
the problem described in the first post in that thread would magically go
away. It didn't :-(

Felix suggested removing the nouveau driver and using "modesetting" as the
driver. I have removed the nouveau driver -- or at least I thought I did -- by
executing:
apt-get remove xserver-xorg-video-nouveau
which moved the packages:
xserver-xorg-video-nouveau
xserver-xorg-video-all

Upon rebooting into bookworm, though, I still see the original problem, as
described in the original post.

If I look to see what driver is being used:

----

[ZB:~] inxi -SGaz
System:
Kernel: 6.1.0-12-amd64 arch: x86_64 bits: 64 compiler: gcc v: 12.2.0
parameters: BOOT_IMAGE=/BOOT/debian@/vmlinuz-6.1.0-12-amd64
root=ZFS=/ROOT/debian ro root=ZFS=rpool/ROOT/debian
Desktop: Trinity info: kicker wm: Twin vt: 7 dm: LightDM v: 1.26.0
Distro: Debian GNU/Linux 12 (bookworm)
Graphics:
Device-1: NVIDIA GF108 [GeForce GT 430] vendor: Gigabyte driver: nouveau
v: kernel non-free: series: 390.xx+ status: legacy-active (EOL~late 2022)
arch: Fermi code: GF1xx process: 40/28nm built: 2010-16 pcie: gen: 1
speed: 2.5 GT/s lanes: 16 ports: active: HDMI-A-1 empty: DVI-I-1,VGA-1
bus-ID: 04:00.0 chip-ID: 10de:0de1 class-ID: 0300
Display: x11 server: X.Org v: 1.21.1.7 with: Xwayland v: 22.1.9 driver: X:
loaded: modesetting dri: nouveau gpu: nouveau display-ID: :0 screens: 1
Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x317mm (20.00x12.48")
s-diag: 599mm (23.57")
Monitor-1: HDMI-A-1 mapped: HDMI-1 model: VGA TO HDMI built: 2013
res: 1920x1080 hz: 60 dpi: 96 gamma: 1.2 size: 509x286mm (20.04x11.26")
diag: 584mm (23") ratio: 16:9 modes: max: 1920x1080 min: 640x480
API: OpenGL v: 4.3 Mesa 22.3.6 renderer: NVC1 direct-render: Yes
[ZB:~]

----

So the nouveau driver still seems to be available and in use, despite being
removed.

My xorg.conf file currently looks like this:

----

[ZB:~] cat /etc/X11/xorg.conf
Section "ServerLayout"
Identifier "X.org Configured"
Screen 0 "Screen0" 0 0
Screen 1 "Screen1" RightOf "Screen0"
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
ModulePath "/usr/lib/xorg/modules"
FontPath "/usr/share/fonts/X11/misc"
FontPath "/usr/share/fonts/X11/cyrillic"
FontPath "/usr/share/fonts/X11/100dpi/:unscaled"
FontPath "/usr/share/fonts/X11/75dpi/:unscaled"
FontPath "/usr/share/fonts/X11/Type1"
FontPath "/usr/share/fonts/X11/100dpi"
FontPath "/usr/share/fonts/X11/75dpi"
FontPath "built-ins"
EndSection

Section "Module"
Load "glx"

EndSection

Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
EndSection

Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/dev/input/mice"
Option "ZAxisMapping" "4 5 6 7"
EndSection

Section "Monitor"
Identifier "Monitor0"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
EndSection

Section "Monitor"
Identifier "Monitor1"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
EndSection




[54/136]
Section "Device"
### Available Driver options are:-
### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
### <string>: "String", <freq>: "<f> Hz/kHz/MHz",
### <percent>: "<f>%"
### [arg]: arg optional
#Option "SWcursor" # [<bool>]
#Option "HWcursor" # [<bool>]
#Option "NoAccel" # [<bool>]
#Option "ShadowFB" # [<bool>]
#Option "VideoKey" # <i>
#Option "WrappedFB" # [<bool>]
#Option "GLXVBlank" # [<bool>]
#Option "ZaphodHeads" # <str>
#Option "PageFlip" # [<bool>]
#Option "SwapLimit" # <i>
#Option "AsyncUTSDFS" # [<bool>]
#Option "AccelMethod" # <str>
#Option "DRI" # <i>
Identifier "Card0"
# Driver "nouveau"
Driver "modesetting"
BusID "PCI:4:0:0"
EndSection

Section "Device"
### Available Driver options are:-
### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
### <string>: "String", <freq>: "<f> Hz/kHz/MHz",
### <percent>: "<f>%"
### [arg]: arg optional
#Option "SWcursor" # [<bool>]
#Option "kmsdev" # <str>
#Option "ShadowFB" # [<bool>]
#Option "AccelMethod" # <str>
#Option "PageFlip" # [<bool>]
#Option "ZaphodHeads" # <str>
#Option "DoubleShadow" # [<bool>]
Identifier "Card1"
Driver "modesetting"
BusID "PCI:0:2:0"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"
SubSection "Display"
Viewport 0 0
Depth 1
Modes "1920x1200"
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 4
Modes "1920x1200"
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 8
Modes "1920x1200"
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 15
Modes "1920x1200"
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 16
Modes "1920x1200"
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 24
Modes "1920x1200"
EndSubSection
EndSection

Section "Screen"
Identifier "Screen1"
Device "Card1"
Monitor "Monitor1"
SubSection "Display"
Viewport 0 0
Depth 1
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 4
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 8
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 15
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 16
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 24
EndSubSection
EndSection

----

And the file that Felix suggested I install,
/etc/X11/xorg.conf.d/50-device.conf, looks like this:

----

Section "Device"
Identifier "DDX"
Driver "modesetting"
# Driver "nouveau"
EndSection

----

The one obvious improvement after upgrading to bookworm is that my desktop
comes up correctly after setting the driver to "modesetting" in the xorg.conf
files, whereas in bullseye X would not start after executing the
apt-get remove xserver-xorg-video-nouveau
command. So that's good. But as the original problem of a tail appearing after
lines of text still remains, I haven't really made any progress :-(

Felix, if I understand what he said correctly, says that the "modesetting"
driver should work fine, so I think I need some more-precise instructions as
to how to ensure that the system comes up using that driver instead of nouveau.

Doc

--
Web: http://enginehousebooks.com/drevans

[Felix Miata]

You did it. You made the switch. But see below.....

(There are multiple components to GPU support in Linux.)
(There is no "the" nouveau "driver". Graphics support is in the hands of multiple
software components, several of which incorporate the string "nouveau" in naming.)

D. R. Evans composed on 2023-09-11 11:47 (UTC-0600):

> Graphics:
> Device-1: NVIDIA GF108 [GeForce GT 430] vendor: Gigabyte driver: nouveau

Above shows your kernel DEVICE driver is nouveau. It ships specifically for each
kernel with each kernel. For NVidia GPUs there is no other FOSS device driver
option for normal use with KMS enabled, which maximum possible FOSS performance
unconditionally requires. With KMS disabled, there is a crude generic option with
limited resolutions available that no one ever would use purposely unless too
naive to understand the opportunity loss. It's for fallback and troubleshooting
when normal is unavailable.

> v: kernel non-free: series: 390.xx+ status: legacy-active (EOL~late 2022)
> arch: Fermi code: GF1xx process: 40/28nm built: 2010-16 pcie: gen: 1
> speed: 2.5 GT/s lanes: 16 ports: active: HDMI-A-1 empty: DVI-I-1,VGA-1
> bus-ID: 04:00.0 chip-ID: 10de:0de1 class-ID: 0300
> Display: x11 server: X.Org v: 1.21.1.7 with: Xwayland v: 22.1.9 driver: X:
> loaded: modesetting dri: nouveau gpu: nouveau display-ID: :0 screens: 1

Above shows your loaded X DISPLAY driver is modesetting, the one & only competent
FOSS alternative to the nouveau that ships in xserver-xorg-video-nouveau.

The DRI driver is another nouveau, another piece of the graphics support puzzle,
another only option for competent FOSS NVidia GPU support.
# dpkg-query -W | grep nouveau
libdrm-nouveau2:amd64 2.4.114-1+b1 amd64 Userspace interface to nouveau-specific
kernel DRM services -- runtime
#
https://en.wikipedia.org/wiki/Direct_Rendering_Infrastructure

> My xorg.conf file currently looks like this:

You should have no /etc/X11/xorg.conf file. Proprietary NVidia drivers and
configurators normally make one. It's just something they do. For FOSS drivers,
/etc/X11/xorg.conf is an anachronism that remains occasionally useful. Any such
file created by NVidia installation or reconfiguration must be removed, or
severely edited, in order to revert from proprietary NVidia driver use to
FOSS-only use.

> And the file that Felix suggested I install,
> /etc/X11/xorg.conf.d/50-device.conf, looks like this:

> Section "Device"
> Identifier "DDX"
> Driver "modesetting"
> # Driver "nouveau"
> EndSection

That's a valid available option for overriding the selection Xorg would make on
its automagic own. Its existence overrides any conflicting equivalent in any
existing /etc/X11/xorg.conf. By having it it is normally not necessary to keep
xserver-xorg-video-nouveau uninstalled to keep X keeping the modesetting DIX
loaded instead of the nouveau DDX.

DIX: Device Independent X display driver (works with most GPUs regarless of brand)

DDX: Device Dependent X display driver (specific to one brand of GPU)
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

[D. R. Evans]

Felix Miata wrote on 9/11/23 19:57:

> You did it. You made the switch. But see below.....
>
> (There are multiple components to GPU support in Linux.)
> (There is no "the" nouveau "driver". Graphics support is in the hands of multiple
> software components, several of which incorporate the string "nouveau" in naming.)
>

I'm glad that you understand this stuff. It certainly seems non-obvious. And
the days of good O'Reilly books that walk one through details like this seem
to be long gone :-(

From the rest of your post, it sounds like everything is as it should be,
except that I should probably remove the /etc/X11/xorg.conf file. And I could
also re-install the xserver-xorg-video-nouveau without effecting any change;
but for now I think I'll just keep things as they are and just note these as
possible changes to try sometime, with the expectation that they won't make
any practical difference, but might make the system a bit cleaner to administer.

And, from what you say here:

> D. R. Evans composed on 2023-09-11 11:47 (UTC-0600):
>
>> Graphics:
>> Device-1: NVIDIA GF108 [GeForce GT 430] vendor: Gigabyte driver: nouveau
>
> Above shows your kernel DEVICE driver is nouveau. It ships specifically for
each
> kernel with each kernel. For NVidia GPUs there is no other FOSS device driver
> option for normal use with KMS enabled, which maximum possible FOSS performance
> unconditionally requires. With KMS disabled, there is a crude generic
option with
> limited resolutions available that no one ever would use purposely unless too
> naive to understand the opportunity loss. It's for fallback and troubleshooting
> when normal is unavailable.

it sounds like the issue must be in the nouveau kernel device driver, and
there's nothing I can really do to change that.

So I guess I will just wait and hope that some future update removes the problem.

⁂

Just for the record, to provide some context for anyone finding this thread as
a result of a search:

1. The issue is that black-on-white text has a "tail" extending some distance
on the right of the text (I don't know how to describe it any better than that).

2. It began with a normal bullseye update. Before that, there was no problem
at all.

3. Every update and upgrade since then has exhibited the problem.

4. The monitor is KVM-switchable to another bookworm installation, which does
not (and never has) exhibited the problem.

[Felix Miata]

D. R. Evans composed on 2023-09-12 11:12 (UTC-0600):

> Felix Miata wrote:

> From the rest of your post, it sounds like everything is as it should be,
> except that I should probably remove the /etc/X11/xorg.conf file. And I could
> also re-install the xserver-xorg-video-nouveau without effecting any change;
> but for now I think I'll just keep things as they are and just note these as
> possible changes to try sometime, with the expectation that they won't make
> any practical difference, but might make the system a bit cleaner to administer.

You really should eliminate that xorg.conf file, and if the problem continues,
don't assume it's the kernel driver at fault. Just report a bug if so inclined.
Where would depend on behavior after removing xorg.conf. If it fixes the problem,
there is almost assuredly no bug anywhere at all affecting you. If with
modesetting it's gone, but with xserver-xorg-video-nouveau installed and in use it
remains, then it would be good to report a nouveau DDX bug, though the problem
could be DRI or Mesa. Unreported bugs can go a very long time before a fix occurs,
if ever. What you are now experiencing is not acceptable behavior. 13 years of age
is too young to accept FOSS performance degradation or need GPU upgrade.

[D. R. Evans]

Felix Miata wrote on 9/12/23 11:51:

>
> You really should eliminate that xorg.conf file, and if the problem continues,
> don't assume it's the kernel driver at fault. Just report a bug if so inclined.
> Where would depend on behavior after removing xorg.conf. If it fixes the problem,
> there is almost assuredly no bug anywhere at all affecting you. If with
> modesetting it's gone, but with xserver-xorg-video-nouveau installed and in use it
> remains, then it would be good to report a nouveau DDX bug, though the problem
> could be DRI or Mesa. Unreported bugs can go a very long time before a fix occurs,
> if ever. What you are now experiencing is not acceptable behavior. 13 years of age
> is too young to accept FOSS performance degradation or need GPU upgrade.

I have removed /etc/X11/xorg.conf, and the problem remains.

So in this case, where should I report the issue?

[Felix Miata]

D. R. Evans composed on 2023-09-13 08:54 (UTC-0600):

> I have removed /etc/X11/xorg.conf, and the problem remains.

> So in this case, where should I report the issue?

Follow the instructions on https://www.debian.org/Bugs/Reporting and be sure to
include when the problem began. I'd probably select Mesa as component, because
IIRC without rereading the whole pair of threads, it happens whether you're using
the modesetting DIX or nouveau DDX. Triagers can move it to DRM or kernel if they
think it better.

Do you have disk space available or a different disk for installing Bookworm?
There's no way to predict when such a bug will get attention or fixed. Developers
usually need repeatable reproduction scenarios in order to determine what broke.