The apple keyboard layout

Apple Keyboard

Some keyboard models that use the Apple keyboard driver may have swapped keys or missing functionality. This article describes how to change the settings for the keyboard so that it behaves as expected.

Contents

)»> 7 have changed place with ^ and ° (or @ and #, or ` and

Numlock is on

You may find that the numlock is on. The symptoms are that only the physical keys 7 , 8 , 9 , u , i , o , j , k , l and surrounding keys work and output numbers. To fix this hit Fn+F6 twice. You might need to use a utility like numlockx .

Alternatively, set the keycodes manually using xmodmap to avoid use Numlock:

Repeating keys on a wireless keyboard

Unpair the keyboard and then re-pair it. The trick is to hold down the power button throughout the entire pairing process.

hid_apple module options

• fnmode — Mode of top-row keys

• swap_opt_cmd — Swap the Option («Alt») and Command («Flag») keys

• iso_layout — Enable/Disable hardcoded ISO-layout of the keyboard. Possibly relevant for international keyboard layouts

• swap_fn_leftctrl — Swap the Fn and left Control keys

Function keys do not work

If your F keys do not work, this is probably because the kernel driver for the keyboard has defaulted to using the media keys and requiring you to use the Fn key to get to the F keys. To change the behavior temporarily, append 2 to /sys/module/hid_apple/parameters/fnmode .

To make the change permanent, set the hid_apple fnmode option to 2:

To apply the change to your initial ramdisk, in your mkinitcpio configuration (usually /etc/mkinitcpio.conf ), make sure you either have modconf included in the HOOKS variable or /etc/modprobe.d/hid_apple.conf in the FILES variable. You would then need to regenerate the initramfs.

Switching Cmd and Alt/AltGr

This will switch the left Alt and Cmd key as well as the right Alt / AltGr and Cmd key.

Temporary and immediate solution:

Permanent change, taking place at next reboot:

Swap the Fn and left Control keys

This will switch the Fn and left Control keys.

Temporary and immediate solution:

Permanent change, taking place at next reboot:

_have_changed_place_with_^_and_°_(or_@_and_#,_or_`_and_

)»> have changed place with ^ and ° (or @ and #, or ` and

With German layout, circumflex/degree symbol and are exchanged. With French layout, @/# are exchanged. With the US layout, `/

and are exchanged.

To change the behavior temporarily, overwrite /sys/module/hid_apple/parameters/iso_layout with 0 :

To make the change permanent, set the hid_apple iso_layout option to 0:

PrintScreen and SysRq

Apple Keyboards have an F13 key instead of a PrintScreen / SysRq key. This means that Alt+SysRq sequences do not work, and application actions associated with PrintScreen (such as taking screenshots in many games that work under Wine) do not work. To fix this, you can add setxkbmap -option «apple:alupckeys» to your .xinitrc . This will map PrintScreen / SysRq to F13 , as well as Scroll lock to F14 and Pause to F15 .

Alternatively, follow the Map scancodes to keycodes article to map the F13 scancode to the PrintScreen / SysRq keycode, where 458856 (0x070068) is the scancode of F13 , and sysrq is the keycode of PrintScreen / SysRq .

Treating Apple keyboards like regular keyboards

Depending on the customisations you want to accomplish, there are two solutions available and some options that are in the kernel. You need to choose one of the other.

Use a patch to hid-apple

While the original hid-apple module does not have options to further customize the keyboard, like swapping Fn and left Ctrl keys or having Alt on the left side of Super , there is a patched version adding this functionality to the module. To use it, install the hid-apple-patched-git-dkms AUR package. This will install the patched hid-apple and mask out the original one.

The package uses DKMS to automatically recompile the module during kernel upgrades. While the dkms will be pulled in by dependency. You still need to install an appropriate kernel header package manually. See the DKMS page for more info.

In addition to the patched kernel module, a configuration file is also provided by the package at /usr/lib/modprobe.d/hid_apple.conf , which enables PC-like layout by default:

• Top-row keys are normally function keys, switchable to media keys by holding Fn key, as in #Function keys do not work.
• Four keys at the lower left corner act as Ctrl , Fn , Super , Alt , in this order.
• Two keys at the lower right corner act as Alt , Ctrl , in this order.
• If you have an Ejectcd key, it will act as Delete key.

If you wish to change the default options, copy the configuration file to /etc/modprobe.d and make desired changes:

The file under /etc/modprobe.d will completely override the one with the same name under /usr/lib/modprobe.d , and the content is NOT merged.

Alternatively, put additional options in a file with a different name if you want to keep default ones,

Please refer to the project README for the exact meaning of each configuration option and tweaking the configuration file to suit your needs. Learn more about modprobe.d at Kernel module#Using files in /etc/modprobe.d/.

After installation, reboot for the change to take effect, or #Change the Behavior Without Reboot.

Troubleshooting configuration not picked up by the module

First, make sure the patched version is loaded, see what parameters are provided by the module:

If you do not see new options like swap_fn_leftctrl , ejectcd_as_delete , etc., check your DKMS installation.

Then, check if configuration files are correctly included in the initramfs:

Check the presence and content of usr/lib/modprobe.d/hid_apple.conf and any other relevant configuration files in etc/modprobe.d/ . If they are not there, you should check your /etc/mkinitcpio.conf to include those. By default, there should be a modconf hook that automatically include those files, if not, add it to the HOOKS array after autodetect .

Alternatively, specify those files in FILES array explicitly:

Use un-apple-keyboard

If you do not need all of these customizations and you do not want to compile a new module manually or using dkms, there is an AUR package un-apple-keyboard AUR which does not rely on a new kernel module, but rather just to mappings. It enables the following features:

• The keyboard is considered as an ISO keyboard (e.g. and > located at the right of the Left Shift key are working like expected).
• The function keys are disabled by default. You need to press the Fn key in combination to trigger them. By default, the behavior are thus keys F1 to F12
• The Alt and Cmd keys are swapped.
• F13 is mapped to SYSRQ , F14 to Scroll Lock and F15 to Pause .

The first 3 aforementioned features are brought to you using the default linux kernel module hid-apple .

The last one is provided by providing a mapping to keyfuzz AUR .

Change the Behavior Without Reboot

To reload the kernel module without reboot, run rmmod hid_apple && modprobe hid_apple .

Magic Keyboard does not connect

If you have a magic keyboard that will not connect to the system through the built in tools, such as the Gnome 3 bluetooth menu in settings, install blueman and its dependencies and attempt to connect with it. If it still fails to connect, make sure you have bluetoothctl and hcitool installed.

Enable dvorak/dvp

By default xkb loads translation table (actually called xkb_symbols ) macintosh_vndr/us for macintosh keyboard:

This translation table located in /usr/share/X11/xkb/symbols/macintosh_vndr/us and do not contains dvorak/dvp layout. You can use default translation table from /usr/share/X11/xkb/symbols/us and add command setxkbmap in your .profile for forced loading layout:

No input during root disk decryption

You may have to manually add the hid_apple module to the mkinitcpio configuration:

Or place the keyboard hook before autodetect so that all keyboard drivers are included:

Regenerate the initramfs after doing either of these.

Источник

Особенности использования клавиатуры Apple под Windows

Клавиатура от Apple была приобретена для использования с хакинтошем, но с OS X в тот момент не срослось и основной системой для меня осталась Windows. Но не все так просто, как оказалось, работа под Windows собпряжена с несколькими проблемами:
1) Для вызова клавиш F2-F12, требется зажатие модификатора (Fn).
2) Раскладка на клавиатуре не совпадает с системной (коды клавиш используются стандартные).
3) Некоторые клавиши в принципе не работали (например, PrintScreen).

