Bug 22185

The problem here is that the functional key does not have "standard" keycode.

A couple of questions:

What is the driver you are using? If you do not know, please provide "xprop -root | grep XKB".

What do you see in xev utility, when you press Fn?

(In reply to comment #1)
> The problem here is that the functional key does not have "standard" keycode.

That seems like a fixable problem in evdev, if not already fixed.

> A couple of questions:
> 
> What is the driver you are using? If you do not know, please provide "xprop
> -root | grep XKB".

evdev.

$ xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "evdev", "pc104", "us", "", ""
_XKB_RULES_NAMES(STRING) = "evdev", "pc104", "us", "", ""

> What do you see in xev utility, when you press Fn?

KeyPress event, serial 30, synthetic NO, window 0x1c00001,
    root 0xac, subw 0x0, time 264955922, (82,128), root:(86,176),
    state 0x10, keycode 151 (keysym 0xff20, Multi_key), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: True

KeyRelease event, serial 33, synthetic NO, window 0x1c00001,
    root 0xac, subw 0x0, time 264955934, (82,128), root:(86,176),
    state 0x10, keycode 151 (keysym 0xff20, Multi_key), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False


Note that both the Press and Release event appear after I release the key.  Many Fn keys, including mine, don't generate keyboard events until released, because various combinations of Fn with other keys generate entirely different events and/or trigger things in BIOS.

Without my xmodmap call in ~/.xsession, Fn shows up as XF86WakeUp rather than Multi_key.

Ok, let's do it step by step.
First, Xorg probably should "standardize" Fn keycode. I do not think that 'wakeup' is the proper keycode for it. Peter, what do you think? Should evdev be fixed - and special keycode for Fn introduced?

Mapping WakeUp to Multi sounds really weird to me, I would not like to have that kind of mapping...

(In reply to comment #3)
> Ok, let's do it step by step.
> First, Xorg probably should "standardize" Fn keycode. I do not think that
> 'wakeup' is the proper keycode for it. Peter, what do you think? Should evdev
> be fixed - and special keycode for Fn introduced?

I suspect "wakeup" might have the right semantics.  On some laptops, resuming from suspend-to-RAM requires hitting the Fn key, not just any key on the keyboard.  That may have something to do with the mapping of Fn to XF86WakeUp.

But regardless of the choice of keycode, I definitely agree that Fn should produce the same keycode on every laptop.

> I definitely agree that Fn should produce the same keycode on
> every laptop.

For Linux+evdev that is a kernel issue, not an X issue, and the
kernel bases them on other standards, such as USB.  Evdev just
parrots what the kernel gives it.

> For Linux+evdev that is a kernel issue, not an X issue, and the
> kernel bases them on other standards, such as USB.  Evdev just
> parrots what the kernel gives it.
I do not know then what we could do. Adding mapping Wakeup->Compose unconditionally for that model would be wrong, I guess. Adding XKB option just for that strange mapping looks a bit of overkill. Any better ideas? I am inclined to WONTFIX...

(In reply to comment #2)
> Without my xmodmap call in ~/.xsession, Fn shows up as XF86WakeUp rather than
> Multi_key.

I can confirm this, I've always seen it as wakeup key in my tests.
I've never had the time to dig into it further, so I blame the kernel (probably because of what James said though I can neither confirm nor deny this).

The question is - is there any other key that produces the XF86WakeUp symbol?

Following up on this: I agree that it doesn't make sense to do this by default, but it doesn't seem particularly unreasonable to add an XKB option to map wakeup to compose.

it doesn't seem particularly unreasonable to add an XKB option to map XXX to YYY ;)

The question is whether it should be done and what is the reason to make that personal tweak public. Do you know many people doing it? I do not use Compose, so I have absolutely no opinion. But I'd love to see some support for that option.

do we have any data on which keys use KEY_WAKEUP and which use KEY_FN?
My lenovo uses the former, but how standard is this?

The trick on current laptop keyboards is finding an otherwise unused key.  Older laptops sometimes have keys like Scroll Lock, Pause, Menu, or RWIN that can be repurposed, but my current laptop eliminated every one of those keys, leaving only Fn unused.  Looking at other laptop keyboard layouts, the same applies: there are few if any unused keys, but Fn is almost always present precisely because of the multiplexing required with a limited number of keys.

I don't know how widely it's used.  I know of a few other people doing it, and I've seen mention of it elsewhere (using xmodmap).

> do we have any data on which keys use KEY_WAKEUP and which use KEY_FN?  My lenovo uses the former, but how standard is this?

I've never seen a laptop that produces KEY_FN, but presumably they must exist.  Perhaps the option could simply map both to Compose?

I don't disagree with adding an option, that's easy enough.

One other solution to this that would be more flexible and solve a whole bunch of other issues we've been seeing is to allow for additional local configuration, but one that's accessible through the common configuration channels. Right now, we load the xkb data files from one location only (/usr/share/X11/xkb). A natural extension to that would be to add /etc/X11/xkb as a default include path to the server and the other tools so that you can just drop your configuration in there. You'd have to copy bits and bobs from the original dir to get the same and correct structure but that seems to be a good solution for the various requests for custom configurations that we're seeing.

Peter, that architectural change is LOOOOOOOOOOOOOONG overdue. But that is not only about include path. The question is also about multiple rules/base and rules/base.xml.in.

Should we create a special bug about it? A lot of things to discuss, I guess...

yeah, please file a bug on it and CC me

(In reply to comment #15)
> yeah, please file a bug on it and CC me

https://bugs.freedesktop.org/show_bug.cgi?id=74422

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/issues/1.