Debian 11 Bullseye dual monitor freezes after locking it and more...

mrmazda · 01-23-2022, 12:40 PM

Quote:

Originally Posted by linuxnewbie137

Well, I deactivated KScreen2 and created a file named 50primaryScreen containing "xrandr --output HDMI-1 --primary" (just that), it didn't do anything. Then I renamed it into 50primaryScreen.conf and pc didn't even boot :P . So, either I missing something or it just doesn't work like this.

The filename might make a difference. I usually name mine setup. 50primaryScreen could be being usurped by one of the later run files that were already there. Try dropping the 50, and deleting ~/.cache/* again.

If you create and login as another user, does it have all the same trouble?

linuxnewbie137 · 01-23-2022, 03:50 PM

Quote:

Originally Posted by mrmazda

The filename might make a difference. I usually name mine setup. 50primaryScreen could be being usurped by one of the later run files that were already there. Try dropping the 50, and deleting ~/.cache/* again.

If you create and login as another user, does it have all the same trouble?

I renamed the 50primaryScreen file into setup.primaryScreen and .cache into .cache.old. I created the new user as well and rebooted. My main user's monitors configuration remained the same, but the new user's were set correctly.

mrmazda · 01-23-2022, 05:43 PM

Something in your Plasma settings is corrupted. Delete ~/.cache/* one more time, and delete everything in ~/.config/ that starts with a K, Q, ak, ba, br, dr, k, pl, po, q, sp, st, sy, while Plasma is not running. Delete files with the same start characters (except for kmail if it exists) in ~/.local/share/ also, and every directory in $HOME that begins with .kd or .qt. You could delete everything in ~/.config/, but that would loose settings for applications other than KDE/Plasma, such as chromium, which, if you have a good recent backup, you could restore after deleting everything. For extra insurance, before restarting Plasma, reboot, to ensure there's nothing corrupted remaining in RAM cache from the previous Plasma session.

linuxnewbie137 · 01-23-2022, 07:29 PM

Quote:

Originally Posted by mrmazda

Something in your Plasma settings is corrupted. Delete ~/.cache/* one more time, and delete everything in ~/.config/ that starts with a K, Q, ak, ba, br, dr, k, pl, po, q, sp, st, sy, while Plasma is not running. Delete files with the same start characters (except for kmail if it exists) in ~/.local/share/ also, and every directory in $HOME that begins with .kd or .qt. You could delete everything in ~/.config/, but that would loose settings for applications other than KDE/Plasma, such as chromium, which, if you have a good recent backup, you could restore after deleting everything. For extra insurance, before restarting Plasma, reboot, to ensure there's nothing corrupted remaining in RAM cache from the previous Plasma session.

I don't have a backup of my main user.

Quote:

Delete files with the same start characters (except for kmail if it exists) in ~/.local/share/ also...

Do you mean same start characters as before (K, Q, ak, ba... etc) for config? Directories as well? Because there are no files in ~/.local/share/, only directories.

I deleted everything you said except things under ~/.local/share/, still the same, small screen is the primary one.

BTW I didn't know that disabling KScreen2 was user-specific setting, so, I was wrong about the second's user monitors configuration. small screen is the primary one as well.

mrmazda · 01-23-2022, 11:55 PM

Quote:

Originally Posted by linuxnewbie137

I don't have a backup of my main user.

You could make one.

Quote:

Do you mean same start characters as before (K, Q, ak, ba... etc) for config? Directories as well? Because there are no files in ~/.local/share/, only directories.

Yes. Directories are files.

Quote:

I deleted everything you said except things under ~/.local/share/, still the same, small screen is the primary one.

Quote:

BTW I didn't know that disabling KScreen2 was user-specific setting, so, I was wrong about the second's user monitors configuration. small screen is the primary one as well.

You disabled KScreen2 in the second user and still the small screen on VGA is primary?

I'm running out of ideas. Are there any remnants of your attempt to install NVidia's proprietary drivers, unneeded/unwanted files, either in /etc/X11/xorg.conf.d/, or /etc/X11/xorg.conf? A default install should have neither, or /etc/X11/xorg.conf.d/ may exist but be empty or have one or two files for input or other devices besides monitors.

Is your HDMI connection pure, or is there an adapter involved? Have you tried another HDMI cable?

Is the problem present if you login to some other session type than Plasma, and have the xrandr script xrandr --output HDMI-1 --primary in /etc/X11/Xsession.d/? There should be some other option available via your login screen, maybe Openbox. If there isn't, add one either using tasksel in a terminal, or apt install icewm to get the fallback minimalist DE that I use for such purposes.

One more thing to try: to the xrandr script add a new first line xrandr --output HDMI-1 --auto.

Another long shot: change the original line to xrandr --output HDMI-1 --mode 1920x1080 --rate 60 --primary --output VGA-1 --right-of HDMI-1

Another: append a 3 to the linu line that appears after striking the E key at the Grub menu with the highlight on your normal Grub menu selection. This line usually wraps, but is easily reached with left arrow after going down to the initrd line. After booting this way, login as root, then try startx. Don't do anything more than is required to determine whether problem remains, then exit the session, and execute systemctl isolate graphical to return to normal operation, or just reboot. Attempting startx by an ordinary user will probably fail, but you could try.

If you have an available DVI port on the 9500, try using it instead of the VGA port, with an adapter if necessary because your smaller display only has VGA and/or HDMI input.

I tried reproducing your situation with two different PCs with NVidia GPUs:

Code:

# inxi -S
System:
  Host: gb970 Kernel: 5.10.0-11-amd64 x86_64 bits: 64
    Desktop: Trinity R14.0.11 Distro: Debian GNU/Linux 11 (bullseye)
# inxi -Gayz
Graphics:
  Device-1: NVIDIA GF108 [GeForce GT 630] vendor: Gigabyte driver: nouveau
    v: kernel bus-ID: 01:00.0 chip-ID: 10de:0f00 class-ID: 0300
  Display: x11 server: X.Org 1.20.11 driver: loaded: modesetting
    display-ID: :0 screens: 1
  Screen-1: 0 s-res: 3600x1080 s-dpi: 120 s-size: 762x228mm (30.0x9.0")
    s-diag: 795mm (31.3")
  Monitor-1: HDMI-1 res: 1920x1080 hz: 60 dpi: 305 size: 160x90mm (6.3x3.5")
    diag: 184mm (7.2")
  Monitor-2: VGA-1 res: 1680x1050 hz: 60 dpi: 90
    size: 474x296mm (18.7x11.7") diag: 559mm (22")
  OpenGL: renderer: llvmpipe (LLVM 11.0.1 128 bits) v: 4.5 Mesa 20.3.5
    compat-v: 3.1 direct render: Yes
# xrandr | egrep 'onnect|creen|\*' | grep -v disconn | sort -r
VGA-1 connected 1680x1050+1920+0 (normal left inverted right x axis y axis) 474mm x 296mm
Screen 0: minimum 320 x 200, current 3600 x 1080, maximum 16384 x 16384
HDMI-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 160mm x 90mm
   1920x1080     60.00*+  59.96    59.94    59.93    30.00    24.00    29.97    23.98
   1680x1050     59.97*+  74.89    59.95    59.88
#

As you can see, the HDMI connected to the larger screen is monitor-1, so is where the login greeter appears, and is the functional primary in the TDE desktop session. Neither xorg.conf nor xrandr were required to produce this. It just happened automagically.

Code:

# inxi -S
System:
  Host: hp945 Kernel: 5.10.0-11-amd64 x86_64 bits: 64
    Desktop: Trinity R14.0.12 Distro: Debian GNU/Linux 11 (bullseye)
# inxi -Gayz
Graphics:
  Device-1: NVIDIA GT218 [GeForce 210] vendor: eVga.com. driver: nouveau
    v: kernel bus-ID: 01:00.0 chip-ID: 10de:0a65 class-ID: 0300
  Display: x11 server: X.Org 1.20.11 driver: loaded: modesetting
    unloaded: fbdev,vesa display-ID: :0 screens: 1
  Screen-1: 0 s-res: 3600x1080 s-dpi: 120 s-size: 762x228mm (30.0x9.0")
    s-diag: 795mm (31.3")
  Monitor-1: HDMI-1 res: 1920x1080 hz: 60 dpi: 305 size: 160x90mm (6.3x3.5")
    diag: 184mm (7.2")
  Monitor-2: VGA-1 res: 1680x1050 hz: 60 dpi: 90
    size: 474x296mm (18.7x11.7") diag: 559mm (22")
  OpenGL: renderer: NVA8 v: 3.3 Mesa 20.3.5 direct render: Yes
# xrandr | egrep 'onnect|creen|\*' | grep -v disconn | sort -r
VGA-1 connected 1680x1050+1920+0 (normal left inverted right x axis y axis) 474mm x 296mm
Screen 0: minimum 320 x 200, current 3600 x 1080, maximum 8192 x 8192
HDMI-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 160mm x 90mm
   1920x1080     60.00*+  59.96    59.94    59.93    30.00    24.00    29.97    23.98
   1680x1050     59.97*+  74.89    59.95    59.88
#

Different GPU, same result. None of my older NVidia GPUs have HDMI outputs. The GeForce 210 is roughly a year newer than your GeForce 9500 GT. My GT 630 is newer still.

linuxnewbie137 · 01-24-2022, 08:18 AM

Quote:

You could make one.

True, but in case that my configs or something is broken, I will backup the broken thing as well. I guess there is no point on doing that.

Quote:

Yes. Directories are files.

Of course, everything is a file on linux, but I had to ask just to be sure I won't delete anything necessary or crucial. However, I will try that when we are completely out of ideas, because I have reconfigured my desktop like 10 times since yesterday. :P

Quote:

You disabled KScreen2 in the second user and still the small screen on VGA is primary?

Yes.

Quote:

I'm running out of ideas. Are there any remnants of your attempt to install NVidia's proprietary drivers, unneeded/unwanted files, either in /etc/X11/xorg.conf.d/, or /etc/X11/xorg.conf? A default install should have neither, or /etc/X11/xorg.conf.d/ may exist but be empty or have one or two files for input or other devices besides monitors.

No, there is only our setup file inside /etc/X11/xorg.conf.d/. There is only one xorg.conf file, in the entire system, under /usr/share/doc/xserver-xorg-video-intel/ containing only a Device section about my CPU (I guess).

Quote:

Is your HDMI connection pure, or is there an adapter involved? Have you tried another HDMI cable?

Yes, there are no adapters at my HDMI connection.

Quote:

Is the problem present if you login to some other session type than Plasma, and have the xrandr script xrandr --output HDMI-1 --primary in /etc/X11/Xsession.d/? There should be some other option available via your login screen, maybe Openbox. If there isn't, add one either using tasksel in a terminal, or apt install icewm to get the fallback minimalist DE that I use for such purposes.

There was no option for other sessions, so I installed icewm.
The problem is present, yes.

Quote:

One more thing to try: to the xrandr script add a new first line xrandr --output HDMI-1 --auto.

Another long shot: change the original line to xrandr --output HDMI-1 --mode 1920x1080 --rate 60 --primary --output VGA-1 --right-of HDMI-1

Nope, nothing changed.

Quote:

Another: append a 3 to the linu line that appears after striking the E key at the Grub menu with the highlight on your normal Grub menu selection. This line usually wraps, but is easily reached with left arrow after going down to the initrd line. After booting this way, login as root, then try startx. Don't do anything more than is required to determine whether problem remains, then exit the session, and execute systemctl isolate graphical to return to normal operation, or just reboot. Attempting startx by an ordinary user will probably fail, but you could try.

During this attempt when I opened the GUI for root, HDMI was my primary monitor but KScreen2 was enabled, so I disabled it, logged out, logged in and then the VGA was my primary again.

There is a new clue here though. I don't know if you are aware of it, but X server is using /usr/share/X11/xorg.conf.d/ as system configuration directory. This directory contains the following files:

1) 10-amdgpu.conf

2) 10-quirks.conf

3) 10-radeon.conf

4) 40-libinput.conf

5) 70-wacom.conf

I guess this is a system-wide configuration directory for x-server, not user-specific. Maybe our script should be putted in here?

Quote:

If you have an available DVI port on the 9500, try using it instead of the VGA port, with an adapter if necessary because your smaller display only has VGA and/or HDMI input.

My smaller display has only a VGA input.
I don't understand the reason of doing that, but I did try to connect my second monitor via DVI and I ended up with an "out of range" message in both monitors :P

Also, this was found inside /var/log/Xorg.0.log. I don't know if it is normal or related to any of the above, that's why I am posting it.

Code:

# [    13.814] (II) modeset(0): EDID vendor "GSM", prod id 19322
[    13.814] (II) modeset(0): Using hsync ranges from config file
[    13.814] (II) modeset(0): Using vrefresh ranges from config file
[    13.814] (II) modeset(0): Printing DDC gathered Modelines:
[    13.814] (II) modeset(0): Modeline "1440x900"x0.0  106.50  1440 1520 1672 1904  900 903 909 934 -hsync +vsync (55.9 kHz eP)
[    13.814] (II) modeset(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz e)
[    13.814] (II) modeset(0): Modeline "800x600"x0.0   36.00  800 824 896 1024  600 601 603 625 +hsync +vsync (35.2 kHz e)
[    13.815] (II) modeset(0): Modeline "640x480"x0.0   31.50  640 656 720 840  480 481 484 500 -hsync -vsync (37.5 kHz e)
[    13.815] (II) modeset(0): Modeline "640x480"x0.0   31.50  640 664 704 832  480 489 492 520 -hsync -vsync (37.9 kHz e)
[    13.815] (II) modeset(0): Modeline "640x480"x0.0   30.24  640 704 768 864  480 483 486 525 -hsync -vsync (35.0 kHz e)
[    13.815] (II) modeset(0): Modeline "640x480"x0.0   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz e)
[    13.815] (II) modeset(0): Modeline "720x400"x0.0   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz e)
[    13.815] (II) modeset(0): Modeline "1280x1024"x0.0  135.00  1280 1296 1440 1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz e)
[    13.815] (II) modeset(0): Modeline "1024x768"x0.0   78.75  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.0 kHz e)
[    13.815] (II) modeset(0): Modeline "1024x768"x0.0   75.00  1024 1048 1184 1328  768 771 777 806 -hsync -vsync (56.5 kHz e)
[    13.815] (II) modeset(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
[    13.815] (II) modeset(0): Modeline "832x624"x0.0   57.28  832 864 928 1152  624 625 628 667 -hsync -vsync (49.7 kHz e)
[    13.815] (II) modeset(0): Modeline "800x600"x0.0   49.50  800 816 896 1056  600 601 604 625 +hsync +vsync (46.9 kHz e)
[    13.815] (II) modeset(0): Modeline "800x600"x0.0   50.00  800 856 976 1040  600 637 643 666 +hsync +vsync (48.1 kHz e)
[    13.815] (II) modeset(0): Modeline "1152x864"x0.0  108.00  1152 1216 1344 1600  864 865 868 900 +hsync +vsync (67.5 kHz e)
[    13.815] (II) modeset(0): Modeline "1440x900"x0.0  136.75  1440 1536 1688 1936  900 903 909 942 -hsync +vsync (70.6 kHz e)
[    13.815] (II) modeset(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)

I don't know if this happens to you as well, but the VGA monitor is the primary one even at boot time, like, even before I get into grub's menu to select OS etc. Obviously it is the same in a later time at login screen.

I know that this should be able to change with configuration files inside users' accounts, which in my case doesn't happen, but I just provide you everything I can.

mrmazda · 01-24-2022, 09:55 AM

Quote:

Originally Posted by linuxnewbie137

True, but in case that my configs or something is broken, I will backup the broken thing as well. I guess there is no point on doing that.

By backup I meant a backup from which files can be selectively restored, one at a time if necessary or desired.

Quote:

No, there is only our setup file inside /etc/X11/xorg.conf.d/.

Is this a typo? The instruction was:

Quote:

Create a file containing it in /etc/X11/Xsession.d/.

/etc/X11/xorg.conf.d/ is for configuration settings. They are read and taken into account by the X server. /etc/X11/Xsession.d/ contains commands to be executed at X startup regardless of configuration settings.

Quote:

There was no option for other sessions, so I installed icewm.
The answer is yes.

So this is not a KDE/Plasma problem.

Quote:

During this attempt when I opened the GUI for root, HDMI was my primary monitor but KScreen2 was enabled, so I disabled it, logged out, logged in and then the VGA was my primary again.

Try this again, but before logging out, run the xrandr --output HDMI-1 --primary script you put in /etc/X11/Xsession.d/.

There is a new clue here though. I don't know if you are aware of it, but X server is using /usr/share/X11/xorg.conf.d/ as system configuration directory. This directory contains the following files:

1) 10-amdgpu.conf

2) 10-quirks.conf

3) 10-radeon.conf[/quote]Mine only has 10-radeon.conf. Please post the content of all three of these. Since we are using NVidia GPUs, not AMD, 1 & 3 should not be affecting either of us.

Quote:

I guess this is a system-wide configuration directory for x-server, not user-specific. Maybe our script should be putted in here?

Anything in /usr/share/X11/xorg.conf.d/ that is inconsistent with content in /etc/X11/xorg.conf.d/ is overridden by the latter. /usr/ is the domain of the package management system. It should not be touched by the sysadmin. /etc/ is for the sysadmin.

Quote:

My smaller display has only a VGA input.
I don't understand the reason of doing that, but I did try to connect my second monitor via DVI and I ended up with an "out of range" message in both monitors :P

When nothing seeming logical seems to have any effect on a problem, seemingly less or illogical remains to be tried.

Also, this was found inside /var/log/Xorg.0.log. I don't know if it is normal or related to any of the above, that's why I am posting it.

Quote:

Code:

# [    13.814] (II) modeset(0): EDID vendor "GSM", prod id 19322
[    13.814] (II) modeset(0): Using hsync ranges from config file
[    13.814] (II) modeset(0): Using vrefresh ranges from config file

I don't know where these come from. I don't have any *.conf files anywhere on my currently booted Bullseye installation that specify hsync or vrefresh. Yet, my log also shows them right before the modelines listing. I can only presume either there are some hard-coded defaults contained within a binary file, or those lines get printed preceding modelines regardless of existence or not of any configuration files. Their values shouldn't have anything to do with your problem.

Quote:

I don't know if this happens to you as well, but the VGA monitor is the primary one even at boot time, like, even before I get into grub's menu to select OS etc. Obviously it is the same in a later time at login screen.

Here the HDMI port's display is where POST and Grub's menu show up. Older discrete GPUs tend to favor the outputs bottom to top, that is, #1 in priority is the port closest to the motherboard, and #3 the farthest from it. Is your 9500's HDMI port in the middle between VGA & DVI, or at the top? On my GT218, the older card in post #20, and the card in post #2, HDMI is in the middle. OTOH, my newer GF108 has HDMI at the top, and yet HDMI is its primary when coupled with VGA rather than DVI.

Quote:

I know that this should be able to change with configuration files inside users' accounts, which in my case doesn't happen, but I just provide you everything I can.

Speaking of user accounts, you could try running that xrandr script from Plasma itself: systemsettings -> startup & shutdown -> autostart.

This could be a problem caused by the DM. If you're using SDDM, try switching to LightDM, or vice versa.

Do you have a TV or access to some other 1920x1080 monitor to try with your HDMI cable? It's possible there is something in your larger monitor's EDID that X doesn't like.

linuxnewbie137 · 01-24-2022, 11:32 AM

Quote:

Is this a typo? The instruction was:
Create a file containing it in /etc/X11/Xsession.d/.

Well, in the first place I got confused and created the file inside xorg.conf.d, but in a later time I noticed my mistake and placed the file under Xsession.d. The name of the file was setup.primaryScreen and it didn't work, but now I changed it into 50primaryScreen as you suggested in the beginning and it worked. The thing is that the lock screen freeze remains after all. So, I believe it is not related with KScreen2.

I am sorry about your extra trouble.

Please let me know how you made the link to your phrase.

Quote:

When nothing seeming logical seems to have any effect on a problem, seemingly less or illogical remains to be tried.

That's true

Quote:

... Is your 9500's HDMI port in the middle between VGA & DVI, or at the top? ...

No, VGA is in the middle, between DVI (on the left) and HDMI (on the right).

mrmazda · 01-24-2022, 03:41 PM

Quote:

Originally Posted by linuxnewbie137

Well, in the first place I got confused and created the file inside xorg.conf.d, but in a later time I noticed my mistake and placed the file under Xsession.d. The name of the file was setup.primaryScreen and it didn't work, but now I changed it into 50primaryScreen as you suggested in the beginning and it worked.

So, no longer is which display is primary is any issue, right, big/HDMI screen = primary screen?

Quote:

The thing is that the lock screen freeze remains after all. So, I believe it is not related with KScreen2.

Is this applicable only to a KDE/Plasma session, not to IceWM? If yes, it's more of a "Desktop" issue than a "Debian" issue. I suggest to start a new thread in the "Desktop" forum, given how little attention the issue brought here in "Debian". Get some fresh eyes without any digression into primary display. Other than switching to a different DM, I don't know what to do more than we already have to diagnose the lock screen freezing. Possibly you can re-enable KScreen2 without losing your HDMI primary.

Quote:

Please let me know how you made the link to your phrase.

Above the input window is an icon that looks like a world globe. Clicking that opens an input window to paste or type a URL that will be applied to whatever text is highlighted when the globe link was clicked on.

Quote:

No, VGA is in the middle, between DVI (on the left) and HDMI (on the right).

There's no way to know what left and right, with nothing more, refer to, because those other than yourself can't see your PC's physical position. It could be a tower case, but laid on its side, or a desktop case, but stood on its end. So, the motherboard is considered to be situated at the bottom, because everything else is plugged down into it, and usually faces up when it is being serviced or built. Thus the "bottom" of a PC is the adjacent side closest to where the mouse and keyboard cables plug in, even though when in normal use it may be standing upright. This corresponds to PCI & PCIe adapter cards, whose bottom contains the connectors that go into a motherboard socket. So, most likely, your DVI is the bottom connector and your HDMI is the top connector.

And it's why X thinks your VGA should be the primary when the DVI is not used.

linuxnewbie137 · 01-24-2022, 07:58 PM

Quote:

So, no longer is which display is primary is any issue, right, big/HDMI screen = primary screen?

Yes, big/HDMI screen is my primary screen now. The lock screen freeze is still here so I re-enabled the KScreen2. We are where we began but without the complete freeze.

Quote:

Is this applicable only to a KDE/Plasma session, not to IceWM? ...

I don't know, because lock screen shortcut and lock button don't work during IceWM session.

Quote:

... Other than switching to a different DM...

How can I do that without messing up everything? I guess I have to log in a tty session, systemctl set-default multi-user.target, reboot, remove sddm, download e.g lightDM, systemctl set-default graphical.target and reboot, right?

Quote:

Above the input window is an icon that looks like a world globe. Clicking that opens an input window to paste or type a URL that will be applied to whatever text is highlighted when the globe link was clicked on.

This is a test link:

Quote:

Please let me know how you made the link to your phrase.

Quote:

There's no way to know what left and right, with nothing more, refer to...

Looking a tower from behind, knowing where the MOBO is and how PCI is plugged onto it, I thought that it is easy to understand left and right even if the case is upside down. Anyway, you are right, you can't see my PC and I should be more specific about it.

Quote:

... This corresponds to PCI & PCIe adapter cards, whose bottom contains the connectors that go into a motherboard socket. So, most likely, your DVI is the bottom connector and your HDMI is the top connector. And it's why X thinks your VGA should be the primary when the DVI is not used.

You are right again, DVI is the bottom connector and HDMI is the top connector.

mrmazda · 01-24-2022, 10:35 PM

Quote:

Originally Posted by linuxnewbie137

Quote:

... Other than switching to a different DM...

How can I do that without messing up everything? I guess I have to log in a tty session, systemctl set-default multi-user.target, reboot, remove sddm, download e.g lightDM, systemctl set-default graphical.target and reboot, right?

DEs aren't tied to specific DMs. You shouldn't need another DM to use some other DE. You can select another DE to install just like installing some application. At the greeter screen you can select among all installed DEs. To keep your settings safe, use an alternate user/login to check for freezing lock screen with/in the alternate DE.

linuxnewbie137 · 01-25-2022, 07:49 AM

Quote:

Originally Posted by mrmazda

DEs aren't tied to specific DMs. You shouldn't need another DM to use some other DE. You can select another DE to install just like installing some application. At the greeter screen you can select among all installed DEs. To keep your settings safe, use an alternate user/login to check for freezing lock screen with/in the alternate DE.

You told me to change DM not DE, but now you are speaking about changing DE. Is this because you want me to use another DE to check that freeze related to screen lock? Should I try changing both?

BTW I have seen a video about DEs which was saying that we shouldn't install many DEs together because there are daemons and other things, that I can't remember right now, that could be messed up. I installed Plasma, some years ago, to my laptop alongside mate and it was like 105 celsius when running Plasma. Now, this could be messed up things or just Plasma was super heavy for my laptop back then.

mrmazda · 01-25-2022, 10:39 AM

Quote:

Originally Posted by linuxnewbie137

You told me to change DM not DE, but now you are speaking about changing DE. Is this because you want me to use another DE to check that freeze related to screen lock? Should I try changing both?

Yes to both, but independently, and DM first, since it's simpler and shouldn't impact personal settings.

Quote:

BTW I have seen a video about DEs which was saying that we shouldn't install many DEs together because there are daemons and other things, that I can't remember right now, that could be messed up.

I've seen that claim, but never AFAIK experienced consequent trouble. Using another DE only by logging in as a different user should be protective against any such trouble.

linuxnewbie137 · 01-26-2022, 02:04 PM

For some reason some shortcuts stopped working. I didn't do anything different, I was keep switching compositors etc, nothing that I haven't done already.

journalctl -xe reported -> (see the attached picture).

I don't have the sliest idea about what happened but I fixed that by deleting files from .config/ .cache/ and .local/share as you told me.

Quote:

Originally Posted by mrmazda

Yes to both, but independently, and DM first, since it's simpler and shouldn't impact personal settings.

I've seen that claim, but never AFAIK experienced consequent trouble. Using another DE only by logging in as a different user should be protective against any such trouble.

I installed gnome-desktop using this command:

Code:

# sudo tasksel install desktop gnome-desktop

Logged in from a different user into gnome, without removing KDE, and nothing happened. Freezes are still there. It has to be SDDM problem, because the screen freezes, not the mouse, and the apps e.g firefox - youtube still playing.

I don't want to change display manager though, KDE picked this manager for a reason and it should work. Do you think a reinstall of it can make any difference? Maybe be I can reconfigure it somehow, I don't know...

I also tried to create a brand new user without any configuration just in case there is a bug or something with the theme, icons or conky I use. Nothing, freeze is still there.

New clues:

1) If I open and close enough photos I can make the freeze happen. It seems like a buffer fills up but never gets cleaned. I am not 100% sure about it, but I think this doesn't happen to new users or the buffer isn't filled up enough and I need to open more photos.

2) Login freeze doesn't seem to be related to the second monitor, it just makes the freeze happen faster than photos (I guess). It happened in single monitor setup as well.

mrmazda · 01-26-2022, 07:03 PM

Quote:

Originally Posted by linuxnewbie137

I don't want to change display manager though, KDE picked this manager for a reason and it should work.

Theory and practice don't always match up. The reason was KDM was based upon KDE4. Switching to a KDE5 base for KDM was apparently too big an ordeal for anyone to volunteer to do the work. KDE decided it had to retain a DM of its own, so somebody cobbled together something that should work for most users. The result was many KDM features were lost when KDM4 support ceased, and apparently, adequate testing of multi-monitor installations was one of SDDM's omissions. Consequently, I use KDM3 or TDM on the vast majority of my own installations. I have SDDM on very few installations, and on zero Debian installations. More often I use LightDM than SDDM.

Quote:

Do you think a reinstall of it can make any difference?

Unlikely, but you could try purging rather than mere removal. Purging removes config files that removal leaves behind. Until and unless it happens that some other fault can be proven, SDDM as your problem can't be ruled out. Troubleshooting is a matter of elimination.