Установка Boot Camp решала первую проблему и даже клавиша выброса диска заработала, но появились неприятные фризы при старте системы и проблему раскладки она не решала. После недолгих копаний, был найден ключ реестра, отвечающий за работу функциональных клавиш и программа, позволяющая редактировать раскладки.
Результатом этого стал данный установщик, в котором содержится:

• Драйвер от Apple из дистрибутива Mac OS X Leopard 10.5.4
• Файл реестра, изменяющий параметр, ответсвенный за клавиши F2-F12
• Установщики раскладок клавиатуры (для русского и английского языков)

Набор проверен на 32-битных версиях Windows Vista и Windows 7, в принципе, и под Windows XP тоже должно работать.
Раскладки добавляются автоматически, чтобы полностью заменить стандартные:

1) Укажите одну из новых раскладок, в качестве языка ввода по-умолчанию:

2) Перенесите новые раскладки вверх списка:

3) Нажмите «Применить» и удалить стандартные раскладки.

Также вы можете скачать раскладки отдельно (для 32 и 64-разрядных ОС): Русская, Английская

UPDATE:
Последняя версия драйвера из Boot Camp 5.0:
yadi.sk/d/TcAobagLM58Bf

В этом случае вам будет необходимо вручную установить раскладки клавиатуры и внести следующие изменения в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\KeyMagic\:
1. Для возвращения привычного поведения клавишам F1-F12 измените значение OSXFnBehavior на 00.
2. Чтобы сместить Print Screen на законное место (F13): «Keymap»=hex:68,46,69,47,6a,48

