[solved] xbindkeys problem

ccc1 · 2010-07-15 08:47:25

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)

Inxsible · 2010-07-15 14:26:40

ccc1 wrote:

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.

ccc1 · 2010-07-15 15:00:58

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 248
KeyPress 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: False
KeyRelease 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)

Inxsible · 2010-07-15 16:27:28

ccc1 wrote:

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 248
KeyPress 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: False
KeyRelease 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

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)

ccc1 · 2010-07-15 16:45:30

Inxsible wrote:

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)

Inxsible · 2010-07-15 16:49:04

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)

Inxsible · 2010-07-15 16:58:24

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)

ccc1 · 2010-07-15 17:13:45

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

Inxsible · 2010-07-15 17:19:23

That's cool. If you can mark the thread solved, that'd be cooler

ccc1 · 2010-07-15 17:20:15

done

Arch Linux

#1 2010-07-15 08:47:25

[solved] xbindkeys problem

#2 2010-07-15 14:26:40

Re: [solved] xbindkeys problem

#3 2010-07-15 15:00:58

Re: [solved] xbindkeys problem

#4 2010-07-15 16:27:28

Re: [solved] xbindkeys problem

#5 2010-07-15 16:45:30

Re: [solved] xbindkeys problem

#6 2010-07-15 16:49:04

Re: [solved] xbindkeys problem

#7 2010-07-15 16:58:24

Re: [solved] xbindkeys problem

#8 2010-07-15 17:13:45

Re: [solved] xbindkeys problem

#9 2010-07-15 17:19:23

Re: [solved] xbindkeys problem

#10 2010-07-15 17:20:15

Re: [solved] xbindkeys problem

Board footer