[SOLVED] Expose and Dashboard keys don't work (macbook 4.1)

[_mario_]

Hi all,

i didn't expect that much replies for a simple suggestion...
however i'd like to explains some things:

What really bothers me is that I had to compile a kernel module to get this to work (as well as fix expose and dashboard keys). The way this should really be done is as follows: The fn key should be treated just as ctrl, alt, and super. That way xmodmap could be used to map the primary and secondary functionality of *any* key.
...
This is of course not a trivial patch to get working, and it'd be difficult to get it accepted upstream as it'd mess with a fair chunk of "stable" albeit hackish code in usbhid and hid-quirks.

in theory you're right. that would be a nice feature, but unfortunately the FN-key is not supposed to work like this. in ealier PC days this key was invented to overcome the restrictions imposed by small laptop sizes, where a full-sized keyboard wouldn't fit. thus, to stay fully compatible, the keyboard controller itself emits different scan codes with and without FN. the operating system doesn't even notice the difference. in contrast, Apple does this translation in software. as Linux is primarily a PC operating system, it's very unlikely to get userland FN key support for a few Linux on Mac users.

having that said, i think it's a good advice to look how other PC operating systems (read Windows) work on Apple hardware, i.e. what Apple does to get it to work.

The only time I have argued different is in the case of things such as the help key on the full apple keyboard that is in place of Insert as it appears on most other PC keyboards. (Clear / Numlock is another case of this).

The Help key in windows yields Insert, just what a PC user would expect. Apple simply seems to think the user doesn't need an Insert key (maybe because its software is properly designed) and gave it another function (Help) in MacOS.

Curious exactly what this means....
It is just my personal opinion, but I would rather have a key perform the function that is actually marked on the key by default and allow the user an option to change its function via software (gnome keyboard layout options?). Having a key marked one thing and performing a completely different function is quite confusing.

I don’t know how it is with newer or older Macbooks (I guess it is different, because Apple liked to change some of the keys on the keyboard), but on the 3,1 on the Carriage Return Key there is a large sign saying Return (↩) which is ‘Return’ in xmodmap and a smaller one saying Enter (⌅) which should correspond to ‘KP_Enter’ in xmodmap. So for that one it would be reasonable to somehow map it that way. Users of course could change it afterwards with xmodmap to ‘Insert’ it they wanted to.

In earlier days there had been a difference between Return and Enter. most PC operating systems don't really differentiate those 2 keys anymore. (has anybody ever used Return and Enter for something differently in Linux?) however, Apple always did make a difference (while at the same time not providing an Insert key). there are applications really distinguishing those 2 functions. since PC operating systems usually do not, Apple decided to map FN-Return to Insert in Windows. I personally think that's the right decision, because it's convienient for (at least) Windows on Mac users, we don't need 2 keys doing the same, and we need an Insert key which is more important than an Enter key. and as a side note: remapping FN-behaviour is not possible with xmodmap.

so we'll have to patch the kernel. maybe having a module option similar to pb_fnmode that differentiates between FN-Return being Insert or Enter might be a solution.

i can always patch the module myself. but i thought having Insert would be helpful for others too, although it isn't consistent with what is printed on the keyboard.

last but not least: thanks kosumi68 for struggling with our wishes.

ciao,
Mario

[cyberdork33]

as Linux is primarily a PC operating system, it's very unlikely to get userland FN key support for a few Linux on Mac users.

That's no way to think! I know I am treading on dangerous territory here, but Macs ARE PCs... They are just very picky and temeramental ones . Linus even uses a Mac running linux. Don't think that Macs don't matter in Linux.

having that said, i think it's a good advice to look how other PC operating systems (read Windows) work on Apple hardware, i.e. what Apple does to get it to work.

while that makes sense to do, it can also be dangerous sometimes. we don't have to (or necessarily want to) do things the way apple does them.

The Help key in windows yields Insert, just what a PC user would expect. Apple simply seems to think the user doesn't need an Insert key (maybe because its software is properly designed) and gave it another function (Help) in MacOS.

I fully agree with that. I actually like having help act as Insert, but for an OSX user this is a foreign concept. "Help" should do help, not insert. Situations like this are why I think it is best to have the keys perform the functions actually printed on them by default, and allow changes in userland. It is only logical that a key that says "Help" actually does something that helps the user... Think about it as if you have no preconceptions about the layout of the keyboard.

Where this gets grey is in areas like the Function keys on modern Apple Keyboards because the intended default is not so obvious.