В качестве бонуса: можно увеличить ток на встроенном USB-хабе до 500 мА:

Windows Registry Editor Version 5.00

; Изменяем название хаба в диспетчере устройств
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_05AC&PID_1006\000000000000]
«DeviceDesc»=«Apple Keyboard Hub»

; Увеличиваем ток на хабе до 500 мА
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_05AC&PID_1006\000000000000\Device Parameters]
«ForcePortPower»=dword:000001f4

Источник

How to identify your Apple keyboard layout by country or region

Use the letters and symbols on your Apple keyboard to help you determine your keyboard layout by country or region.

Some keyboard layouts are only available in certain countries or regions.

If you need keyboard replacement or repair, contact Apple or a service provider.

Identify your keyboard layout (ANSI, ISO, or Japanese)

Find the key that has the word “return” or the return-left symbol printed on it. The key should look like one of the options below:

ANSI keyboard

If your Return key looks like one of the images below, you have an ANSI keyboard:

ISO keyboard

If your Return key looks like one of the images below, you have an ISO keyboard:

Japanese keyboard

If your Return key looks like the image below, you have a Japanese keyboard:

Identify the ANSI keyboard layouts

Find the Tab key or the key with the tab symbol . The Q key to the right should look like one of the options below and will help you to identify your keyboard layout:

US English

(if the Caps Lock key is below the Tab key)

Источник

Your guide to keyboard layout

Discover how you can use the Keyboard Layout Guide to manage how keyboards work within your iOS or iPadOS app. Learn how you can avoid writing lengthy code blocks when you use UIKeyboardLayoutGuide and UITrackingLayoutGuide to integrate the keyboard into your interface, helping people have a smoother, more enjoyable experience whenever they use the on-screen keyboard within your app. To get the most out of this session, we recommend familiarity with both Auto Layout and UILayoutGuide.

Resources

Related Videos

WWDC21

WWDC 2017

