Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

video issue following latest bullseye update

25 views
Skip to first unread message

D. R. Evans

unread,
May 15, 2023, 11:51:15 AM5/15/23
to
Following an update this morning to one of my bullseye systems, an irritating
video problem has surfaced. The best way I can think of to describe the
problem is that if one has a line of black text on what is supposed to be a
white background, to the right of the text a clear, short tail of even whiter
background is visible (the tail is maybe an inch or so long).

The update was to:
Linux 5.10.0-23-amd64 #1 SMP Debian 5.10.179-1 (2023-05-12) x86_64 GNU/Linux

I suspect that this is due to a driver issue related to the update. (I have
tried a couple of different desktops, KDE and TDE, but they both exhibit the
problem, so I don't think it can be caused by the desktop software. The
problem did not exist prior to this morning's update.)

So I'm wondering if someone can walk me through how to figure out what video
driver I am using, and what other drivers might be available to try?

Doc

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

Felix Miata

unread,
May 15, 2023, 1:20:08 PM5/15/23
to
D. R. Evans composed on 2023-05-15 09:49 (UTC-0600):

> I'm wondering if someone can walk me through how to figure out what video
> driver I am using, and what other drivers might be available to try?

Not without knowing anything about your GPU:

sudo sed -i 'a/^B_ALLOW_UPDATE/#B_ALLOW_UPDATE/g' /etc/inxi.conf # just doit
inxi -SGaz # paste into your reply
cat /var/log/Xorg.0.log | pastebinit # provide resulting URL in reply
--
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

unread,
May 15, 2023, 3:00:06 PM5/15/23
to
Felix Miata wrote on 5/15/23 11:16:
> D. R. Evans composed on 2023-05-15 09:49 (UTC-0600):
>
>> I'm wondering if someone can walk me through how to figure out what video
>> driver I am using, and what other drivers might be available to try?
>
> Not without knowing anything about your GPU:

Yes, I figured that that would be the first step; I didn't know how to do that
either, so thanks for taking my "walk me through" request seriously.

>
> sudo sed -i 'a/^B_ALLOW_UPDATE/#B_ALLOW_UPDATE/g' /etc/inxi.conf # just doit
> inxi -SGaz # paste into your reply

----

[ZB:tmp] inxi -SGaz
System: Kernel: 5.10.0-23-amd64 x86_64 bits: 64 compiler: gcc v: 10.2.1
parameters: BOOT_IMAGE=/BOOT/debian@/vmlinuz-5.10.0-23-amd64
root=ZFS=/ROOT/debian ro root=ZFS=rpool/ROOT/debian
Desktop: Trinity info: kicker wm: Twin dm: LightDM 1.26.0 Distro:
Debian GNU/Linux 11 (bullseye)
Graphics: Device-1: NVIDIA GF108 [GeForce GT 430] vendor: Gigabyte driver:
nouveau v: kernel bus ID: 04:00.0
chip ID: 10de:0de1 class ID: 0300
Display: x11 server: X.Org 1.20.11 driver: loaded: nouveau
unloaded: modesetting display ID: :0 screens: 1
Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm
(20.0x11.2") s-diag: 582mm (22.9")
Monitor-1: HDMI-1 res: 1920x1080 hz: 60 dpi: 96 size: 509x286mm
(20.0x11.3") diag: 584mm (23")
OpenGL: renderer: NVC1 v: 4.3 Mesa 20.3.5 direct render: Yes
[ZB:tmp]

----

FYI, the actual physical size of the monitor is quite a lot larger than the
23" reported in the output above. I don't suppose that that matters, but I
noticed that the numbers are wrong, so I thought I'd better mention it. The
actual diagonal size of the monitor is ~32".

> cat /var/log/Xorg.0.log | pastebinit # provide resulting URL in reply

https://paste.debian.net/1280303/

Thank you.

Felix Miata

unread,
May 15, 2023, 3:30:07 PM5/15/23
to
D. R. Evans composed on 2023-05-15 12:50 (UTC-0600):

> Felix Miata wrote on 5/15/23 11:16:

>> D. R. Evans composed on 2023-05-15 09:49 (UTC-0600):

>>> I'm wondering if someone can walk me through how to figure out what video
>>> driver I am using, and what other drivers might be available to try?

>> Not without knowing anything about your GPU:

> Yes, I figured that that would be the first step; I didn't know how to do that
> either, so thanks for taking my "walk me through" request seriously.

>> sudo sed -i 'a/^B_ALLOW_UPDATE/#B_ALLOW_UPDATE/g' /etc/inxi.conf # just doit

The object was to disable Debian's disabling of internal inxi update mechanism,
and I forgot to tell you to use it as step 2:

inxi -U

Current upstream version is 3.3.27. Bullseye's is ancient, lacking, and quite
broken in inxi parlance.

>> inxi -SGaz # paste into your reply

> [ZB:tmp] inxi -SGaz
> System: Kernel: 5.10.0-23-amd64 x86_64 bits: 64 compiler: gcc v: 10.2.1
> parameters: BOOT_IMAGE=/BOOT/debian@/vmlinuz-5.10.0-23-amd64
> root=ZFS=/ROOT/debian ro root=ZFS=rpool/ROOT/debian
> Desktop: Trinity info: kicker wm: Twin dm: LightDM 1.26.0 Distro:
> Debian GNU/Linux 11 (bullseye)
> Graphics: Device-1: NVIDIA GF108 [GeForce GT 430] vendor: Gigabyte driver:
> nouveau v: kernel bus ID: 04:00.0
> chip ID: 10de:0de1 class ID: 0300
> Display: x11 server: X.Org 1.20.11 driver: loaded: nouveau
> unloaded: modesetting display ID: :0 screens: 1
> Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm
> (20.0x11.2") s-diag: 582mm (22.9")
> Monitor-1: HDMI-1 res: 1920x1080 hz: 60 dpi: 96 size: 509x286mm
> (20.0x11.3") diag: 584mm (23")
> OpenGL: renderer: NVC1 v: 4.3 Mesa 20.3.5 direct render: Yes
> [ZB:tmp]

Thus, expected info is missing, and too long lines wrapped.

> FYI, the actual physical size of the monitor is quite a lot larger than the
> 23" reported in the output above. I don't suppose that that matters, but I
> noticed that the numbers are wrong, so I thought I'd better mention it. The
> actual diagonal size of the monitor is ~32".

15 or more years years ago, Xorg was reconfigured to lie about DPI and screen
size. It forces DPI to 96 regardless of actual screen dimensions, and shows the
actual physical dimensions required to produce 96 DPI. If you wish actual DPI
used, or any arbitrary DPI, it must be forced through xrandr or /etc/X11/xorg.con*.

>> cat /var/log/Xorg.0.log | pastebinit # provide resulting URL in reply

> https://paste.debian.net/1280303/

Nothing obvious shows up in the log or your incomplete inxi output, except that
you have the exact same GPU as I have in a currently idle PC here, with TDE,
that's due for an update, so if what I suggest below doesn't help, I'll do that
this afternoon to see if it repros here.

Try using the (default) modesetting DIX display driver instead of Nouveau. Remove
package

xserver-xorg-video-nouveau

and reboot to see if it makes a difference. I use only the DIX for all of my
NVidia GPUs. It's so default it isn't separately packaged. :)

