# display going to sleep after starting wm



## chessguy64 (May 18, 2022)

I left my system on overnight and gnome put my monitor to sleep (which I thought I had turned off in settings). Now whenever I log in and startx, the screen is loading and black like normal, but then my monitor light starts blinking, and I can't get anything on the display. Doesn't seem to matter which wm I start, same thing. (tried with xfce). If I remove the .xinitrc from my home directory, and "$ startx", I get a display. I know it's not my nvidia driver, because it was working fine all day yesterday. Is this a saved state somewhere in a file I have to clear? How do I fix this?


----------



## SirDice (May 18, 2022)

Xorg itself doesn't keep the state as far as I know. But if you used x11/nvidia-settings, that does save some things. It may have saved some resolution/refresh rate combination that's out of range for your monitor. Most monitors nowadays will just switch off the display to protect it.


----------



## mer (May 18, 2022)

Some of the WMs/DEs use a screen saver program to do that, so double check any autostart items.
If by removing your .xinitrc, take a look for an "xset dpms" command in it.
My preferred method is to have this line in my .xinitrc
xset dpms 0 0 600

and not run any type of screensaver.  That command uses the monitor power management stuff and after 5 minutes of inactivity, powers down the monitor.

Sorry, I'm answering "not your question".


----------



## chessguy64 (May 18, 2022)

I didn't use nvidia-settings. The only settings I changed was in the nvidia app, "performance max". What's the best way to resolve this? Tried removing xorg and nvidia-driver-340, and reinstalling. That didn't work.


----------



## mer (May 18, 2022)

What are the contents of your .xinitrc file?  You say removing that you don't have the problem, but I agree that it sounds like command in there is trying to put the monitor in a state it doesn't like.
I think the nvidia app/nvidia-settings can create a save file of the settings (it may do it by default) so if there is a command in your .xinitrc to reload it, it could have bad input for your card/monitor.


----------



## chessguy64 (May 18, 2022)

mer said:


> and not run any type of screensaver. That command uses the monitor power management stuff and after 5 minutes of inactivity, powers down the monitor.



It's good to know for the future, but the only thing that was in my .xinitrc was "exec /usr/local/bin/gnome-session". I tried just a "startxfce4" with no .xinitrc file and the same thing happened. It looks like I'm going to have to do a clean install now because I've hit the power button on my desktop so many times to restart I'm getting a kernel panic every time I boot now.  ->

"panic: ufs_dirbad /: bad dir ino 12900608 at ofset 48128: mangled entry"

next install I will be sure to turn off any screensavers / double check power management stuff. Thanks.


----------



## mer (May 18, 2022)

You have nividia, yes?  At one point in time there were issues if you were in a graphical mode and then switched to a different console, the screen would be all just green blocks.  A work around for that was to add the following line to your /boot/loader.conf file and reboot:

hw.vga.textmode="1"

I don't know if the problem was ever fixed or not, I don't know if it relates to your problem, but it at least doesn't hurt.


----------



## SirDice (May 18, 2022)

chessguy64 said:


> Doesn't seem to matter which wm I start, same thing. (tried with xfce). If I remove the .xinitrc from my home directory, and "$ startx", I get a display.


So, XFCE and Gnome fail, but TWM works. Both XFCE and Gnome have their own resolution settings (stored in your home directory along the other XFCE/Gnome settings). Those would be ignored by TWM. 



chessguy64 said:


> Tried removing xorg and nvidia-driver-340, and reinstalling.


Removing and/or reinstalling applications isn't going to change or remove settings. Especially not settings that are stored in the user's home directory. 



chessguy64 said:


> It looks like I'm going to have to do a clean install now because I've hit the power button on my desktop so many times to restart I'm getting a kernel panic every time I boot now.


Check your BIOS settings. Specifically power button settings. Set this to 4 second delay. Then a momentary (short) press of the power button will trigger a graceful shutdown via ACPI. Pressing the power button for 4 seconds will instantly power it off. Immediately turning the power off could result in a filesystem corruption. Another way would be to SSH into the machine and restart it remotely.

What happens if you create a new (test) user account and use that? If it works on the new test user then we can conclude the faulty setting is stored somewhere in your home directory.


----------



## chessguy64 (May 18, 2022)

mer said:


> At one point in time there were issues if you were in a graphical mode and then switched to a different console, the screen would be all just green blocks


Yes I have nvidia. What do you mean by switching to a different console? Like switching to a different text tty (ALT-F1) while inside a WM ? I didn't know you could do that, I thought you had to kill the x session first. 



SirDice said:


> Immediately turning the power off could result in a filesystem corruption. Another way would be to SSH into the machine and restart it remotely.



Yes I should have tapped the power button instead of holding it down. I think I remember trying that a few times when I was having problems using the wrong nvidia driver, when my display was hanging,and it didn't work. Or maybe I just didn't wait long enough. I will double check my BIOS settings. Also I created a new user acccount and put "exec /usr/local/bin/gnome-session" in .xinitrc, and the same thing happened. I was looking in /usr/local/share/X11 at app-defaults and some other files, but that's all gone now. lol.


----------



## mer (May 18, 2022)

Answer to your question is "Yes, that's what I meant".  When in an X session, "CTRL-ALT-F#" to switch to an alternate console.

I think SirDice is right with a local config file for XFCE/Gnome.  I'm not sure where that would live, but a lot winds up  under $HOME/.config  Some applications do wind up creating their own directories under $HOME so you'll need to do "ls -a" to find them.


----------



## chessguy64 (May 18, 2022)

Yeah but why would GNOME/Xfce generate a default config file for a new user based off settings from another user ? My monitor blinking and the display not coming up correctly persisted across user accounts. I'm thinking it's some type of shared file / files somewhere in the filesystem and not in $HOME that it is reading from and loading these saved values / states.


----------



## SirDice (May 18, 2022)

After things have gone south, can you post the Xorg.0.log from that session?

Easy way to do that on the commandline: `cat /var/log/Xorg.0.log | nc termbin.com 9999`


----------



## mer (May 18, 2022)

chessguy64 said:


> Yeah but why would GNOME/Xfce generate a default config file for a new user based off settings from another user ? My monitor blinking and the display not coming up correctly persisted across user accounts.


Ahh, sorry, I missed that from post #9.


----------



## chessguy64 (May 18, 2022)

SirDice said:


> After things have gone south, can you post the Xorg.0.log from that session?



I can't. I get a kernel panic with the error msg I posted earlier every time I boot. I could possibly do it with recovery / single user mode ? But even then I'd have to reinstall for any fixes to work. Unless there is some way to repair the filesystem?


----------



## SirDice (May 18, 2022)

chessguy64 said:


> I could possibly do it with recovery / single user mode ?


Just don't start X after you rebooted. The logs would still be there after the panic/reboot. Only if you start X it would get overwritten with the 'new' session logs. 



chessguy64 said:


> Unless there is some way to repair the filesystem?


Yeah, you probably want to fix those first. Boot to single user mode and run `fsck -y` there.


----------



## Deleted member 70435 (May 18, 2022)

chessguy64 said:


> I can't. I get a kernel panic with the error msg I posted earlier every time I boot. I could possibly do it with recovery / single user mode ? But even then I'd have to reinstall for any fixes to work. Unless there is some way to repair the filesystem?


do you have any knowledge about vt and framebuffer? you may be able to troubleshoot and your monitor recognizes.


----------



## chessguy64 (May 18, 2022)

I'm getting a lot of "READ_DMA CAM ATA Status" errors while fsck is running. It's saying it could not read from certain blocks / sectors. Is this indicative of a failing hard drive? or just a corrupted filesystem? I had done a "smartctl" test on the drive a few days ago and I don't think there were any errors. No knowledge of vt or framebuffer, no.


----------



## mer (May 18, 2022)

My experience has been those types of errors are more hardware than software related.  A software change can trigger them:  think of a timeout that got changed.  "Send a command, wait X, check for status"  Maybe previous version X was a lot longer and it was changed down.  That could lead to more errors being detected.

So double check cables:  power down, unplug and replug both ends of data cables.  Do one cable at a time so you don't look track of where they were.  Also unplug and replug power cables to the drives.

sometimes the quick smartctl tests don't show anything but a longer test does.


----------



## grahamperrin@ (May 22, 2022)

Reading this alongside <https://forums.freebsd.org/posts/568325> and nearby posts: starting afresh will be a good idea (if you have not already done so), but only if you're certain that the storage is OK.



chessguy64 said:


> I'm getting a lot of "READ_DMA CAM ATA Status" errors while fsck is running. It's saying it could not read from certain blocks / sectors. Is this indicative of a failing hard drive?



Maybe.



chessguy64 said:


> or just a corrupted filesystem? I had done a "smartctl" test on the drive a few days ago and I don't think there were any errors. …



S.M.A.R.T self-tests, short and extended, are: 

read-oriented
no substitute for a thorough write test. 
Please see, for example steps 1–5 under <https://forums.freebsd.org/posts/529183>. 

Ultimate Boot CD

does not include StressDisk
includes things such as *HDAT2*
<https://forums.freebsd.org/posts/530069>
<https://forums.freebsd.org/posts/547395>


----------



## chessguy64 (May 22, 2022)

I'll be mounting another hard drive in my case and installing 13.1-RELEASE on it. I'm pretty sure the hard drive I was using before is good, at least good enough to work for a while, but I'll go with ZFS instead of UFS this time, installing the nvidia driver from pkg instead of ports. Also I noticed that I can do "pkg install nvidia-driver-340' or 'pkg install nvidia-driver-390'. On my first attempt I did 'pkg install nvidia-driver', which installed the 470 driver. When that didn't work I built the nvidia-driver-390 from ports, never doing 'pkg install nvidia-driver-3xx'. I'm not too hopeful it will be stable because of all the reports of crashes with the 390 driver, but maybe I can move to something more lightweight, like e16. Also, what about setting up wayland instead of xorg?


----------



## grahamperrin@ (May 22, 2022)

Thanks,



chessguy64 said:


> … I'm pretty sure the hard drive I was using before is good, at least good enough to work for a while, …



My strongest possible recommendation is to stress-test the disk, in its entirety, before giving it to ZFS. 

HDAT2, if you can. There exist many alternatives but (if UBCD and HDAT2 will work with your hardware) the result of HDAT2's _most powerful_ test (pictured in post 530069) will be enlightening.


----------



## grahamperrin@ (May 22, 2022)

chessguy64 said:


> … wayland instead of xorg?



I never used Wayland (see <https://community.kde.org/FreeBSD/Setup#KDE_and_the_rest> point 5). More specifically, I never attempted to jump through the hoops that might be required for it to work for KDE Plasma. 

This year's Wayland-oriented topics include: 









						Sway and Wayland
					

Reading the page 107,Chapter 5. The X Window System on the official FreeBSD handbook and the problem is that's the official handbook does not explain something about installing and managing Wayland. Arrived at this point a question rises in my mind - Is it even possible in 2022 install and use...




					forums.freebsd.org
				












						Nesting, ie running a wayland-compositor within an xorg-desktop.
					

Currently i'm experimenting in running "sway" or "labwc" within "xfce4". Do you nest some things, what are your experiences?




					forums.freebsd.org


----------



## chessguy64 (May 22, 2022)

It's more of a learning environment than anything. Not vital that the system is stable 100% of the time. All the data on the disk is expendable. Text only console mode, no X as a last resort. But I just read TCP/IP Illustrated Volume 2 so working with a BSD would be preferable. (I know the 4.4BSD-Lite code is old) I have other books as well like APUE so I need a UNIX/BSD.


----------

