Bug 54171

I guess it would be more correct to fix udev/kernel. Isn't that so?

Currently symbols/inet(evdev) is used for all keyboards, so all of them would use F20 for micmute. I am not very happy about that...

(In reply to comment #1)
> I guess it would be more correct to fix udev/kernel. Isn't that so?

It's already "fixed" in udev/kernel, because udev/kernel can handle keycodes over 255. However, X11 can't (MICMUTE is out of range), we have to remap it to something that X11 can use. We've used F21-23 before, so I assumed that was the best place to put it. I'm open to suggestions.

> Currently symbols/inet(evdev) is used for all keyboards, so all of them would
> use F20 for micmute. I am not very happy about that...

What keyboards have F20? We're already using F21-23 for the touchpad on/off/toggle buttons, so there is a precedent for this.

Are there physical keyboards with an F20 key?

(In reply to comment #3)
 
Not in common use. The M keyboard only has 12, and the Sun keyboard only has 12. Seems that every PC vendor and certainly every laptop maker only goes up to F12. Even the X Termainal photo from Wikipedia only has up to F12

(In reply to comment #4)
> Not in common use. The M keyboard only has 12, and the Sun keyboard only has
> 12. Seems that every PC vendor and certainly every laptop maker only goes up to
> F12. Even the X Termainal photo from Wikipedia only has up to F12

Sun keyboards in the 80's had 35 F-keys - since around 1990 many of those were
relabeled - the left side keys to the SunStop, SunProps, etc and the right side
to the numeric keypad.   Those were only found on the old Sun 4 and older
systems, not any UltraSPARC, x86 or AMD64 systems.   I think other Unix
workstations from the era had similarly large amounts of F keys for the
CAD/CAM applications of the time, but those fell out of use over the years.

> Are there physical keyboards with an F20 key?

Unicomp "terminal" keyboards have 24 function keys, are still manufactured, and available with USB for use with a PC.

> Unicomp "terminal" keyboards have 24 function keys, are still manufactured, and
> available with USB for use with a PC.
So, F30?

I wasn’t ready to come out of the woodwork with this, but given this bug
report....

I've started implementing my earlier suggestion to get around X’s 8–bit
keycode limitation by modifying evdev to create one X keyboard device
for each 7–bit block of linux event key codes.

This will make every key available to X, inlcuding the mic mute key,
the zoom key (Fn-SPC), et al.

Not to mention all of the telephone and media-device input keys
(KEY_OK .. KEY_CAMERA_RIGHT).

My plan was/is to get it into shape by the end of this (holiday)
weekend.

Wow, okay. That's great news! I can certainly wait a few more months, thanks for working on it.

s/months/days/

Hi James,

I don't think I'm on the relevant mailing lists. Have you posted the code yet?

What's the status of this?

The bug is stagnant. I'm not sure if James Cloos has fixed it in X yet, but because we're waiting on that proper fix we haven't mapped micmute to F20 just yet.

I've sent another message to the list to see if they would include the patch. It is not worth holding off on this, even if we do eventually get around the 8 bit keycode limitation, since while I wasn't looking both udev and gnome-settings-daemon have standardized on F20 for this key.

https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=5cda26ee

I would prefer for James Cloos to fix it properly..

(In reply to comment #1)
> Currently symbols/inet(evdev) is used for all keyboards, so all of them
> would use F20 for micmute. I am not very happy about that...

This doesn't really make sense. Yes, today symbols/inet is used for all keyboards, but FK20 (code 198) is not mapped to _anything_. If you actually have a keyboard with an F20 key, it'll be remapped by the vendor specific keyboard map anyway (eg digital_vndr/lk).

A quick grep reveals that only 3 keyboards even use this key: a VT105, an ancient DEC keyboard that also requires a special driver, and a fujitsu keyboard that I can't find any mention of online. 

The other approach if people are really big on keeping F20 functionality around is to map FK20 to F20, and leave gnome-settings-daemon as it is. This has the downside of making XF86AudioMicMute irrelevent.

quite frankly, I think we should admit defeat and go with the F20 route. X gaining support for > 255 keycodes is unlikely to ever happen and F20 is as good/bad a key as any.

Anthough I know what needs to be done, and have a preliminary commit for
xkeyboard-config, the changes for xf86-input-evdev will require a block
of time I've not been able to schedule.

I agree that that f20 patch is good for now.

I'll post something on the list about my proposed patches.

Ok, let's do it with F20. The patch does not apply to git:

$ git am ~/Downloads/mail.google.com
Applying: Add XF86AudioMicMute mappings
error: patch failed: symbols/inet:120
error: symbols/inet: patch does not apply
Patch failed at 0001 Add XF86AudioMicMute mappings
The copy of the patch that failed is found in:
   /home/svu/git/xkeyboard-config/.git/rebase-apply/patch
When you have resolved this problem, run "git am --resolved".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Created attachment 79265 [details] [review]
0001-https-bugs.freedesktop.org-show_bug.cgi-id-54171.patch

Sorry about that, this patch should work.

Created attachment 79266 [details] [review]
0001-Add-XF86AudioMicMute-mappings.patch

Forgot the title for the last patch. This one is better.

applied, thanks!

Current kernels have KEY_MICMUTE==248, i. e. X.org should be perfectly able to recognize this. Apparently this was done in 2011 already.

Can we update xkeyboard-config to also recognize KEY_MICMUTE in addition to F20, so that it works with both kinds of udev/kernel keymaps for a while? After that version has been out in the wild for some time, we can mass-convert the udev keymaps to produce the proper KEY_MICMUTE instead of KEY_F20.

(In reply to comment #23)
> Current kernels have KEY_MICMUTE==248, i. e. X.org should be perfectly able
> to recognize this.

I'm not certain that's enough for X.org to be able to handle it. Any changes to this should go in another bug anyway.

> Current kernels have KEY_MICMUTE==248, i. e. X.org should be
> perfectly able to recognize this. Apparently this was done in
> 2011 already.

248 is the first linux kernel value which X cannot handle.

The mapping is +8, so 248 ⟹ 256, which does not fix in 8 bits.

(The first 8 are reserved – from way back – for the modifiers.)

(In reply to comment #25)
> > Current kernels have KEY_MICMUTE==248, i. e. X.org should be
> > perfectly able to recognize this. Apparently this was done in
> > 2011 already.
> 
> 248 is the first linux kernel value which X cannot handle.
> 
> The mapping is +8, so 248 ⟹ 256, which does not fix in 8 bits.
> 
> (The first 8 are reserved – from way back – for the modifiers.)

So nothing to change until we're all using Wayland.

Ah, thanks for the heads-up!