Como os códigos de chave são mapeados para a ação apropriada?

Depois de descobrir como alterar o mapeamento de códigos de verificação para códigos-chave usando udev, consulte esta pergunta . Eu estava pensando como esses códigos-chave (ou eventos, se você quiser) são mapeados para a ação apropriada.

Por exemplo, se você pressionar volume upo teclado, um código de digitalização será enviado, que será convertido no volumeupcódigo da tecla. Mas como esse código de chave é interceptado, o volume aumenta e a notificação apropriada é exibida?

Meu palpite é que em algum lugar um script deve ser chamado, então eu gostaria de saber onde estão esses scripts.

EDIT: Os códigos-chave que menciono não devem ser confundidos com os xevretornos dos códigos-chave , mas também estou interessado neles;)

Ok, encontrei isso em https://help.ubuntu.com/community/MultimediaKeys

Quando você pressiona uma tecla do teclado, o kernel do linux gera um scancode bruto para ela (se estiver atribuído). Cada scancode pode ser mapeado para um código de chave. Isso está no nível do kernel. X possui uma maneira (quase) total independente de mapear chaves: X lê a tabela de códigos de chave do kernel na inicialização e depois mapeia o código de chave para sua tabela de códigos de chave independente (é o mesmo que os códigos de chave do kernel, mas diferente :)). Em seguida, cada código-chave pode ser mapeado para um código-chave, ou seja, uma string que representa uma chave ou sugere uma ação. Portanto, para que nossas chaves estejam totalmente funcionais, elas precisam de um código de chave / código de chave do kernel mais um código de chave / código de chave X. Pode parecer estranho, mas os desenvolvedores do X têm motivos para manter um mapeamento de teclado separado do kernel. Não é nada difícil, apenas um procedimento bastante tedioso.

Então, os códigos de chave são mapeados para os chaves, então onde estão os códigos? Encontrei e respondo a esta pergunta: Onde encontro uma lista de todos os X academias de ginástica atualmente? Já que estamos falando sobre as teclas de volume, isso seria encontrado no XF86keysym.hcódigo-fonte mencionado na resposta.

Nesse arquivo no meu computador, encontrei o seguinte para volume:

#define XF86XK_AudioLowerVolume 0x1008FF11   /* Volume control down        */
#define XF86XK_AudioMute    0x1008FF12   /* Mute sound from the system */
#define XF86XK_AudioRaiseVolume 0x1008FF13   /* Volume control up          */

Estranho ... valores diferentes de qualquer outra coisa, talvez haja vários sistemas para manipular chaves? http://crunchbang.org/forums/viewtopic.php?id=16656

Estou usando o Xubuntu e, para controlar as teclas, preciso mapear as ações manualmente (como esta: Como altero os atalhos do teclado no xubuntu? ). No entanto, as notificações parecem independentes, como se estivessem pressionando a tecla e agindo de acordo. Isso pode significar que outros programas no Ubuntu são configurados dessa maneira, portanto, não há necessidade de mapear scripts para as teclas.

Portanto, tenho certeza de que os programas estão pegando a chave (portanto, nenhum script foi encontrado).

No Xubuntu, tive esse problema com o Pulse Audio e usando scripts personalizados para alterar o volume. Parecia que o Pulse estava interceptando a tecla Mute , a tecla Mute silencia Alsa e PulseAudio, mas reativa o som apenas Alsa para soluções alternativas interessantes.

Verifique isso no NotifyOSD https://wiki.ubuntu.com/NotifyOSD#Volume_changes

Se você olhar para Estes diagramas: https://wiki.ubuntu.com/NotifyOSD#Architecture

Especialmente este:

Isso mostra que existe um "ouvinte de chaves de hardware" que recebe o formulário DBus ou HAL? Em seguida, "recupera o elemento visual do sistema", onde os ícones de som e brilho estão na fonte do Notify-OSD, e então faz a bolha a partir daí.

Isso tudo é muito confuso, mas até onde eu entendi (até agora):

scancode bruto (por exemplo, e016)> código-chave (por exemplo, 160)> keysym (por exemplo, XF86AudioMute)> gnome-settings-daemon (por exemplo, aumento de volume)> sinal DBus> sinal de escuta de hardware para o OSD de notificação (ou outro escuta de programa)

Na maioria dos casos, não há scripts executados. Eles fazem com que os eventos sejam enviados ao gerenciador de janelas ou ao daemon de configurações. A única vez que conheço scripts no processo é quando você configura as ligações de teclas personalizadas. Para ligações de teclas personalizadas, você pode adicionar linhas de comando (executáveis ​​ou scripts) e vinculá-las às chaves.

Por favor, veja esta resposta que escrevi para uma pergunta sobre como fazer backup de atalhos de teclado no Ubuntu: Onde estão armazenados os atalhos de teclado do GNOME? Eu tenho um script que faz backup ou restaura todas as combinações de teclas, incluindo as combinações de teclas personalizadas. Se você executar o script, poderá ver onde no dconf as combinações de teclas estão armazenadas e qual aplicativo é notificado sobre o evento-chave.

A resposta está relacionada a Drivers .

Todo hardware deve ter um driver para interagir com o sistema operacional.

Citando http://www.linuxforu.com/2010/11/understanding-linux-device-drivers/ :

Um motorista dirige, gerencia, controla, dirige e monitora a entidade sob seu comando. O que um driver de barramento faz com um barramento, um driver de dispositivo faz com um dispositivo de computador (qualquer peça de hardware conectada a um computador) como mouse, teclado, monitor, disco rígido, câmera Web, relógio e muito mais.

Além disso, um “piloto” pode ser uma pessoa ou até um sistema automático monitorado por uma pessoa (um sistema de piloto automático em aviões, por exemplo). Da mesma forma, uma peça específica de hardware pode ser controlada por um software (um driver de dispositivo) ou por outro dispositivo de hardware, que por sua vez pode ser gerenciado por um driver de dispositivo de software. Neste último caso, esse dispositivo de controle é comumente chamado de controlador de dispositivo. Por ser um dispositivo propriamente dito, muitas vezes também precisa de um motorista, geralmente chamado de motorista de ônibus.

Um dispositivo possui um registro de dispositivo que armazena os bits de Controle / Status e Dados. Sempre que alguns dados precisam ser transferidos, geralmente são enviados configurando os bits de dados.

Portanto, sempre que você pressiona alguma tecla do teclado, alguns dados são gravados no registro. Esses bits são lidos pelo driver do dispositivo e a ação apropriada é executada. Esta é a breve explicação.

Ligações:

• Se você estiver interessado, recomendo que você leia esta série em Drivers de dispositivos, composta por 17 artigos bem escritos por linuxforu : http://www.linuxforu.com/tag/linux-device-drivers-series/ .

• Você pode ler o documento específico que contém instruções sobre como gravar um driver de dispositivo para teclado USB: http://www.emntech.com/docs/USB_KeyBoard_Driver_eMNTech.pdf

• Se você está muito empolgado com os drivers de dispositivo Linux, leia o livro "Linux Device Drivers", disponível gratuitamente em pdf: http://lwn.net/Kernel/LDD3/