In earlier days there had been a difference between Return and Enter. most PC operating systems don't really differentiate those 2 keys anymore. (has anybody ever used Return and Enter for something differently in Linux?) however, Apple always did make a difference (while at the same time not providing an Insert key). there are applications really distinguishing those 2 functions. since PC operating systems usually do not, Apple decided to map FN-Return to Insert in Windows. I personally think that's the right decision, because it's convienient for (at least) Windows on Mac users, we don't need 2 keys doing the same, and we need an Insert key which is more important than an Enter key. and as a side note: remapping FN-behaviour is not possible with xmodmap.

while this is an excellent argument for using Fn+Return as Insert (and I will likely make my MacBook Pro do this once I get Ubuntu on it), I still don't know if that should be a default (of course the other problem with this is that nobody knows that ⌅ = Enter, and beyond that, it doesn't seem to be consistant for which keyboard actually have the symbol on the Return key). Maybe common switches like this and Help/Insert should be in the gnome keyboard config applet for Mac layouts.

[_mario_]

That's no way to think! I know I am treading on dangerous territory here, but Macs ARE PCs... They are just very picky and temeramental ones . Linus even uses a Mac running linux. Don't think that Macs don't matter in Linux.

i neither tried to start a discussion whether Macs ARE PCs (or vice versa), nor whether linux on Mac users are important. the point simply is: other machines handle FN-keys in hardware. only a small user group has the possibility to to it in software. so it's the most practical solution to handle this stuff inside the kernel and leave the remaining userland untouched. it's a hack. nothing else. it's just too unlikely that someone changes a lot of APIs to get this to work for a few users, even if Linus itself uses a Mac.

while this is an excellent argument for using Fn+Return as Insert (and I will likely make my MacBook Pro do this once I get Ubuntu on it), I still don't know if that should be a default (of course the other problem with this is that nobody knows that ⌅ = Enter, and beyond that, it doesn't seem to be consistant for which keyboard actually have the symbol on the Return key). Maybe common switches like this and Help/Insert should be in the gnome keyboard config applet for Mac layouts.

changing Help/Insert is possible in userland. the kernel should (theoretically) emit the insert keycode for this key's scan code. so we can assign an appropriate X11 symbol, right? (on the other hand this might also be done inside the kernel, as there already is a KEY_HELP constant.)

changing the FN-key behaviour cannot be done in userland, unless the kernel exports this feature (should be easy. just like /sys/module/hid/parameters/pb_fnmode).

i could write this (2nd part). however, kosumi68, what are the chances to get this upstream? or in the mactel repo? i'm asking, because i personally don't need that functionality and it's quite some work to do.

ciao,
Mario

[cyberdork33]

i neither tried to start a discussion whether Macs ARE PCs (or vice versa), nor whether linux on Mac users are important.

I know you didn't... I did. You did imply that the Mac user demographic is "not important" though. I was simply trying to make the point that you are what you think you are. If you think that you will never be important, then you never will be. Trying to be optimistic.

the point simply is: other machines handle FN-keys in hardware.

well understood.

only a small user group has the possibility to to it in software. so it's the most practical solution to handle this stuff inside the kernel and leave the remaining userland untouched. it's a hack. nothing else. it's just too unlikely that someone changes a lot of APIs to get this to work for a few users, even if Linus itself uses a Mac.

I am not saying that it should be changed for the benefit of Mac users only (though I still believe that should be considered a key driver in itself), but rather that the way it is currently handled (in kernel) is not the best way. The idea of Linux being flexible is what drives a change to the current situation. There also used to not be WIN keys on most PC keyboards, but they work... Things evolve. If the Fn key can be treated as any normal key on the keyboard, then it should be reported in a manner that is consistant with it function regardless of whether or not the name of the key is the same as keys on other keyboards that work differently.

Please don't take things as an attack, I am simply trying to have a discussion.

[kosumi68]

Wow, keyboard mapping discussions really *does* stir emotions, don't they.

i could write this (2nd part). however, kosumi68, what are the chances to get this upstream? or in the mactel repo? i'm asking, because i personally don't need that functionality and it's quite some work to do.

Regarding the FN+F3 and FN+F4, they have a history with the kernel, including the CYCLEWINDOWS suggestion. Today, function keys should be mapped to function keys, rather than to labels. The most clean patch (and Dmitry, the input maintainer, likes clean patches) is most likely to create a new function key if none of the current ones match. This might be what it eventually ends up at. In any respect, I expect a dialog about it upstream.

Regarding KP_ENTER or INSERT, it makes little sense to me, regardless of reason, to do anything different from what other operating systems do. After all, confusion is not the goal of ubuntu. I suppose the big question is: which users are most likely to switch to ubuntu: Windows or Mac users? Serving the masses might be a good idea here.

[cyberdork33]

Wow, keyboard mapping discussions really *does* stir emotions, don't they.

yes... for some reason.

In any respect, I expect a dialog about it upstream.

That's all we can really ask for at the moment.

I suppose the big question is: which users are most likely to switch to ubuntu: Windows or Mac users? Serving the masses might be a good idea here.

Well, we are talking about apple hardware here, so... Mac users I would venture to say, though there are a lot of PC-to-Mac switchers out there that are trying to put Ubuntu on their new Mac.

[_alex_]

Hello Mario,

I have to respectfully disagree about the current kernel space handling being practical. Take a look at usbhid.c and hid-quirks.c. The quirks are locked to the hardware and become more numerous as Apple continually shuffles keys around with each release (this has lead to numerous bugs in the past, including the aluminum key numlock messing up the keyboard, because inside usbhid it was erroneously treated as a laptop keyboard).

Last Macbook revision, we had to wait several months for a patch which merely added the hardware ID to the quirks table to make it into the repos. One has to ask oneself whether this is really practical. And in my opinion it is very clearly not. It shouldn't take months to get a functioning keyboard. In addition, these kernel space hacks lead to increasingly bloated code that continually breaks working hardware when people issue a patch with erroneous assumptions (again see launchpad for dozens of bugs because of this).

The way I see it, there should be one quirk and only one quirk in the kernel, and that is to enable fn key treatment on Macs just like any other modifier key (alt, ctrl, super). If PCs have hardware handling of the fn key, then that's their loss, but to the kernel it'd just look like a keyboard that emits more keycodes and which lacks a mac-like fn key. Then in userspace we just have a "Keyboard Shortcuts" like program that lets the user map fn+delete to "Delete", fn+anything to "whatever you want" etc.) just like any other modifier key.
(It's really a hybrid program between xmodmap and keyboard shortcuts --- since you want to map modified keys to another keycode).

This would pretty much remove 90% of the code from the quirks files. And old hardware wouldn't be repeatedly broken because new mappings could be selected (manually or automatically where possible) based on the user's model (you can set keyboard layout already anyway) and stored in a configuration file.

It's in my opinion ridiculous that this hasn't been done from the get go, and has lead us down the road where one needs to patch the kernel to make a key work a certain way---this isn't a mac only problem either, as many PC keyboards come with media keys in numerous configs.

Just my thoughts,
Alex

[cyberdork33]

That is exactly what I was thinking too.

P.S. The Keyboard Layouts are all screwy for international keyboards too...

[_mario_]

I have to respectfully disagree about the current kernel space handling being practical. ...

i aggree. you're absolutely right. such things don't belong into a kernel. (and from the point of micro-kernel construction the whole input framework doesn't belong into the kernel at all.)
practical in my previous post meant: it was easy to implement in the kernel the first time this problem appeared. (but this implemetation evolved to a tremendous hack. yes i saw it.)

however, we still have to wait until new hardware IDs have been added for the new feature (passing FN to userspace) to be enabled automatically. although a kernel parameter may solve this quickly.

in addition, other quirks are nevertheless necessary to exclude the trackpad device, for the bcm5974 to work, unless we also incorporate it. but it will need updates due to Apple regularily changing the protocol. and following your suggestion, the userspace tools have to be updated, if Apple again decides to shuffle keys around. and that's the same: a maintenance problem. nothing else. it will take some time too.

furthermore, how does that work on the "traditional" text console?

last but not least: who is going to get his hands dirty and starts the change? in the meantime, i think, it's necessary to patch the kernel until this stuff is completely moved to userspace. hopefully the kernel developers will find a solution.

Regarding the FN+F3 and FN+F4, they have a history with the kernel, including the CYCLEWINDOWS suggestion. Today, function keys should be mapped to function keys, rather than to labels. The most clean patch (and Dmitry, the input maintainer, likes clean patches) is most likely to create a new function key if none of the current ones match. This might be what it eventually ends up at. In any respect, I expect a dialog about it upstream.

right now, those keys are mapped to KEY_FN_F5 and KEY_FN_F4 which happed to be 470 and 469. unfortunately, the X server doesn't process keycodes greater than 255. i've already tried that. the X keymap compiler complains about an invalid range...

I suppose the big question is: which users are most likely to switch to ubuntu: Windows or Mac users? Serving the masses might be a good idea here.

that's a good question. i really don't know.

ciao,
Mario

[kosumi68]

however, we still have to wait until new hardware IDs have been added for the new feature (passing FN to userspace) to be enabled automatically. although a kernel parameter may solve this quickly.

in addition, other quirks are nevertheless necessary to exclude the trackpad device, for the bcm5974 to work, unless we also incorporate it. but it will need updates due to Apple regularily changing the protocol. and following your suggestion, the userspace tools have to be updated, if Apple again decides to shuffle keys around. and that's the same: a maintenance problem. nothing else. it will take some time too.

This problem is partly cushioned by the ability to use dkms packages.