♪ ♪ Hi. My name is Kasia Wawer. I’m an engineer on the Keyboards UI team, and today, I’ll be your guide to the wonderful world of keyboard layout. I am incredibly excited to talk to you today about bringing the keyboard from a frame-based past into an auto-layout future. We’ll start our tour by talking about the new guide. Then, we’ll go over some of the new things you’ll be able to do to more fully integrate the keyboard into your layout. And finally, we’ll talk about what a keyboard really is— philosophically speaking, types of keyboards to consider, and some of the cases you might not think about right away. So, let’s get started with our tour. As with many things, this one begins in the ancient past. If you have worked with the keyboard in your app before, you know the way that it’s been handled since time immemorial is by registering for notifications, deriving the appropriate offsets and animations from the information in the notification, doing some math, and finally, using that to adjust your layout. Now, notifications are sticking around. We are not deprecating them. You can learn more about them, if you’re interested, in «The Keys to a Better Text Input Experience» from 2017. Let’s look at a quick example of how notifications might be used with a custom guide. Now, don’t copy any of this code because we’re about to replace it. But here’s how you handle the keyboard before iOS 15. You’d create your custom guide and anchors to respond to notifications. Then, you’d register for the appropriate notifications. Usually, at least willShow and willHide, but sometimes frame changes, etc. Then, you’d respond to said notifications by getting the frame information from the notification, making sure that you’re adjusting for your own views and the safe area guide, if the keyboard is leaving the screen. And you’d get the animation info from the notification and, finally, change your guide to match. Now, it’s not a ton, but it can get complicated quickly. Today, I am happy to announce a brand-new addition to the auto layout collection: UI keyboard layout guide. Now, try to constrain your excitement as we dive into this. Keyboard layout guide is brand-new in iOS 15. It’s a layout guide. You can constrain the views and guides in your existing layout to it. If you’re not familiar with layout guides, a layout guide is a way to represent space in a layout without using a view. It has all the same anchors as a view. The keyboard layout guide will represent the space that the keyboard occupies in your app so that your layout can account for it. And that’s it! Mostly. Let’s talk about updating that code we just saw to use this instead. Here’s that notifications code. Don’t copy it yet, wait for the green checkmark. So, now you can go ahead and remove that anchor you were tracking. And change from your layout guide to the view’s keyboardLayoutGuide.

And we don’t need to register for notifications anymore. And we don’t need to respond to them either. And that’s it. All that code boils down to this single line. Ready to see it in action? Here’s what it looks like to bring up the keyboard when using the notifications code. And here’s what it looks like to bring it up using the guide.

You may have noticed that, other than their localizations, those looked virtually identical, but that’s kinda the point. You don’t have to do nearly as much, and you get the same result. So, let’s talk about updating to the guide. It’s a property on UI view. And, for most cases, you’ll just update to using the guide’s topAnchor. The guide matches keyboard animations, like bring up and dismiss, and it follows height changes too. Because sometimes the keyboard is taller, and sometimes it’s shorter. But the guide will adapt to fit whatever size appears. And, when the keyboard is undocked, by default, the guide will drop to the bottom of the screen and be the width of your window, and anything you’ve tied to the top anchor will follow. It accounts for safe-area insets, so you don’t have to worry about that anymore, either. For basic uses, that’s probably all you need to know. But now we get to talk about the fun stuff. Why did we choose to use a new class and not just a normal layout guide? Well, we wanted you to be able to do more than you’ve ever been able to do with the keyboard. Our next stop is full keyboard integration into your app. Why do I say «integration»? Well, I have often heard people talking about the keyboard as something they need to avoid, or as something fighting with their layout, but the keyboard is part of your app. One of the main motivations behind UI keyboard layout guide is to give you, the developer, the ability to respond to the many different ways we have for users to input text, and let you really, fully think of the keyboard as a part of your layout in a way that maybe you haven’t been able to before. I am really excited to see how you take advantage of these new features. So, our next stop, what makes keyboard layout guide not just a layout guide? With UI keyboard layout guide, you have the ability to fully follow the keyboard in all its incarnations, if you so choose, by using a new property: followsUndockedKeyboard. It’s false by default, but if you set it to true, the guide will follow the keyboard when it’s undocked or floating, giving you a lot of control over how your layout responds to wherever the keyboard may be.

