Discovered a workaround - turning off xrandr plugin is ok, but I still think that there should be an action exposed in the g-k-p for Toggle Displays, so the user can change the shortcut keys etc.

gconftool-2 -s /apps/gnome_settings_daemon/plugins/xrandr/active -t bool false

Bastien, Peter, opinions (not on the patch, obviously)?

The question is, why would you want to disable it. It's what's written on the keyboard...

i'm not sure why one would want to move that key or use exactly that combination for something else.
however, keybinding-properties then shouldn't allow assigning that shortcut to another function and warn about this shortcut being reserved.

(In reply to comment #4)
> however, keybinding-properties then shouldn't allow assigning that shortcut to
> another function and warn about this shortcut being reserved.

The only way I can think of to do this for keys that g-k-p doesn't manage itself - short of keeping a hardcoded list which would be a maintenance nightmare and probably wrong most of the time - would be to try to grab the key ourselves prior to setting it, and abort and disallow the shortcut if that grab fails. Any better ideas?

I think that'd be a good behaviour anyway. Usually, the gnome stack is the first lot of programs to start so we're mostly guaranteed the shortcuts we need anyway.
If for some reason some other program reserved a key combination already not being able to set it seems sensible.

I'm picturing something like:
"This shortcut is not available, it is already in use by another application."

XGrabKey throws a BadAccess for already-grabbed combinations so that should be possible to do. However, you can't really tell which app already has the grab, that may result in quite a few bugreports and complaints.

However, the issue you then have is that you set a shortcut once and it's not available next login because it's blocked by another app. Which isn't ideal either, I'm not sure what to do in that case though. How is that handled currently?

If something runs prior to g-s-d and takes away its shortcuts, g-s-d will simply silently (except for some log output) not grab the keys and thus not handle the shortcut. There is currently no additional error handling with regards to failed grabs.

(In reply to comment #3)
> The question is, why would you want to disable it. It's what's written on the
> keyboard...

Bastien, Peter,

The main reason to turn it off is that the graphics driver does not support xrandr, and I need to be able to set the Fn-F7 shortcut to execute a custom script (e.e. disper: http://willem.engen.nl/projects/disper/) in order to be able to have a functional Fn-F7 shortcut.

Many people use the NVIDIA binary driver (as evidenced by the latest phoronix graphics survey here http://www.phoronix.com/scan.php?page=article&item=phx_2009_survey_results&num=2) so I believe this is a very valid reason.
The NVIDIA bindary driver does not at this point support xrandr and there is no clear prospect in sight that it will support xrandr in the near future. Maybe the real solution would be to have customizability in the xrandr plugin, not g-k-p, I don't know, but I think the problem is quite real.

The second reason is that I might not be happy with the default behavior of Fn-F7 and want to write my own script, to handle it. For one, the default behavior cycles through many different combinations of monitor/resolution - not a fun thiing to be doing when you're in a conference room and the project takes 5 seconds just to pick up the signal from your computer - you can easily get lost while pressing Fn-F7 for a good amount of time. The current script that I use only toggles between 2 modes - presentation mode and primary display. I realize this is not good for everyone - imo customizability would be very nice for the above reasons.

(In reply to comment #4)
> i'm not sure why one would want to move that key or use exactly that
> combination for something else.

Another point I would like to make.

The above question can just as effectively be applied to: Sound Volume Up/Down, play/Pause/Eject or any of the other shortcut keys in g-k-p.


Why would I be able to customize the multimedia keys, but not Fn-F7? They are different on different machines? Sure, but so could Fn-F7 be, no?

"Heck, I could customize Alt-Tab, but I cannot customize Fn-F7? Why not?"

I hope you can see how this might look from the point of view of a confused user.

Thanks for listening.

I agree with the reporter.  In my case, an external monitor is on the left of my T42 ThinkPad laptop and there is no way to change this setup in my small work area.  When I use Fn+F7, the external monitor is always placed on the right.  This is a pain when moving the mouse cursor from one display to the other.

If I could configure gnome to change this to the left (when using the hotkey combo) that would work, but another option would be just to use my own script for Fn+F7 - if I could prevent gnome-settings-daemon from grabbing the Fn+F7 XF86Display key.

It would be great if there was a way to disable gnome-settings-daemon from ursurping certain hotkeys when this is undesirable.  Ideally there would be a choice for each hotkey that the gnome-settings-daemon might use.

(In reply to comment #9)
> (In reply to comment #4)
> > i'm not sure why one would want to move that key or use exactly that
> > combination for something else.
> 
> Another point I would like to make.
> 
> The above question can just as effectively be applied to: Sound Volume Up/Down,
> play/Pause/Eject or any of the other shortcut keys in g-k-p.

Except that's not a good reason. Just because we got it wrong for those keys doesn't mean we should get it wrong again.

See https://bugzilla.gnome.org/show_bug.cgi?id=494210

We would want users to be able to set Ctrl+Alt+P as a "play/pause" key, whilst still handling the "play" keys available on some keyboards.

In your case (which is to work around a broken driver), you could simply change the keysym of the Fn+F7 key, and add a custom keybindings as per usual.

Bastien Nocera wrote:
> In your case (which is to work around a broken driver), you could simply change
> the keysym of the Fn+F7 key, and add a custom keybindings as per usual.

Doesn't work - or at least I don't know how to make it work.  Fn+F7 generates an acpi event: 
$ acpi_listen
ibm/hotkey HKEY 00000080 00001007
-----------------------------------------------------------------------------------------------------

If I run xev and press Fn+F7 I get the following output:
VisibilityNotify event, serial 30, synthetic NO, window 0x4600001,
    state VisibilityFullyObscured

VisibilityNotify event, serial 30, synthetic NO, window 0x4600001,
    state VisibilityUnobscured

Expose event, serial 30, synthetic NO, window 0x4600001,
    (0,0), width 178, height 10, count 3

Expose event, serial 30, synthetic NO, window 0x4600001,
    (0,10), width 10, height 58, count 2

Expose event, serial 30, synthetic NO, window 0x4600001,
    (68,10), width 110, height 58, count 1

Expose event, serial 30, synthetic NO, window 0x4600001,
    (0,68), width 178, height 110, count 0
-----------------------------------------------------------------------------------------------------

$ xmodmap -pke shows the following:
keycode 235 = XF86Display NoSymbol XF86Display
----------------------------------------------------------------------------------------------------

If I go to System > Preferences > Keyboard Shortcuts and create a shortcut to run my bash script, when I press Fn+F7 "XF86Display" is what shows up there.  When I press Fn+F7 now, my bash script seems to execute along with the default gnome-settings-daemon action.  The result is that the display switches to the external monitor and I can't switch it back with subsequent presses of Fn+F7.

I tried putting a line in .Xmodmap for keycode 235 = to break the connection between XF86Display and the acpi event, but with this edit, nothing happens when I press Fn+F7.  If I execute the following command as root: "/etc/init.d/acpid restart", then I can execute my script with Fn+F7, but after a reboot I have to again run the command "/etc/init.d/acpid restart" before Fn+F7 will work with my script in /etc/apci/events (and /etc/acpi/actions).  Running "/etc/init.d/acpid restart" at every boot is unacceptable.

My bash script works fine if I execute it with another method besides Fn+F7.  If this bug is not going to be fixed, I would at least like to know which file I can edit to stop gnome-settings-daemon from acting on this one hotkey combo, Fn+F7.  I do not want to disable gnome-settings-daemon entirely.  It's just that Fn+F7 is the default way to switch displays in ThinkPad laptops.  It works as I want in KDE, but not in Gnome.

Right after I posted the above, a possible solution came to me.  And it works!

I edited /home/~/.Xmodmap and I added the following:
keycode 235 = F30

After a reboot I went to System > Preferences > Keyboard Shortcuts and added the shortcut for my bash script.  When I pressed Fn+F7, F30 was displayed.  Now when I press Fn+F7, my bash script is executed and gnome-settings-daemon doesn't act on it.