Tiny Core Linux
General TC => General TC Talk => Topic started by: GNUser on November 12, 2019, 02:06:28 PM
-
I run Pure64 10.1 on my laptop. I'd like the laptop's behavior to be identical regardless of whether its lid is open or closed. In the past, I found that the only way to achieve completely identical behavior is to disable the lid switch at the level of the kernel.
In Debian, I can find the lid's sysfs node (e.g., PNP0C0D:00) by running cat /proc/acpi/wakeup, then this command completely disables the lid switch by unbinding its driver:
echo 'PNP0C0D:00' | sudo tee /sys/bus/acpi/drivers/button/unbindIn Pure64, cat /proc/acpi/wakeup shows me that laptop lid's sysfs node is PNP0C0D:00 as expected, but notice what happens when I try to unbind the driver:
echo 'PNP0C0D:00' | sudo tee /sys/bus/acpi/drivers/button/unbind
PNP0C0D:00
tee: /sys/bus/acpi/drivers/button/unbind: I/O error
Can you please help me completely disable the lid switch? I'm aware of the acpi=off kernel boot parameter, but that has the unpleasant side effect of also disabling kernel's battery stats (which I need for one of my shell scripts). I'd like to disable only the lid switch.
-
Hi GNUser
I see laptop-mode-tools.tcz includes:
/usr/local/share/laptop-mode-tools/files/acpi/actions/lm_lid.sh
/usr/local/share/laptop-mode-tools/files/acpi/events/lm_lidMaybe they are of some use?
-
Hi, Rich. acpitool (not currently in repo) gets me part of the way there:
$ acpitool -w
Device S-state Status Sysfs node
---------------------------------------
1. HDEF S4 *disabled pci:0000:00:1b.0
2. USB1 S4 *enabled pci:0000:00:1d.0
---snip---
17. LID S3 *enabled platform:PNP0C0D:00
$ sudo acpitool -W 17
Changed status for wakeup device #17 (LID)
Device S-state Status Sysfs node
---------------------------------------
1. HDEF S4 *disabled pci:0000:00:1b.0
2. USB1 S4 *enabled pci:0000:00:1d.0
---snip---
17. LID S3 *disabled platform:PNP0C0D:00
However, even after the above, if laptop lid is closed then xscreensaver does not kick in after the appropriate number of minutes. So disabling the lid switch under acpi is not the whole story.
Any idea how to completely disable the lid switch via software (or at least make xscreensaver unaware of it)?
-
acpi is a red herring. Even if it is completely disabled with acpi=off kernel boot parameter, xscreensaver still refuses to kick in while laptop lid is closed.
xscreensaver must be aware of the lid switch some other way (BIOS? kernel? Xorg?). I'll contact the xscreensaver developer to see if he can point me in the right direction.
-
Hi GNUser
I'm not sure I'm following you. Are you saying the display won't blank with the lid closed?
-
My monitor stays on while lid is closed. I like it that way.
When I give the laptop some long-running job, I turn the brightness all the way down then close the lid just to keep my toddlers and baby from accidentally pressing any keys. I want the screensaver to kick in while the lid is closed, same as it would if the lid were open.
-
Hi, Core guys!
Sorry for interrupting your essential talk.
GNUser, why not to move towards allowing acpi power off your monitor while lid closed? And no matter, what screensaver has on its (his?) mind.
I use notebook in the same manner, put some task to work, and close lid. Monitor is powered off by acpi and things roll on.
Not trying to advice, as you are much more experienced, but do you remember about "xset dpmi a b c"?
-
Thank you, jazzbiker. That's perfectly sensible advice and would yield a great result. However, this is more about control at this point: I don't like the lid switch, so am on a war path to disable it >:(
(I'd do it mechanically, except that on my T400 the lid switch is actually a little magnet just below the display and above the Bluetooth icon. In the past I've "disabled" it by taping a small magnet in that area, but found that it was actually keeping the switch in the "lid closed" position, causing a wakeup-suspend loop when running some distros.)
P.S. xset is a great tip. I'm aware of it, and one of my startup jobs is actually xset s off; xset -dpms; xset s noblank to disable any interference from X.
-
It seems that opening and closing the laptop lid don't generate any libinput events?! Very strange.
bruno@box:~$ cat /proc/bus/input/devices
---snip---
I: Bus=0019 Vendor=0000 Product=0005 Version=0000
N: Name="Lid Switch"
P: Phys=PNP0C0D/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2a/PNP0C09:00/PNP0C0D:00/input/input1
U: Uniq=
H: Handlers=event1
B: PROP=0
B: EV=21
B: SW=1
# notice my laptop's lid switch is supposedly "event 1"
bruno@box:~$ tce-load -wi libinput
bruno@box:~$ sudo libinput debug-events
event6 POINTER_MOTION +2.02s 0.79/ 0.00 ( +1.00/ +0.00)
event6 POINTER_MOTION +2.04s 1.40/ 2.79 ( +1.00/ +2.00)
event6 POINTER_MOTION +2.05s 2.52/ 10.09 ( +1.00/ +4.00)
event6 POINTER_MOTION +2.08s 1.10/ 3.31 ( +1.00/ +3.00)
event6 POINTER_MOTION +2.09s 1.61/ 3.21 ( +1.00/ +2.00)
event6 POINTER_MOTION +2.12s 0.00/ 0.56 ( +0.00/ +1.00)
### in here I close and open the laptop lid. nothing related to event1 is logged as you can see.
event3 KEYBOARD_KEY +9.93s *** (-1) pressed
event3 KEYBOARD_KEY +10.05s *** (-1) pressed
If opening and closing the laptop lid doesn't cause any input device events to fire, how come xscreensaver knows when lid is closed? Something is aware that the lid is closed, because the xscreensaver's animations never start as long as laptop lid is closed.
-
This just in from xscreensaver's developer, Jamie Zawinski:
Q (GNUser): How does xscreensaver detect laptop lid switch state?
A (Zawinski): Basically, "it doesn't." It's all terrible. Everything about power management on Linux is laughable.
Oops. It seems I hit a nerve. Maybe I'm just going to leave this voodoo alone and settle for a workaround similar to what jazzbiker suggests. I feel defeated. You'd think it would be trivial to disable an input device.
-
Hi GNUser
### in here I close and open the laptop lid. nothing related to event1 is logged as you can see.
event3 KEYBOARD_KEY +9.93s *** (-1) pressed
event3 KEYBOARD_KEY +10.05s *** (-1) pressed
It appears closing and opening the lid causes keyboard pressed events without the corresponding keyboard released events.
-
No, those two keyboard (event3) events are from me pressing Control+c after I re-opened the lid. Opening and closing the lid causes nothing whatsoever to show up on the list.
-
Hi GNUser
I should have realized that was something else. The events are only 0.120 seconds apart.
-
Hi GNUser!
Is it your laptop with libreboot? May it entertain you with some funny tricks?
Have You tried Xfbdev?
-
Hi, jazzbiker.
Yes, it's my T400 ThinkPad with Libreboot. Alas, it does not entertain me with funny tricks.
Xfbdev is a good idea, except that I depend on some full-blown Xorg features.
I will try disabling acpi on my wife's laptop (Sony Vaio with stock BIOS) and seeing whether xscreensaver is still aware of the laptop's lid switch. If it's not, it would point to a low-level awareness of the lid switch on my Libreboot machine.
-
Hi GNUser
Does your machine report anything for:
cat /sys/module/button/parameters/lid_report_intervalIf it does, try setting it to 0 or -1.
-
Thank you, Rich.
My laptop reports 500.
I cannot set it to -1 ("Invalid argument"). I can set it to 0, but it does not seem to help (xscreensaver still refuses to kick in while lid is closed) :(
-
I set it to 500000 to see what would happen. xscreensaver still refuses to kick in when lid is closed.
I have to say this is the most stubborn issue I've ever had with GNU/Linux. It's usually a very malleable OS.
-
I found /proc/acpi/button/lid/LID/state which does seem to consistently accurately report the lid switch state. Getting warmer?
$ cat /proc/acpi/button/lid/LID/state
state: open
$ sleep 5; cat /proc/acpi/button/lid/LID/state # I close the lid after entering the command
state: closed
$ echo 0 | sudo tee /sys/module/button/parameters/lid_report_interval
$ sleep 5; cat /proc/acpi/button/lid/LID/state # I close the lid after entering the command
state: closed
$ echo 500000 | sudo tee /sys/module/button/parameters/lid_report_interval
$ sleep 5; cat /proc/acpi/button/lid/LID/state # I close the lid after entering the command
state: closed
$ sudo acpitool -W 17 # this disables the lid switch wakeup device
$ cat /proc/acpi/button/lid/LID/state
state: open
$ sleep 5; cat /proc/acpi/button/lid/LID/state # I close the lid after entering the command
state: closed
Bottomline from all the above: No matter what I do, I cannot disable the lid switch--but at least the output of cat /proc/acpi/button/lid/LID/state is always accurate with regard to whether the lid is open or closed.
Maybe there's a way to force the file to always say open? (Alas, I wouldn't expect chattr +i to work on the /proc virtual filesystem.)
-
Hi, GNUser!
Sorry again for my silly posts, but so much time spent struggling with this lid switch was enough to compile custom lid-less kernel. If you hate this lid switches, solve the problem once and forever.
Thanks for Your answers.
-
A last attempt before recompiling kernel: Finding a way to disable the button kernel module.
I took a look at the kernel's source code, and the module that enables the lid switch is called button
https://github.com/torvalds/linux/blob/master/drivers/acpi/button.c
button does not show up in output of lsmod or find /lib/modules/4.19.10-tiny
core64/kernel/ -name 'button.ko.gz' but does show up in output of ls /sys/module, so it's loaded and must be a kernel builtin. Therefore, it cannot be blacklisted with blacklist=<module_name> kernel boot parameter.
However, it seems there is a way (https://unix.stackexchange.com/a/468038) to disable built-in kernel modules: initcall_blacklist=<module's_initialization_function>. I can't find a function in button.c that has the __init attribute, so I tried blacklisting various functions in button.c that have _init in the name, to no avail.
Can someone help me figure out which initcall I should blacklist in order to prevent the button kernel module from being loaded (or some other way to disable that module short of recompiling kernel)? I realize it would probably disable both my lid switch and power button, but that's fine--I only use the power button to power on, never to poweroff.
-
Hi GNUser
Try:
initcall_blacklist=acpi_button_register_driver
-
Thank you, Rich, but no joy. The module still gets loaded.
-
Maybe you could use the acpid extension and write a rule to achieve what you wish to happen when the lid is closed?
-
acpid would be a great tool if I were looking to do something special when the kernel reports that the lid is closed.
However, what I want is for the kernel to never report to userland that the lid is closed--for it to either always report it as open or else ignore it completely.
-
Hi GNUser
Thank you, Rich, but no joy. The module still gets loaded.
Did dmesg log any output in response to the blacklist request?
-
Hmm, it did, but it doesn't look good:
$ dmesg | grep blacklist
Command line: BOOT_IMAGE=/boot/vmlinuz64 tce=sda2/tce opt=sda2 blacklist=pcspkr blacklist=uvcvideo tz=EST+5EDT,M3.2.0/2,M11.1.0/2 syslog lang=en_US.UTF-8 user=bruno initcall_blacklist=acpi_button_register_driver
Kernel command line: BOOT_IMAGE=/boot/vmlinuz64 tce=sda2/tce opt=sda2 blacklist=pcspkr blacklist=uvcvideo tz=EST+5EDT,M3.2.0/2,M11.1.0/2 syslog lang=en_US.UTF-8 user=bruno initcall_blacklist=acpi_button_register_driver
initcall_blacklist requires CONFIG_KALLSYMS
It seems that Pure64's kernel was compiled without the configuration option needed for initcall_blacklist to work. Darn.
-----
It the meantime, I tried my old trick of taping a magnet over the lid switch (my T400's lid switch is actually a little magnet above the bluetooth LED). However, doing this results in the switch always being in the "closed" state. I tried the boot parameter button.lid_init_state=open but it makes no difference--the magnet causes constant "closed" state.
-----
It seems I'm running out of options. I'll ask on the kernel mailing list just to make sure we aren't missing something.
-
Hi GNUser
... It the meantime, I tried my old trick of taping a magnet over the lid switch (my T400's lid switch is actually a little magnet above the bluetooth LED). However, doing this results in the switch always being in the "closed" state. I tried the boot parameter button.lid_init_state=open but it makes no difference--the magnet causes constant "closed" state. ...
You could try weakening/dispersing the magnetic field by placing something metallic between the lid magnet and the switch. Maybe
several layers of aluminum foil or a piece of sheet steel (top of a tuna can).
-
Excellent idea! I'll try that, or some magnetic insulation tape if it doesn't work.
Either way, I'll stop bothering you guys with this miniscule issue. If I hear something helpful back from the kernel guys, I'll share it.
Cheers,
gnuser
-
Hi GNUser
... I'll stop bothering you guys with this miniscule issue. ...
No bother. It allowed me to spend some quality time looking through the /proc and /sys file systems as well as driver code. :)
-
I also enjoy this kind of quality time...much to my wife's chagrin ;)
-
I heard back from the kernel guys, so here's a quick update.
Rich was right: If the kernel supports initcall_blacklist then the correct kernel boot parameter to disable the button driver is initcall_blacklist=acpi_button_register_driver
If the kernel does not support initcall_blacklist, unbinding all of the button driver's devices has the same effect as disabling the driver. Here's how to find all the devices, unbind them, and confirm that they are unbound:
# ls /sys/bus/acpi/drivers/button
LNXPWRBN:00 PNP0C0D:00 PNP0C0E:00 bind uevent unbind
# echo "LNXPWRBN:00" > /sys/bus/acpi/drivers/button/unbind
# echo "PNP0C0D:00" > /sys/bus/acpi/drivers/button/unbind
# echo "PNP0C0E:00" > /sys/bus/acpi/drivers/button/unbind
# ls /sys/bus/acpi/drivers/button
bind uevent unbind
I've done the unbinding, but xscreensaver still refuses to kick in if lid is closed. I can only conclude that either a) there is a software component (X? kernel? video driver?) that can detect the sensor's state without the button driver's help or b) the T400 has a second lid sensor somewhere that does not depend on the button driver.
-
I am very close to a solution. I discovered that disabling the lid switch (via the unbind method above) is not enough to make the OS totally oblivious to the lid switch state because the touchpad generates noise while the laptop lid is closed.
$ cat /proc/bus/input/devices
---snip---
I: Bus=0011 Vendor=0002 Product=0007 Version=01b1
N: Name="SynPS/2 Synaptics TouchPad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input5
U: Uniq=
H: Handlers=mouse0 event5
B: PROP=1
B: EV=b
B: KEY=420 30000 0 0 0 0
B: ABS=11000003
I: Bus=0011 Vendor=0002 Product=000a Version=0000
N: Name="TPPS/2 IBM TrackPoint"
P: Phys=synaptics-pt/serio0/input0
S: Sysfs=/devices/platform/i8042/serio1/serio2/input/input7
U: Uniq=
H: Handlers=mouse1 event6
B: PROP=21
B: EV=7
B: KEY=70000 0 0 0 0
B: REL=3
---snip---
$ sudo cat /dev/input/event5 # close the lid without touching the touchpad, then open the lid and find:
»Ò]ºö »Ò]ºö »Ò]èÛ
J »Ò]èÛ
( »Ò]èÛ
»Ò]èÛ
% »Ò]èÛ
»Ò]èÛ
E »Ò]èÛ
---snip---
The noise apparently is enough to keep xscreensaver from kicking in while the lid is closed.
Disabling the touchpad using "xinput disable <touchpad's xinput id>" is not enough--I have to either disable the touchpad at the kernel level:
$ cd /sys/bus/serio/drivers/psmouse
$ echo serio1 | sudo tee unbind
Or else via xorg.conf:
# Xorg :1 -configure
# mkdir /etc/X11
# mv /root/xorg.conf.new /etc/X11/xorg.conf
# echo 'Section "InputClass"
Identifier "disable touchpad"
MatchProduct "SynPS/2 Synaptics TouchPad"
Option "Ignore" "on"
EndSection' >>/etc/X11/xorg.conf
$ echo "etc/X11/xorg.conf" >>/opt/.filetool.lst
$ filetool.sh -b
$ sudo reboot
Unbinding the lid switch PLUS disabling the touchpad using one of the two methods above causes all applications (including xscreensaver) to always behave as if the laptop lid were open. Yay! ;D
The only problem with using one of these methods to disable the touchpad (which I don't use anyway) is that they also disable the trackpoint (which I do use). It seems the trackpoint (/dev/input/event6) is somehow a child device of the touchpad (/dev/input/event5)?
*****
So here is my last question about this issue: Can you help me disable the touchpad (via driver unbinding or via xorg.conf) without also disabling the trackpoint?
*****
-
https://wiki.archlinux.org/index.php/Lenovo_ThinkPad_T400
says you should add a device for /dev/input/mice to use the trackpad. Worth a try combining it with your ignore segment.
-
Hi GNUser
Here's your touchpad:
S: Sysfs=/devices/platform/i8042/serio1/input/input5
Here's your trackpoint:
S: Sysfs=/devices/platform/i8042/serio1/serio2/input/input7
It's possible unbinding from serio1 also killed the connection to serio2.
$ cat /proc/bus/input/devices
$ sudo cat /dev/input/event5 # close the lid without touching the touchpad, then open the lid and find:
»Ò]ºö »Ò]ºö »Ò]èÛ
J »Ò]èÛ
( »Ò]èÛ
»Ò]èÛ
% »Ò]èÛ
»Ò]èÛ
E »Ò]èÛ
---snip---
You should repeat that test with /dev/input/event6 to make sure it's not noisy too.
I have a laptop that I rarely use because I hate laptops. Anyway, last May I finally found out how to disable that annoying touchpad
that would do things every time I accidentally bumped it with the heel of my hand. I don't recall the details (hows and whys) but I
think I tracked down all the changes involved.
.xsession provides an entry for launching something called .mouse_config:
/usr/local/bin/Xorg -nolisten tcp &
export XPID=$!
waitforX || ! echo failed in waitforX || exit
"$DESKTOP" 2>/tmp/wm_errors &
export WM_PID=$!
[ -x ./.setbackground ] && ./.setbackground
[ -x ./.mouse_config ] && ./.mouse_config &
[ $(which "$ICONS".sh) ] && ${ICONS}.sh &
[ -d ".X.d" ] && find ".X.d" -type f -print | while read F; do . "$F"; done
This is the contents of my .mouse_config:
xset m 3/1 0
xmodmap -e 'pointer = 1 2 3 4 5'
This is my /etc/X11/xorg.conf:
Section "ServerLayout"
Identifier "X.org Configured"
Screen 0 "Screen0" 0 0
Screen 1 "Screen1" RightOf "Screen0"
Screen 2 "Screen2" RightOf "Screen1"
InputDevice "Mouse0" "CorePointer"
InputDevice "Mouse1"
InputDevice "Keyboard0" "CoreKeyboard"
Option "AllowEmptyInput" "off"
EndSection
Section "Files"
ModulePath "/usr/local/lib/X11/modules"
FontPath "/usr/lib/X11/fonts/misc/"
FontPath "/usr/lib/X11/fonts/TTF/"
FontPath "/usr/lib/X11/fonts/OTF/"
FontPath "/usr/lib/X11/fonts/Type1/"
FontPath "/usr/lib/X11/fonts/100dpi/"
FontPath "/usr/lib/X11/fonts/75dpi/"
EndSection
Section "Module"
Load "record"
Load "glx"
Load "extmod"
Load "dri2"
Load "dri"
Load "dbe"
EndSection
Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
EndSection
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/dev/input/mice"
Option "ZAxisMapping" "4 5 6 7"
EndSection
Section "InputDevice"
Identifier "Mouse1"
Driver "synaptics"
Option "TouchpadOff" "1"
EndSection
Section "Monitor"
Identifier "Monitor0"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
EndSection
Section "Monitor"
Identifier "Monitor1"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
EndSection
Section "Monitor"
Identifier "Monitor2"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
EndSection
Section "Device"
### Available Driver options are:-
### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
### <string>: "String", <freq>: "<f> Hz/kHz/MHz",
### <percent>: "<f>%"
### [arg]: arg optional
#Option "NoAccel" # [<bool>]
#Option "SWcursor" # [<bool>]
#Option "Dac6Bit" # [<bool>]
#Option "Dac8Bit" # [<bool>]
#Option "BusType" # [<str>]
#Option "CPPIOMode" # [<bool>]
#Option "CPusecTimeout" # <i>
#Option "AGPMode" # <i>
#Option "AGPFastWrite" # [<bool>]
#Option "AGPSize" # <i>
#Option "GARTSize" # <i>
#Option "RingSize" # <i>
#Option "BufferSize" # <i>
#Option "EnableDepthMoves" # [<bool>]
#Option "EnablePageFlip" # [<bool>]
#Option "NoBackBuffer" # [<bool>]
#Option "DMAForXv" # [<bool>]
#Option "FBTexPercent" # <i>
#Option "DepthBits" # <i>
#Option "PCIAPERSize" # <i>
#Option "AccelDFS" # [<bool>]
#Option "IgnoreEDID" # [<bool>]
#Option "CustomEDID" # [<str>]
#Option "DisplayPriority" # [<str>]
#Option "PanelSize" # [<str>]
#Option "ForceMinDotClock" # <freq>
#Option "ColorTiling" # [<bool>]
#Option "VideoKey" # <i>
#Option "RageTheatreCrystal" # <i>
#Option "RageTheatreTunerPort" # <i>
#Option "RageTheatreCompositePort" # <i>
#Option "RageTheatreSVideoPort" # <i>
#Option "TunerType" # <i>
#Option "RageTheatreMicrocPath" # <str>
#Option "RageTheatreMicrocType" # <str>
#Option "ScalerWidth" # <i>
#Option "RenderAccel" # [<bool>]
#Option "SubPixelOrder" # [<str>]
#Option "ClockGating" # [<bool>]
#Option "VGAAccess" # [<bool>]
#Option "ReverseDDC" # [<bool>]
#Option "LVDSProbePLL" # [<bool>]
#Option "AccelMethod" # <str>
#Option "DRI" # [<bool>]
#Option "ConnectorTable" # <str>
#Option "DefaultConnectorTable" # [<bool>]
#Option "DefaultTMDSPLL" # [<bool>]
#Option "TVDACLoadDetect" # [<bool>]
#Option "ForceTVOut" # [<bool>]
#Option "TVStandard" # <str>
#Option "IgnoreLidStatus" # [<bool>]
#Option "DefaultTVDACAdj" # [<bool>]
#Option "Int10" # [<bool>]
#Option "EXAVSync" # [<bool>]
#Option "ATOMTVOut" # [<bool>]
#Option "R4xxATOM" # [<bool>]
#Option "ForceLowPowerMode" # [<bool>]
#Option "DynamicPM" # [<bool>]
#Option "NewPLL" # [<bool>]
#Option "ZaphodHeads" # <str>
Identifier "Card0"
Driver "radeon"
BusID "PCI:1:5:0"
EndSection
Section "Device"
### Available Driver options are:-
### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
### <string>: "String", <freq>: "<f> Hz/kHz/MHz",
### <percent>: "<f>%"
### [arg]: arg optional
#Option "ShadowFB" # [<bool>]
#Option "Rotate" # <str>
#Option "fbdev" # <str>
#Option "debug" # [<bool>]
Identifier "Card1"
Driver "fbdev"
BusID "PCI:1:5:0"
EndSection
Section "Device"
### Available Driver options are:-
### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
### <string>: "String", <freq>: "<f> Hz/kHz/MHz",
### <percent>: "<f>%"
### [arg]: arg optional
#Option "ShadowFB" # [<bool>]
#Option "DefaultRefresh" # [<bool>]
#Option "ModeSetClearScreen" # [<bool>]
Identifier "Card2"
Driver "vesa"
BusID "PCI:1:5:0"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"
SubSection "Display"
Viewport 0 0
Depth 1
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 4
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 8
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 15
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 16
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 24
EndSubSection
EndSection
Section "Screen"
Identifier "Screen1"
Device "Card1"
Monitor "Monitor1"
SubSection "Display"
Viewport 0 0
Depth 1
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 4
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 8
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 15
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 16
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 24
EndSubSection
EndSection
Section "Screen"
Identifier "Screen2"
Device "Card2"
Monitor "Monitor2"
SubSection "Display"
Viewport 0 0
Depth 1
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 4
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 8
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 15
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 16
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 24
EndSubSection
EndSection
I also have /etc/X11/xorg.conf.d/50-synaptics.conf file. I'm not sure it actually gets used. You're welcome to dig through the
attached Xorg.0.log file to see if it is:
# Example xorg.conf.d snippet that assigns the touchpad driver
# to all touchpads. See xorg.conf.d(5) for more information on
# InputClass.
# DO NOT EDIT THIS FILE, your distribution will likely overwrite
# it when updating. Copy (and rename) this file into
# /etc/X11/xorg.conf.d first.
# Additional options may be added in the form of
# Option "OptionName" "value"
#
Section "InputClass"
Identifier "touchpad catchall"
Driver "synaptics"
MatchIsTouchpad "on"
Option "TouchpadOff" "1"
# This option is recommend on all Linux systems using evdev, but cannot be
# enabled by default. See the following link for details:
# http://who-t.blogspot.com/2010/11/how-to-ignore-configuration-errors.html
# MatchDevicePath "/dev/input/event*"
EndSection
Section "InputClass"
Identifier "touchpad ignore duplicates"
MatchIsTouchpad "on"
MatchOS "Linux"
MatchDevicePath "/dev/input/mouse1"
Option "Ignore" "on"
Option "TouchpadOff" "1"
EndSection
And a copy of /proc/bus/input/devices so you can see what's assigned to where:
I: Bus=0019 Vendor=0000 Product=0001 Version=0000
N: Name="Power Button"
P: Phys=PNP0C0C/button/input0
S: Sysfs=/devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0
U: Uniq=
H: Handlers=kbd event0
B: PROP=0
B: EV=3
B: KEY=100000 0 0 0
I: Bus=0019 Vendor=0000 Product=0005 Version=0000
N: Name="Lid Switch"
P: Phys=PNP0C0D/button/input0
S: Sysfs=/devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input1
U: Uniq=
H: Handlers=event1
B: PROP=0
B: EV=21
B: SW=1
I: Bus=0019 Vendor=0000 Product=0001 Version=0000
N: Name="Power Button"
P: Phys=LNXPWRBN/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
U: Uniq=
H: Handlers=kbd event2
B: PROP=0
B: EV=3
B: KEY=100000 0 0 0
I: Bus=0011 Vendor=0001 Product=0001 Version=ab41
N: Name="AT Translated Set 2 keyboard"
P: Phys=isa0060/serio0/input0
S: Sysfs=/devices/platform/i8042/serio0/input/input3
U: Uniq=
H: Handlers=sysrq kbd event3
B: PROP=0
B: EV=120013
B: KEY=4 2000000 3803078 f800d001 feffffdf ffefffff ffffffff fffffffe
B: MSC=10
B: LED=7
I: Bus=0010 Vendor=001f Product=0001 Version=0100
N: Name="PC Speaker"
P: Phys=isa0061/input0
S: Sysfs=/devices/platform/pcspkr/input/input4
U: Uniq=
H: Handlers=kbd event4
B: PROP=0
B: EV=40001
B: SND=6
I: Bus=0019 Vendor=0000 Product=0006 Version=0000
N: Name="Video Bus"
P: Phys=LNXVIDEO/video/input0
S: Sysfs=/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:01/LNXVIDEO:00/input/input5
U: Uniq=
H: Handlers=kbd event5
B: PROP=0
B: EV=3
B: KEY=3e000b 0 0 0 0 0 0 0
I: Bus=0019 Vendor=0000 Product=0000 Version=0000
N: Name="HP WMI hotkeys"
P: Phys=wmi/input0
S: Sysfs=/devices/virtual/input/input6
U: Uniq=
H: Handlers=kbd event6
B: PROP=0
B: EV=33
B: KEY=40 0 0 0 10007 0 0 2100400 0 0 0 0
B: MSC=10
B: SW=22
I: Bus=0003 Vendor=046d Product=c52f Version=0111
N: Name="Logitech USB Receiver"
P: Phys=usb-0000:00:13.0-1/input0
S: Sysfs=/devices/pci0000:00/0000:00:13.0/usb5/5-1/5-1:1.0/input/input7
U: Uniq=
H: Handlers=mouse0 event7
B: PROP=0
B: EV=17
B: KEY=ffff0000 0 0 0 0 0 0 0 0
B: REL=143
B: MSC=10
I: Bus=0003 Vendor=046d Product=c52f Version=0111
N: Name="Logitech USB Receiver"
P: Phys=usb-0000:00:13.0-1/input1
S: Sysfs=/devices/pci0000:00/0000:00:13.0/usb5/5-1/5-1:1.1/input/input8
U: Uniq=
H: Handlers=kbd event8
B: PROP=0
B: EV=1f
B: KEY=4837fff 72ff32d bf544446 0 0 1 20f90 8b17c000 677bfa d9415fed 9ed680 4400 0 10000002
B: REL=40
B: ABS=1 0
B: MSC=10
I: Bus=0011 Vendor=0002 Product=0007 Version=01b1
N: Name="SynPS/2 Synaptics TouchPad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input9
U: Uniq=
H: Handlers=mouse1 event9
B: PROP=9
B: EV=b
B: KEY=6420 0 30000 0 0 0 0 0 0 0 0
B: ABS=2608000 11000003
I: Bus=0003 Vendor=064e Product=f203 Version=0421
N: Name="HP Webcam-101"
P: Phys=usb-0000:00:12.2-3/button
S: Sysfs=/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3:1.0/input/input10
U: Uniq=
H: Handlers=kbd event10
B: PROP=0
B: EV=3
B: KEY=100000 0 0 0 0 0 0
I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="HDA ATI SB Mic"
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:14.2/sound/card0/input11
U: Uniq=
H: Handlers=event11
B: PROP=0
B: EV=21
B: SW=10
I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="HDA ATI SB Headphone"
P: Phys=ALSA
S: Sysfs=/devices/pci0000:00/0000:00:14.2/sound/card0/input12
U: Uniq=
H: Handlers=event12
B: PROP=0
B: EV=21
B: SW=4
-
You should repeat that test with /dev/input/event6 to make sure it's not noisy too.
Good idea. I did, and can confirm no noise from event6 (trackpoint). The touchpad is the only fly in the ointment.
BTW I was mistaken in my prior post--disabling touchpad via xorg.conf doesn't actually help. Only the unbind serio1 does the trick.
I tried to avoid unbinding serio1 and, instead, using this command to discard the noise that the touchpad generates (note: evtest not currently in the repository)...
$ evtest --grab /dev/input/event5 >/dev/null 2>&1...but, interestingly, discarding the noise doesn't help. If the touchpad makes any noise--even if noise is discarded--it prevents xscreensaver from kicking in.
Only this command actually prevents the touchpad from getting in my way:
$ cd /sys/bus/serio/drivers/psmouse
$ echo serio1 | sudo tee unbind
It's possible unbinding from serio1 also killed the connection to serio2.
Well worded. Yes, I think this is exactly what it has come down to. I'm stuck here. I need to unbind the touchpad, but the trackpoint/"nipple mouse" (serio2) needs to remain operational.
-
Yes, Rich, you are correct as usual. Unbinding serio1 causes serio2 to be unbound as well :'(
$ sudo su
# cd /sys/bus/serio/drivers/psmouse
# ls
bind description serio1 uevent
bind_mode module serio2 unbind
# echo serio1 >unbind
# ls
bind description uevent
bind_mode module unbind
-
Maybe unbinding serio1 is more than what I need? Maybe there is a way to somehow disable things in the udev tree up to and including input5 (i.e., disable event5 and input5), while leaving serio1 alone?
# udevadm info --attribute-walk --name=/dev/input/event5
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/platform/i8042/serio1/input/input5/event5':
KERNEL=="event5"
SUBSYSTEM=="input"
DRIVER==""
looking at parent device '/devices/platform/i8042/serio1/input/input5':
KERNELS=="input5"
SUBSYSTEMS=="input"
DRIVERS==""
ATTRS{uniq}==""
ATTRS{properties}=="1"
ATTRS{phys}=="isa0060/serio1/input0"
ATTRS{name}=="SynPS/2 Synaptics TouchPad"
looking at parent device '/devices/platform/i8042/serio1':
KERNELS=="serio1"
SUBSYSTEMS=="serio"
DRIVERS=="psmouse"
ATTRS{resetafter}=="5"
ATTRS{resolution}=="200"
ATTRS{description}=="i8042 AUX port"
ATTRS{firmware_id}=="PNP: PNP0f13"
ATTRS{protocol}=="SynPS/2"
ATTRS{rate}=="80"
ATTRS{bind_mode}=="auto"
ATTRS{resync_time}=="0"
looking at parent device '/devices/platform/i8042':
KERNELS=="i8042"
SUBSYSTEMS=="platform"
DRIVERS=="i8042"
ATTRS{driver_override}=="(null)"
looking at parent device '/devices/platform':
KERNELS=="platform"
SUBSYSTEMS==""
DRIVERS==""
I'm terrible at writing udev rules. Am I on the right track?
-
It was just a shot in the dark, but I tried to create this /etc/udev/rules.d/10-disable-touchpad.rules then include it in mydata.tgz and reboot:
ACTION=="add", SUBSYSTEM=="input", ATTR{phys}=="isa0060/serio1/input0", OPTIONS="ignore_device"It had no effect (which is not surprising given that I am an utter noobie when it comes to udev).
-
SOLVED! ;D ;D ;D ;D ;D ;D ;D ;D
1. Disable lid switch by unbinding its driver:
# echo "PNP0C0D:00" >/sys/bus/acpi/drivers/button/unbind
# echo "PNP0C0E:00" >/sys/bus/acpi/drivers/button/unbind
2. Disable touchpad by unplugging its ribbon (the ribbon is just under the palmrest--it was trivial to find and disconnect)
Now all applications (including xscreensaver) behave identically regardless of whether laptop lid is open or closed. The trackpoint and its three buttons (just under the spacebar) are fully operational.
(It's odd that the trackpoint is always a child of the touchpad on software level, even though on hardware level the two are independent. Oh, well.)
-
Hi GNUser
I know it's late in the game, but I stumbled upon this:
https://www.x.org/releases/current/doc/man/man4/void.4.xhtml
It's an Xorg void input driver that basically does nothing. You could change your touchpads InputDevice section
From:
Driver "synaptics"To:
Driver "void"The caveat is the driver is not in the repository so you would need to compile it yourself.
-
Interesting. I'll try it when I get a chance. Thank you!
-
Even after running the commands in Reply #39, if I suspend my laptop with
sudo sh -c "echo mem >/sys/power/state"
then close the lid then open the lid, something causes the laptop to wake from suspend! So the lid switch is not completely dead yet :o
It turns out that even after lid switch is unbinded from the button driver, acpi can still detect the lid switch state and cause the laptop to wake up from suspend when the lid is opened. cat /proc/acpi/wakeup confirms this. Maybe the issue is that I'm running the commands that unbind the lid switch from the button driver after acpi has already detected the lid switch...
So the (hopefully) final solution is to do the things in Reply #39 plus run this command, which toggles LID's wakup status:
sudo sh -c 'echo LID >/proc/acpi/wakeup'
(Let's see how long it takes to me to truly, fully, completely kill the lid switch...)