No more automatic drop-to-bottom. No listening for hide keyboard notifications when undocking. The layout guide is where the keyboard is. The thing about having that information, though, is that it means you have to be a lot more conscious of how your layout is responding to different types of keyboards. So, UI keyboard layout guide is a subclass of another new layout guide: UI tracking layout guide.

We call it a tracking layout guide because it tracks the constraints you want to change when it moves around the screen. You can give it an array of constraints that activate when near a specific edge, and deactivate when leaving it, and/or an array that activates when specifically awayFrom an edge, and deactivates when near it. Let’s look at an example of what you can do with this, and the code you need to achieve it. Here’s a test app. I have a text field and some controls that can sit on the keyboard. But, when it gets close to the top of the screen, I want them to drop to the bottom to avoid going off-screen.

And when the keyboard moves side to side, I want the rest of the UI to shift a bit to give it a little more space. So, how is all this accomplished? We’re gonna look at some code here. In the following slides, the editView is the view with the text field and controls, and the imageView is the image view. Okay, note that we should be using identifiers here, and you will see that in the sample code, but this fits better on a slide. Let’s start with what’s happening on the vertical axis. First, we define an array that ties the bottom of the editView to the keyboard layout guide’s top.

Then, we set those to be active only when the guide is away from the top, so that they’ll be deactivated when it’s near it.

Then, we define a separate array of constraints that we want for when the keyboard gets close to the top of the view. So, instead of the top of the keyboard layout guide, we use the safe area’s bottom. Here’s a quick visual to help. Here’s the guide and the editView. It’s currently away from the top, so the awayFromTopConstraints are active. But, as you move the guide closer to the top, the awayFrom constraints are deactivated, and the nearTopConstraints are activated, dropping it down to the bottom of the view. When we’re back away from the top, the reverse happens. Now, let’s look at horizontal movement. When the keyboard is away from both the leading and trailing edges, I want the editView to be at the center of the keyboard. I want the imageView to be centered in the view, as well. So, I define those constraints and set them to be active when I’m away from both leading and trailing.

Now, let’s set up what happens when we approach an edge.

I want the editView to move over to trailing when we’re at the trailing edge, and leading to leading. So, first, let’s take care of that. I want the imageView to move out of the way of the keyboard a little, so when we’re near either edge, I move it from the center to the opposite side from the keyboard, leading to leading when the keyboard is on the trailing edge, and vice versa. Then, I just set these to be active when I’m near the proper edge. They’ll be activated when the keyboard crosses into that region, and deactivated when it leaves. And that’s it! Super advanced keyboard integration into your very own layout. Let’s take a look at what that looks like one more time. There’s my editView. It stays with the floating keyboard, and as we move towards the top, it drops to the bottom. And as we move side to side, the adjustments we just talked about happen. Pretty cool! Next, let’s talk about what «near» and «awayFrom» mean for the keyboard. A docked keyboard is considered to be near the bottom and awayFrom the other edges.

Undocked and split keyboards can be awayFrom all edges, or they can get near the top edge. When it’s the floating keyboard, it can be near or awayFrom any edge, and it can even be near two adjacent edges at the same time. This can lead to some potentially interesting conflicts that you should be aware of. Now, all of this only applies when you set followsUndockedKeyboard to true, and for the rest of the talk, that’s the assumption we’ll be making. Okay. Final stretch: considerations for full keyboard integration. A keyboard is a keyboard is a keyboard— until it’s not. When you choose to follow the undocked keyboard, you have some extra things to think about. So, what sorts of things should you be paying attention to when designing your layout? Always remember that the floating keyboard can be awayFrom everything. Do you have sufficient information to be laid out correctly if it’s awayFrom all edges? Also, what should happen when the keyboard is awayFrom the bottom edge, or near the top edge? You want to be careful with what’s tied to the topAnchor of the keyboard, as well. Because it can get way up there! So, be careful. The way to resolve that is to set constraints when the keyboard is awayFrom the bottom edge that move those views off of the topAnchor of the keyboard and down to the bottom of the safeAreaLayoutGuide.

