![]() May 10 02:21:04 yeono acpid: input device has been disconnected, fd 9 May 10 02:20:47 yeono acpid: input device has been disconnected, fd 9 Aside from the regularly flickering light being rather annoying and this obviously nullifying any power savings, it also fills up my system logs with keyboard disconnection and reconnection log entries from the USB subsystem: May 10 02:20:13 yeono acpid: input device has been disconnected, fd 9 However, something is causing the monitors to then start turning fully off, and back on, repeatedly. Then sure enough the monitors do enter power savings mode in accordance with those timeouts, as expected. If I change Xscreensaver's power management settings to the following: Both monitors are connected directly to the computer with no intervening USB hub. My keyboard is hooked up through the USB hub built into one of the monitors, and the mouse is hooked up through the USB hub built into the other. Here is what xset q has to say about DPMS with the above-mentioned settings: DPMS (Energy Star): I'm running Xfce 4.8 and in its Power Manager have set "Put display to sleep" and "Switch off display" to Never in both the "On AC" and "On Battery" settings categories. When I disable power management through the Xscreensaver configuration tool, by unchecking "Power Management Enabled" in the Advanced tab, then everything works fine, except of course I don't get any power management on the monitors. ![]() I have two Dell U2412M monitors hooked up to a single graphics card (one over native DVI and one over HDMI output to DVI input). Ii chromium 1:1.99.1-7.Something weird is up with my Xscreensaver 5.15 configuration on Debian Wheezy. Versions of packages xscreensaver suggests: Versions of packages xscreensaver recommends: Versions of packages xscreensaver depends on: Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ:en Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND Kernel: Linux 5.15.0-3-amd64 (SMP w/8 CPU threads) Like it used to work for decades.ĪPT policy: (500, 'unstable'), (1, 'experimental') Instead, I want to just hammer the password and have it work, no matter how quickly the dialog gets displayed. That breaks decades of muscle memory and also stretches my patience, since I don't want to first have to instruct the computer to show the dialog before it allows me to punch in the password. With version 6, it loses all keystrokes until the dialog is actually displayed, which on my system sometimes takes a second or two. With version 5.x I started noticing that sometimes it would lose the first couple of characters when doing so (especially when typing fast). For the past decades, you could walk up to an XScreensaver-protected machine and hammer in the password before the dialog was shown, and it just worked.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |