GNOME Bugzilla – Bug 650379
Keyboard Setup for Macbook Pro
Last modified: 2017-06-20 18:00:32 UTC
I've decided to raise a bug here as I wasn't getting a response on Fedora's Bugzilla, and it's nice to deal with things upstream anyway I suppose. https://bugzilla.redhat.com/show_bug.cgi?id=702877 On Fedora 15, I can't select my keyboard type as being a UK Macbook Pro, meaning my " and @ keys are the wrong way around amongst other things. I'm not sure why I can't select this anymore.
Ha, that's how you make the keyboard not suck on those... The selection of the keyboard model is still available: gsettings set org.gnome.libgnomekbd.keyboard model 'macintosh' But that's really the wrong way to do it, because all the plugged in keyboards would be affected, not just the ones with a Mac-style keymap. Peter, do you have any ideas on how to fix that at the levels underneath (either through udev or the kernel)?
Oh right, there is a a way to do it then, that's good. There used to be a GUI for choosing that though, wouldn't that be better? Or was that a Fedora GUI?
Note that the fedora bug is filed against system-config-keyboard which is a fedora-specific component. For GNOME: If I select English (UK, Macintosh), I seem to get the right layout here. Can you confirm this? Bastien: we allow per-keyboard configuration in X. All you have to do is pass the device identifier to the various XKB calls. AFAIK, gnome currently simply applies it with XkbUseCoreKbd, which then applies to all devices. I'm currently writing a set of patches to get the product/vendor ID exposed for each device, would that help?
Ah, I didn't see those options before, testing ... "@ Yup, that fixed it! Great, thanks lads (and lasses).
Bastien: that is why I opposed removing the "model" choser Peter: the problem is not the device identifier - the problem is that gnome does not allow (in GUI) choosing the model at all. Neither globally, nor per-device. So people cannot easily change the model even globally (they could in 2.32). In gnome3 UI, there is no such thing as xkb model.
(In reply to comment #5) > Bastien: that is why I opposed removing the "model" choser That's one device, which should be fixed properly in some other way. > Peter: the problem is not the device identifier - the problem is that gnome > does not allow (in GUI) choosing the model at all. Neither globally, nor > per-device. So people cannot easily change the model even globally (they could > in 2.32). In gnome3 UI, there is no such thing as xkb model. And I don't want to add it back. We should really have some other way of handling those particular keyboards rather than having to select a different model when the keymap can work around that problem just as well.
> when the keymap can work around that problem just as well. First of all, let's not talk about keymaps. GNOME does not use keymaps, that is obsolete and rigid way of configuring XKB. Let's talk about RMLVO (rules, models, layouts, variants, options). Could you rephrase your statement in terms of RMLVO? I suspect you wanted to say "layout can work around", right? When you choose the model - you choose not only geometry, but also sometimes you _automatically_ choose vendor-specific layouts (well, considering we are talking about linux with evdev where keycodes are standardized at least). The model is not just geometry - it triggers some other _important_ things in the rules (in rules/evdev in our case). I would not mind dropping the models if they would be about geometries only - that would not affect end-user experience. But models define important things, as you can see here - they define the way how layouts are translated to symbols. Now, if we eliminate models, we have to expose all vendor-specific layouts to all models. That would be strange, that would add a lot of entries into layouts list that simply should not be there. Who cares (on PC) that Sun/Oracle has some special approach layouts? But we'd have to show them. While allowing people choosing proper model we automatically provide them with the vendor-specific layouts. That's why we have rules in XKB. That's a feature to be used, not to be ignored or fought with. The ultimate solution would be to figure out the XKB model based on the actual hardware. That would make sense. For that we'd have to build a map "device id" -> "xkb model". But that absolutely not the same thing as using "evdev" model for everybody.
Are we actually disagreeing here or just using different terminologies? IMO exposing the keyboard model in the GUI shouldn't be necessary if we can tell that the HW is an apple keyboard. Then we can apply the right RMLVO in the background. And tbh, I'm not sure how many other HW-specific models are really relevant enough to worry about them. And I wouldn't be surprised if the ones that may (Sun keyboards) have vendor/product IDs that we can match on for the same autoconfiguration.
(In reply to comment #8) > And tbh, I'm not sure how many other HW-specific models are really relevant > enough to worry about them. And I wouldn't be surprised if the ones that may > (Sun keyboards) have vendor/product IDs that we can match on for the same > autoconfiguration. All this trouble over Macbooks eh? Oh dear :) Yes, it'd be best if the system autodetects that you have a Mac and you don't have to change anything. Gnome 2.x series never got it right either when I tried that, although maybe that's a Fedora thing, I don't know. So if I make a login for my Mrs to use the laptop with Gnome, she'll need to change the keyboard settings too then by the sound of it ... hmm, not ideal really.
I'm happy adding code to gnome-settings-daemon for that. Peter, could you let me know how I would: - get the vid/pid corresponding to a particular device - guess which model to apply to that device (you mentioned that it would be directly in the xkeyboard-config files somewhere? though I can certainly apply this to Apple keyboards only for now) - apply a new model for a particular device (rather than the core device)
> - get the vid/pid corresponding to a particular device XInput should be able to provide that > - guess which model to apply to that device (you mentioned that it would be > directly in the xkeyboard-config files somewhere? though I can certainly apply > this to Apple keyboards only for now) Currently there is no way for that. We have to extend base.xml (and other similar files) to provide that info. We can discuss that here - or open a bug on fd.o > - apply a new model for a particular device (rather than the core device) The proper way would be to update libxklavier for that.
(In reply to comment #10) > I'm happy adding code to gnome-settings-daemon for that. Peter, could you let > me know how I would: > - get the vid/pid corresponding to a particular device There are patches on the xorg-devel list to export this as a property, see http://patchwork.freedesktop.org/patch/5485/ If this property is set, the rest is just matching it up with an internal quirk table. > - guess which model to apply to that device (you mentioned that it would be > directly in the xkeyboard-config files somewhere? though I can certainly apply > this to Apple keyboards only for now) I think "model" is outdated, since that's the hardware-specific part and they are for the most part covered by evdev. Variants are for shuffling keysyms around, so having mac variants for the layouts would be good. Or maybe just an option? I'm not sure how different mac layouts are from the defaults aside from the @ key (and possibly a few others). > - apply a new model for a particular device (rather than the core device) all XKB requests either take XkbUseCoreKbd as device ID or a device ID directly. So you need to feed this down, libxklaver I guess as svu said.
Sergey, do you want to handle that in libxklavier, and set a "macintosh" variant for all Apple keyboards automatically?
First, that info should be put into base.xml. For every model we could specify the list of device ids - so once we have the device with matching id, the corresponding model is activated (that code should go to libxklavier, I guess). Peter, what would you recommend to use as the format for those ids? What does it usually look like? Could you provide some samples?
they're just uint32, each vendor/product has its own unique numbers, apple for example has 0x5ac as vendor ID. For an example use of this information, see: http://patchwork.freedesktop.org/patch/5488/ not that this patch is for evdev, so it uses different APIs than a client would use but the basic approach is the same.
Fine, so the list of HW would be a list of those pairs, specified explicitly, like <hwList> <hw><vendor>1234</vendor><product>5678</product></hw> <hw><vendor>1234</vendor><product>6789</product></hw> ... </hwList> Inside the configItem containing the model. Does that make sense? Another question: would that work without evdev, on other OSes?
Also weird on my Mac keyboard, at the bottom left I've got fn, ctrl, alt and cmd. On OSX, fn+backspace is the delete key. Also this keyboard has no button for the hash symbol (which makes using IRC very annoying). On OSX, there's some combination like alt+3 for it, it doesn't work on Gnome, maybe that should by default?
(In reply to comment #17) > Also weird on my Mac keyboard, at the bottom left I've got fn, ctrl, alt and > cmd. > > On OSX, fn+backspace is the delete key. Also this keyboard has no button for > the hash symbol (which makes using IRC very annoying). On OSX, there's some > combination like alt+3 for it, it doesn't work on Gnome, maybe that should by > default? This would be a problem in the keymap, which isn't provided by GNOME. Best file a bug against your distribution, the package usually is "xkeyboard-config" there. File the bug against libxklavier now: https://bugs.freedesktop.org/show_bug.cgi?id=37446 Thanks Sergey!
(In reply to comment #16) > Inside the configItem containing the model. Does that make sense? > Another question: would that work without evdev, on other OSes? afaik the hw/vendor ID comes from USB so there's no reason other OS can't export it.
Gareth, after all these years, somebody fixed your bug in the kernel. Look for "HID: apple: Use country code to detect ISO keyboards", recently posted to LKML and linux-input.