A user can also move the keyboard at any time, so you can’t count on it being any where specific. You’ll wanna keep that in mind, as well.

Here’s a rare specimen: the split keyboard. Split and undocked keyboards are awayFrom all edges, until it gets too close to the top. As with a docked keyboard, it’s always away from leading and trailing, as well. Let’s talk about some new stuff. There’s a new way to get text into your app this year, using the camera.

It’s still a keyboard, so it will still be able to use the guide.

It’s the same as a regular docked keyboard, but it’s one of a few keyboards that can be pretty much full screen. To learn more about taking advantage of text input via camera this year, tune into «Use the camera for keyboard input in your app.» Continuing with new things, what about when there’s a hardware keyboard attached? Well, new this year, we have an adaptive shortcuts bar that is no longer always full-width. It changes width based on what language you’re using and how many buttons are in the bar.

Previously, it was always the full width of the screen, but now, if you’re following the undocked keyboard, you can actually use the real leading and trailing edges of the bar. So, what’s the story here with edges? This is always near the bottom and, in its normal position, it’s awayFrom the other three edges. But it’s collapsable! If you collapse it, it can also be near the leading or trailing edge.

This is one of several reasons why you might wanna be careful about using the widthAnchor of the keyboard, by the way. It can be very small, or it can be the full width of the screen. Now, let’s get into the most fun part of the tour: what about if you’re not the only app onscreen, and you’re following the undocked keyboard? First, remember that the keyboard can leave your app space. When that happens, we’re going to treat it as though it’s been dismissed. Second, when your app is at its narrowest, the top and bottom edges are in play, but leading and trailing will stay awayFrom, whether the keyboard is over your app or not. Also, the guide is sized for what part of the keyboard is over your app’s window, if you’re not the only thing onscreen. Let’s take a look at some visuals to show you what I mean.

All of this only applies if you have followsUndockedKeyboard set to true. If you haven’t, the guide is at the bottom of the screen, the full width of your window. When you’re full screen and the keyboard is floating and in the middle, you’re awayFrom everything. All of your awayFrom constraints have been activated, and all of your near constraints have been deactivated.

When another app is onscreen, if you’re the wider app, you’re still wide enough for the keyboard to be able to be awayFrom everything. But it needs to move less to be near a horizontal edge. This is similar to being in portrait, too. But, at half screen, the keyboard in the same spot is now near your leading edge, and the guide has gotten sized to match only the part of the keyboard that’s over your app.

When you’re the narrow app, the guide is always considered to be awayFrom the horizontal edges, the same as an iPhone or a docked keyboard, but you can still be near the top edge.

And notice that, again, the guide is sized to account for the portion over your app only. And when you dock the keyboard and it’s full sized again, it’s also away from leading, trailing, and top. And notice, again, that the layout guide is once again sized for what’s over your app. If you’re a slide-over app, it will resize for that, as well.

With the previous examples and our demo code, this should all be well-handled. You just have to keep in mind that you might be in any one of these scenarios. You should now be ready to bring your app to the next level of keyboard integration. So, use keyboard layout guide. If your app can, take advantage of the advanced features of UI tracking layout guide. And, most importantly, if you have been thinking about keyboard layout as fighting or avoiding the keyboard, start thinking about integrating it into your layout instead. And if you’ve already been thinking about it that way, now you have even more tools to realize your full vision.

That brings us to the end of our tour. Please make sure you have all your personal items before exiting, don’t forget to visit the gift shop, and have a great WWDC. [ethereal percussion music]

Looking for something specific? Enter a topic above and jump straight to the good stuff.

An error occurred when submitting your query. Please check your Internet connection and try again.

Источник