You are not logged in.
hi,
i'm running a script, if the key combination associated to XF86Display is pressed, i.e.
"toggle-monitor"
XF86Display
in my .xbindkeysrc
Unfortunatly the script is also run, if i open the lid of my laptop.
i don't use a desktop enviroment, just dwm. anyone got an idea what is triggering the XF86Display "keypress"?
ccc1
Last edited by ccc1 (2010-07-15 17:19:59)
Offline
i don't use a desktop enviroment, just dwm. anyone got an idea what is triggering the XF86Display "keypress"?
Well we know what is triggering the keypress -- opening of the lid.
Question is, how do we stop it?
I am not sure this will work : but start xev and see if closing/opening of your lid gives you any keycodes. If it does, you are in luck and maybe you can disable them.
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
i ran xev and closing and opening the lid lead to this output:
MappingNotify event, serial 27, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 8, count 248KeyPress event, serial 28, synthetic NO, window 0x1e00001,
root 0xc0, subw 0x0, time 12779933, (480,495), root:(481,510),
state 0x0, keycode 235 (keysym 0x1008ff59, XF86Display), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: FalseKeyRelease event, serial 28, synthetic NO, window 0x1e00001,
root 0xc0, subw 0x0, time 12779933, (480,495), root:(481,510),
state 0x0, keycode 235 (keysym 0x1008ff59, XF86Display), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
As a workaround i use XF86Wlan in my .xbindkeyrc for switching monitor outputs, but i still would be interested what is causing this behaviour. disabling hal or dbus didn't help.
ccc1
Last edited by ccc1 (2010-07-15 15:36:07)
Offline
i ran xev and closing and opening the lid lead to this output:
MappingNotify event, serial 27, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 8, count 248KeyPress event, serial 28, synthetic NO, window 0x1e00001,
root 0xc0, subw 0x0, time 12779933, (480,495), root:(481,510),
state 0x0, keycode 235 (keysym 0x1008ff59, XF86Display), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: FalseKeyRelease event, serial 28, synthetic NO, window 0x1e00001,
root 0xc0, subw 0x0, time 12779933, (480,495), root:(481,510),
state 0x0, keycode 235 (keysym 0x1008ff59, XF86Display), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: FalseAs a workaround i use XF86Wlan in my .xbindkeyrc for switching monitor outputs, but i still would be interested what is causing this behaviour. disabling hal or dbus didn't help.
ccc1
As expected. opening/closing the lid does trigger Xf86Display, because normally when you close the lid, you expect that the display will switch to an external monitor through a docking station, or if not connected, it will simply switch off the display to save power.
so you are trying to get both the laptop display and the external display to work together?
If you have 2 monitors and would like to use them simultaneously, I would simply use xrandr to set them up. Can you tell me what you are trying to do exactly?
Last edited by Inxsible (2010-07-15 16:28:47)
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
If you have 2 monitors and would like to use them simultaneously, I would simply use xrandr to set them up. Can you tell me what you are trying to do exactly?
I'm just trying to use the key combo fn+f7 (it also generates the xf86display keypress event) for toggeling between different multi monitor views (only external, only internal, both). Script is working fine.
so i set my .xbindkeysrc up like this:
"toggle-monitor"
XF86Display
hitting fn+f7 toggles the views now as expected.
but in certain cases i get undesired behaviour, since opening the lid also executes my script.
i thought there might be an easy way to stop generating the xf86display event if i open the lid.
but as i wrote before, i'm now using fn+f5 to execute my script and everthing works perfect.
ccc1
Last edited by ccc1 (2010-07-15 16:47:21)
Offline
Is that a thinkpad you have?
if so, you can probably catch the lid open/close event using thinkpad-acpi, and then simply not do anything on it.
I am not sure if other brands have similar options.
Last edited by Inxsible (2010-07-15 16:49:55)
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
Another thing that you could do is use acpi-event to catch the event
Create a file /etc/acpi/events/lidevent to look like (BACK UP ORIGINAL IF EXISTS):
event=button[ /]lid
action=/etc/acpi/lidbtn.sh %e
Create another file /etc/acpi/lidbtn.sh and since you don't want any action on your lid open/close, your /etc/acpi/lidbtn.sh will be
#!/bin/bash
exit
You can also perform other tasks in lidbtn if needed. For eg. switching off/pausing music shutting off wired ethernet connections. possibilities are endless
Let me know if that works
Last edited by Inxsible (2010-07-15 17:01:28)
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
I'm already using a script that gets executed via acpi events, if i open or close the lid.
i use it in the case the laptop is docked:
open lid -> both monitors active
close lid -> only external
i think i just use fn+f5 for toggeling the monitor view, instead of fn+f7. it's fine, but thanks for your help!
ccc1
Offline
That's cool. If you can mark the thread solved, that'd be cooler
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
done
Offline