DIX: Device Independent X (display driver).
All other high competence display drivers are DDX, Device (brand/model) Dependent.

Timothy M Butterworth

unread,
May 15, 2023, 8:30:06 PM5/15/23
to
On Mon, May 15, 2023 at 11:49 AM D. R. Evans <doc....@gmail.com> wrote:
Following an update this morning to one of my bullseye systems, an irritating
video problem has surfaced. The best way I can think of to describe the
problem is that if one has a line of black text on what is supposed to be a
white background, to the right of the text a clear, short tail of even whiter
background is visible (the tail is maybe an inch or so long).

The update was to:
   Linux 5.10.0-23-amd64 #1 SMP Debian 5.10.179-1 (2023-05-12) x86_64 GNU/Linux

I suspect that this is due to a driver issue related to the update. (I have
tried a couple of different desktops, KDE and TDE, but they both exhibit the
problem, so I don't think it can be caused by the desktop software. The
problem did not exist prior to this morning's update.)

Try booting an older kernel version. You should have three kernels installed unless you manually removed all old kernels.
 

So I'm wondering if someone can walk me through how to figure out what video
driver I am using, and what other drivers might be available to try?

   Doc

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



--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

D. R. Evans

unread,
May 17, 2023, 12:20:06 PM5/17/23
to
Felix Miata wrote on 5/15/23 13:25:

>
> Try using the (default) modesetting DIX display driver instead of Nouveau. Remove
> package
>
> xserver-xorg-video-nouveau
>

Synaptic is telling me that this will also remove:
xserver-xorg-video-all

Is it OK that that will also be removed?

Felix Miata

unread,
May 17, 2023, 1:00:08 PM5/17/23
to
D. R. Evans composed on 2023-05-17 10:15 (UTC-0600):

> Felix Miata wrote:

>> Try using the (default) modesetting DIX display driver instead of Nouveau. Remove
>> package

>> xserver-xorg-video-nouveau

> Synaptic is telling me that this will also remove:
> xserver-xorg-video-all

> Is it OK that that will also be removed?

Yes. It's a meta-package responsible for littering your installation with every
existing GPU driver, mostly for GPUs that haven't been made in over two decades.

Felix Miata

unread,
May 18, 2023, 12:20:08 AM5/18/23
to
mick.crane composed on 2023-05-18 04:43 (UTC+0100):

> D. R. Evans wrote:
...
> I found my display worked better after running
> nvidia-detect/testing,now 525.105.17-1 amd64 [installed]
> NVIDIA GPU detection utility
> which told me which driver to install.

Did you read the whole thread? OP has:

Device-1: NVIDIA GF108 [GeForce GT 430] vendor: Gigabyte driver:
nouveau v: kernel bus ID: 04:00.0
chip ID: 10de:0de1 class ID: 0300

AFAICR, proprietary drivers are not supported with his Fermi GPU.

D. R. Evans

unread,
May 18, 2023, 4:21:55 PM5/18/23
to
Felix Miata wrote on 5/15/23 13:25:

> Try using the (default) modesetting DIX display driver instead of Nouveau. Remove
> package
>
> xserver-xorg-video-nouveau
>
> and reboot to see if it makes a difference.

I did this, and when I rebooted I was in the Linux console instead of Light DM
(which is my display manager). Hitting ctrl-alt-F7 to go to the X screen did
not show me the LDM login screen, or any other X screen, but instead another
non-graphical screen.

I reinstalled xserver-xorg-video-nouveau from the console, and (fortunately)
when I rebooted LDM came up as usual and I was able to log in as I normally
do. Obviously, the original issue still exists, but at least I got a graphical
display back.

Felix Miata

unread,
May 19, 2023, 1:30:07 PM5/19/23
to
D. R. Evans composed on 2023-05-18 14:17 (UTC-0600):

> Felix Miata wrote:

>> Try using the (default) modesetting DIX display driver instead of Nouveau. Remove
>> package

>> xserver-xorg-video-nouveau

>> and reboot to see if it makes a difference.

> I did this, and when I rebooted I was in the Linux console instead of Light DM
> (which is my display manager). Hitting ctrl-alt-F7 to go to the X screen did
> not show me the LDM login screen, or any other X screen, but instead another
> non-graphical screen.

How much time did you allow the login screen to show up? I've lately seen on
various hardware of various ages a need to restart the DM after booting because it
fails to come up before something times out. When it happens, either from
Ctrl-Alt-F[2-6] login or remote login, running

systemctl restart <dmname>

will bring it up like it normally should have.

> I reinstalled xserver-xorg-video-nouveau from the console, and (fortunately)
> when I rebooted LDM came up as usual and I was able to log in as I normally
> do. Obviously, the original issue still exists, but at least I got a graphical
> display back.

If by that you mean back to 640x480 or 800x600 instead of your display's native
resolution, please provide input/output from inxi -SGaz, and a fresh Xorg.0.log,
in the current condition. Please also provide Xorg.0.log from attempting to use
modesetting (having removed xserver-xorg-video-nouveau; or [1]) instead of nouveau
display driver.

[1] Instead of driver removal/reinstallation, create file, or add following
content to existing file:

/etc/X11/xorg.conf.d/50-device.conf

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

By simply moving the # to the other driver line, you can easily switch between
using the two display drivers by restarting your DM or rebooting.

My GF108 simply works, with the modesetting DIX, and two displays:
# inxi -GSaz --vs --zl --hostname
inxi 3.3.27-00 (2023-05-07)
System:
Host: gb970 Kernel: 5.10.0-23-amd64 arch: x86_64 bits: 64 compiler: gcc
v: 10.2.1 parameters: root=LABEL=<filter> ipv6.disable=1 net.ifnames=0
plymouth.enable=0 noresume consoleblank=0 mitigations=none preempt=full
Desktop: Trinity v: R14.1.0 tk: Qt v: 3.5.0 info: kicker wm: Twin v: 3.0
vt: 7 dm: 1: TDM 2: XDM Distro: Debian GNU/Linux 11 (bullseye)
Graphics:
Device-1: NVIDIA GF108 [GeForce GT 630] 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: DVI-I-1,HDMI-A-1 empty: VGA-1
bus-ID: 01:00.0 chip-ID: 10de:0f00 class-ID: 0300 temp: 42.0 C
Display: x11 server: X.Org v: 1.20.11 driver: X: loaded: modesetting
dri: nouveau gpu: nouveau display-ID: :0 screens: 1
Screen-1: 0 s-res: 3600x1200 s-dpi: 120 s-size: 762x254mm (30.00x10.00")
s-diag: 803mm (31.62")
Monitor-1: DVI-I-1 pos: right model: Dell P2213 serial: <filter>
built: 2012 res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2
size: 473x296mm (18.62x11.65") diag: 558mm (22") ratio: 16:10 modes:
max: 1680x1050 min: 720x400
Monitor-2: HDMI-A-1 mapped: HDMI-1 pos: primary,left model: NEC EA243WM
serial: <filter> built: 2011 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2
size: 519x324mm (20.43x12.76") diag: 612mm (24.1") ratio: 16:10 modes:
max: 1920x1200 min: 640x480
API: OpenGL v: 4.3 Mesa 20.3.5 renderer: NVC1 direct-render: Yes
#

D. R. Evans

unread,
May 22, 2023, 4:41:10 PM5/22/23
to
Felix Miata wrote on 5/19/23 11:23:

>
> How much time did you allow the login screen to show up? I've lately seen on

Somewhere between three and five minutes, I'd say. Certainly long after the
disk light stopped flickering and the system seemed to have reached a stable
state.

>
> systemctl restart <dmname>

OK; so that would be:
systemctl restart lightdm
Useful to know; thank you.

>
>> I reinstalled xserver-xorg-video-nouveau from the console, and (fortunately)
>> when I rebooted LDM came up as usual and I was able to log in as I normally
>> do. Obviously, the original issue still exists, but at least I got a graphical
>> display back.
>
> If by that you mean back to 640x480 or 800x600 instead of your display's native

No; I didn't mean that. Sorry I wasn't clear. I meant that after reinstalling
xserver-xorg-video-nouveau and rebooting, everything looked the way it did
before I removed xserver-xorg-video-nouveau, so I was back exactly to what I
was seeing when I first started this thread.

>
> [1] Instead of driver removal/reinstallation, create file, or add following
> content to existing file:
>
> /etc/X11/xorg.conf.d/50-device.conf
>
> Section "Device"
> Identifier "DDX"
> Driver "modesetting"
> # Driver "nouveau"
> EndSection
>

I have created that file, with those contents:

----

[ZB:~] cat /etc/X11/xorg.conf.d/50-device.conf
Section "Device"
Identifier "DDX"
Driver "modesetting"
# Driver "nouveau"
EndSection
[ZB:~]

----

Do you really mean "DDX", not "DIX"? <--------

I made the edit according to your instructions (i.e., "DDX") but I'm not
certain that your e-mail didn't contain a typo.

> By simply moving the # to the other driver line, you can easily switch between
> using the two display drivers by restarting your DM or rebooting.
Right now, the 50-device.conf file looks exactly as it does above but, and I
have restarted lightdm by issuing:
systemctl restart lightdm
from the console.

I currently get:

----

[ZB:~] sudo inxi -GSaz
System: Kernel: 5.10.0-23-amd64 x86_64 bits: 64 compiler: gcc v: 10.2.1
parameters: BOOT_IMAGE=/BOOT/debian@/vmlinuz-5.10.0-23-amd64
root=ZFS=/ROOT/debian ro root=ZFS=rpool/ROOT/debian
Desktop: Trinity R14.1.1~[DEVELOPMENT] tk: Qt 3.5.0 info: kicker
wm: Twin 3.0 dm: LightDM 1.26.0
Distro: Debian GNU/Linux 11 (bullseye)
Graphics: Device-1: NVIDIA GF108 [GeForce GT 430] vendor: Gigabyte driver:
nouveau v: kernel bus ID: 04:00.0
chip ID: 10de:0de1 class ID: 0300
Display: server: X.Org 1.20.11 driver: loaded: nouveau unloaded:
modesetting display ID: :0 screens: 1
Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm
(20.0x11.2") s-diag: 582mm (22.9")
Monitor-1: HDMI-1 res: 1920x1080 hz: 60 dpi: 96 size: 509x286mm
(20.0x11.3") diag: 584mm (23")
OpenGL: renderer: NVC1 v: 4.3 Mesa 20.3.5 direct render: Yes

----

But I am still seeing the original problem I reported.

[I also did a test, just to prove to myself that what I'm seeing isn't due to
some weird monitor problem (it's a pretty new monitor, and I wanted to be sure
that somehow I hadn't just missed seeing the problem before I performed the
update -- even though the issue is so obvious that I can't really believe that
I wouldn't have noticed it before). I took a screenshot of a screen display
that exhibited the problem (a konqueror file listing), and copied the file to
another system that is attached to the same KVM switch.

When I display the screenshot image in this, my normal desktop system, I see
the problem; when I look at the same image file on my other system -- which
has NOT had the recent update applied -- the problem is absent, even though
I'm viewing it on the very same monitor. So I am as sure as I can be that, as
I believed, the recent bullseye update led to the issue.]

Felix Miata

unread,
May 23, 2023, 3:41:47 PM5/23/23
to
D. R. Evans composed on 2023-05-22 14:39 (UTC-0600):

> Felix Miata wrote:

> [ZB:~] cat /etc/X11/xorg.conf.d/50-device.conf
> Section "Device"
> Identifier "DDX"
> Driver "modesetting"
> # Driver "nouveau"
> EndSection
> [ZB:~]

> Do you really mean "DDX", not "DIX"? <--------

> I made the edit according to your instructions (i.e., "DDX") but I'm not
> certain that your e-mail didn't contain a typo.

The quoted identifier line's string can be anything at all, unless using an
elaborate xorg.con* where another part needs to refer to a specific "Device"
section. Nouveau is a DDX (device dependent X/display driver). Modesetting is a
DIX (device independent X/display driver).

cf.
<https://forums.opensuse.org/t/amd-intel-nvidia-x-graphics-driver-primer-third-edition/148576>

>> By simply moving the # to the other driver line, you can easily switch between
>> using the two display drivers by restarting your DM or rebooting.
> Right now, the 50-device.conf file looks exactly as it does above but, and I
> have restarted lightdm by issuing:
> systemctl restart lightdm
> from the console.

> I currently get:

> [ZB:~] sudo inxi -GSaz
> System: Kernel: 5.10.0-23-amd64 x86_64 bits: 64 compiler: gcc v: 10.2.1
> parameters: BOOT_IMAGE=/BOOT/debian@/vmlinuz-5.10.0-23-amd64
> root=ZFS=/ROOT/debian ro root=ZFS=rpool/ROOT/debian
> Desktop: Trinity R14.1.1~[DEVELOPMENT] tk: Qt 3.5.0 info: kicker
> wm: Twin 3.0 dm: LightDM 1.26.0

The line wrapping suggests you never succeeded to do "inxi -U". As seen below,
newer (more complete) inxi versions by default limit to 80 columns, to prevent
such wrapping when pasting into emails and forum forms.

Are all users of ZFS supposed to include two root= parameters on their linu lines?

> But I am still seeing the original problem I reported.

Could it be that your PC doesn't like LightDM? Try switching to TDM. All my
Debians use it only. I also use TDM to run Plasma on Leap and Tumbleweed.

I switched from the modesetting DIX driver to the nouveau DDX driver via:

# cat /etc/X11/xorg.conf.d/15-ddxdrv.conf
#Section "OutputClass"
Section "Device"
Identifier "DDX"
# MatchDriver "amdgpu"
# Driver "amdgpu"
# MatchDriver "intel"
# Driver "intel"
# MatchDriver "modesetting"
# Driver "modesetting"
# MatchDriver "nouveau"
Driver "nouveau"
# MatchDriver "radeon"
# Driver "radeon"
EndSection

I was unable to detect any kind of video corruption in the TDE 14.1.x relnotes
window, or doing what follows in TDE's Konsole:

gb970:~ $ grep 'using VT' /var/log/Xorg.0.log
[ 239.391] (++) using VT number 7
gb970:~ $ lspci | grep VGA
01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [GeForce GT 630] (rev a1)
gb970:~ $ grep chipsets /var/log/Xorg.0.log | grep -vE 'VESA|FBDEV'
gb970:~ $ grep PRETTY /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
gb970:~ $ grep 'X.Org X Server' /var/log/Xorg.0.log
X.Org X Server 1.20.11
gb970:~ $ grep 'Current Operating System' /var/log/Xorg.0.log
[ 239.390] Current Operating System: Linux gb970 5.10.0-23-amd64 #1 SMP Debian
5.10.179-1 (2023-05-12) x86_64
gb970:~ $ grep 'Kernel Command Line' /var/log/Xorg.0.log
[ 239.390] Kernel command line: root=LABEL=40deb11 ipv6.disable=1 net.ifnames=0
plymouth.enable=0 noresume consoleblank=0 preempt=full mitigations=none
gb970:~ $ grep Output /var/log/Xorg.0.log | grep -vE 'disconnec|no monit' | grep
-v 'nitor sect'
[ 239.639] (II) NOUVEAU(0): Output DVI-I-1 connected
[ 239.639] (II) NOUVEAU(0): Output HDMI-1 connected
[ 239.639] (II) NOUVEAU(0): Output DVI-I-1 using initial mode 1680x1050 +0+0
[ 239.639] (II) NOUVEAU(0): Output HDMI-1 using initial mode 1920x1200 +1680+0
gb970:~ $ grep -iE "physical size|cm]" /var/log/Xorg.0.log
[ 239.561] (II) NOUVEAU(0): Max Image Size [cm]: horiz.: 47 vert.: 30
[ 239.628] (II) NOUVEAU(0): Max Image Size [cm]: horiz.: 52 vert.: 32
[ 239.785] (II) NOUVEAU(0): Setting screen physical size to 952 x 317
gb970:~ $ grep -v ^\# /etc/X11/xorg.conf.d/50-monitor.conf | grep DisplaySize
grep: /etc/X11/xorg.conf.d/50-monitor.conf: No such file or directory
gb970:~ $ grep -v ^\# /etc/X11/xorg.conf | grep DisplaySize
grep: /etc/X11/xorg.conf: No such file or directory
gb970:~ $ grep -v ^\# /etc/X11/xorg.conf.d/50-monitor.conf | grep PreferredMode
grep: /etc/X11/xorg.conf.d/50-monitor.conf: No such file or directory
gb970:~ $ grep -v ^\# /etc/X11/xorg.conf | grep PreferredMode
grep: /etc/X11/xorg.conf: No such file or directory
gb970:~ $ grep -v ^\# /etc/X11/Xsession.d/95setup | grep xrandr
xrandr --dpi 120
gb970:~ $ xrdb -query | grep dpi
gb970:~ $ xrandr | grep -E 'onnect|creen|\*' | grep -v disconn | sort -r
Screen 0: minimum 320 x 200, current 3600 x 1200, maximum 16384 x 16384
HDMI-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis)
519mm x 324mm
DVI-I-1 connected 1680x1050+1920+0 (normal left inverted right x axis y axis)
473mm x 296mm
1920x1200 59.95*+
1680x1050 59.95*+
gb970:~ $ xdpyinfo | grep -E 'dimen|ution'
dimensions: 3600x1200 pixels (762x254 millimeters)
resolution: 120x120 dots per inch
gb970:~ $ inxi -SGaz --vs --zl --hostname
inxi 3.3.27-00 (2023-05-07)
System:
Host: gb970 Kernel: 5.10.0-23-amd64 arch: x86_64 bits: 64 compiler: gcc
v: 10.2.1 parameters: root=LABEL=<filter> ipv6.disable=1 net.ifnames=0
plymouth.enable=0 noresume consoleblank=0 preempt=full mitigations=none
Desktop: Trinity v: R14.1.0 tk: Qt v: 3.5.0 info: kicker wm: Twin v: 3.0
vt: 7 dm: 1: TDM 2: XDM Distro: Debian GNU/Linux 11 (bullseye)
Graphics:
Device-1: NVIDIA GF108 [GeForce GT 630] 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: DVI-I-1,HDMI-A-1 empty: VGA-1
bus-ID: 01:00.0 chip-ID: 10de:0f00 class-ID: 0300 temp: 45.0 C
Display: x11 server: X.Org v: 1.20.11 driver: X: loaded: nouveau
dri: nouveau gpu: nouveau display-ID: :0 screens: 1
Screen-1: 0 s-res: 3600x1200 s-dpi: 120 s-size: 762x254mm (30.00x10.00")
s-diag: 803mm (31.62")
Monitor-1: DVI-I-1 pos: right model: Dell P2213 serial: <filter>
built: 2012 res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2
size: 473x296mm (18.62x11.65") diag: 558mm (22") ratio: 16:10 modes:
max: 1680x1050 min: 720x400
Monitor-2: HDMI-A-1 mapped: HDMI-1 pos: primary,left model: NEC EA243WM
serial: <filter> built: 2011 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2
size: 519x324mm (20.43x12.76") diag: 612mm (24.1") ratio: 16:10 modes:
max: 1920x1200 min: 640x480
API: OpenGL v: 4.3 Mesa 20.3.5 renderer: NVC1 direct-render: Yes
gb970:~ $

I suppose your issue could involve a timing coincidence, and your problem may be
failing gfxcard RAM.

The modesetting DIX is newer technology than the reverse-engineered,
"experimental" nouveau DDX. Whatever happened when you attempted switching to the
DIX should not have happened. Do you have /etc/X11/xorg.conf or any content in
/etc/X11/xorg.conf.d/ directed to gfx (device, monitor, screen, driver) other than
the file I suggested?

D. R. Evans

unread,
May 31, 2023, 1:50:06 PM5/31/23
to
I'm sorry I'm so slow to respond... it's all a matter of trying to put aside
quality uninterruptible time to work on this.

Since the problem is not so bad that I can't perform work with this computer,
a lot of other work-related things unfortunately have to take priority.

Felix Miata wrote on 5/23/23 13:26:

>
>> I currently get:
>
>> [ZB:~] sudo inxi -GSaz
>> System: Kernel: 5.10.0-23-amd64 x86_64 bits: 64 compiler: gcc v: 10.2.1
>> parameters: BOOT_IMAGE=/BOOT/debian@/vmlinuz-5.10.0-23-amd64
>> root=ZFS=/ROOT/debian ro root=ZFS=rpool/ROOT/debian
>> Desktop: Trinity R14.1.1~[DEVELOPMENT] tk: Qt 3.5.0 info: kicker
>> wm: Twin 3.0 dm: LightDM 1.26.0
>
> The line wrapping suggests you never succeeded to do "inxi -U". As seen below,

The officially supported version of inxi on bullseye [inxi 3.3.01-00
(2021-02-08), according to "inxi --version"] seems to have "-U" disabled.
Which I guess makes sense.

>
> Are all users of ZFS supposed to include two root= parameters on their linu lines?

What an excellent question. I don't know for sure, but I suspect that it's
related to the fact that I am running root-on-ZFS (i.e., the / filesystem is
on a ZFS disk). It's been like that for many years on this machine, and I
believe that when I first installed root-on-ZFS, the instructions told me to
do that. FWIW, I have another root-on-ZFS system, and it also has two "root="
parameters.

>
>> But I am still seeing the original problem I reported.
>
> Could it be that your PC doesn't like LightDM? Try switching to TDM. All my

TDM has never worked properly on this machine; TDM doesn't correctly figure
out which video card to use (at least, it didn't last time I tried it), so it
presents me with a black screen, leaving me having to ssh into the machine and
reconfigure it to use LightDM.

> Debians use it only. I also use TDM to run Plasma on Leap and Tumbleweed.
>
> I switched from the modesetting DIX driver to the nouveau DDX driver via:
>
> # cat /etc/X11/xorg.conf.d/15-ddxdrv.conf
> #Section "OutputClass"
> Section "Device"
> Identifier "DDX"
> # MatchDriver "amdgpu"
> # Driver "amdgpu"
> # MatchDriver "intel"
> # Driver "intel"
> # MatchDriver "modesetting"
> # Driver "modesetting"
> # MatchDriver "nouveau"
> Driver "nouveau"
> # MatchDriver "radeon"
> # Driver "radeon"
> EndSection
>
> I was unable to detect any kind of video corruption in the TDE 14.1.x relnotes
> window, or doing what follows in TDE's Konsole:

I don't think it can be a TDE issue, as the same problem exists on this
machine if I run the official KDE that is currently in bullseye.

>
> I suppose your issue could involve a timing coincidence, and your problem may be
> failing gfxcard RAM.

I suppose anything is possible. But since this began as soon as I applied a
bullseye update, it seems much more likely that it's a nouveau issue that
landed on this machine when I performed the update.

>
> The modesetting DIX is newer technology than the reverse-engineered,
> "experimental" nouveau DDX. Whatever happened when you attempted switching to the
> DIX should not have happened. Do you have /etc/X11/xorg.conf or any content in
> /etc/X11/xorg.conf.d/ directed to gfx (device, monitor, screen, driver) other than
> the file I suggested?

Here is xorg.conf (which I believe was auto-created at some point; I have no
notes that say that I created it):

[ZB:X11] cat xorg.conf | pastebinit
https://paste.debian.net/1281598/
[ZB:X11]

And /etc/X11/xorg.conf.d/ just contains the file you suggested (currently set
to nouveau):

----

[ZB:xorg.conf.d] ls -al
total 11
drwxr-xr-x 2 root root 3 May 22 14:46 .
drwxr-xr-x 14 root root 25 Nov 9 2021 ..
-rw-r--r-- 1 root root 88 May 22 14:46 50-device.conf
[ZB:xorg.conf.d] cat *
Section "Device"
Identifier "DDX"
# Driver "modesetting"
Driver "nouveau"
EndSection
[ZB:xorg.conf.d]

----

Felix Miata

unread,
Sep 11, 2023, 10:30:06 PM9/11/23
to
D. R. Evans composed on 2023-05-22 14:39 (UTC-0600):

> Do you really mean "DDX", not "DIX"? <--------

> I made the edit according to your instructions (i.e., "DDX") but I'm not
> certain that your e-mail didn't contain a typo.

My first thread post did have a bad one:

sudo sed -i 'a/^B_ALLOW_UPDATE/#B_ALLOW_UPDATE/g' /etc/inxi.conf

was supposed to read

sudo sed -i 's/^B_ALLOW_UPDATE/#B_ALLOW_UPDATE/g' /etc/inxi.conf
0 new messages