Re: video issue following latest bullseye update
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]
----
Doc
--
Web: http://enginehousebooks.com/drevans
Reply to: