Mehrere Tastaturen verschieden behandeln?

18/07/2009 - 12:42 von Stefan | Report spam
In einer Diskussion wurde die Frage aufgeworfen, was nötig wàre, um
mehrere gleichzeitig angeschlossene Tastaturen gezielt verschieden zu
behandeln. (Also z.B. eine Tastatur deutsch und die andere Englisch oder
eine Tastatur mit Funktionen zu belegen etc.) Da die Tastaturen ja
individuelle Adressen haben, sollte das grundsàtzlich möglich sein, das
Betriebssystem stellt eine solche Funktion aber nicht zur Verfügung.

Wàre sowas mit einem einfachen "Hack" zu erreichen oder müsste man da
ganz tief im System rumprogrammieren? (Man möge die naive Formulierung
eines Nichtprogrammierers entschuldigen.)
 

Lesen sie die antworten

#1 spamfalle2
18/07/2009 - 13:50 | Warnen spam
Stefan wrote:

In einer Diskussion wurde die Frage aufgeworfen, was nötig wàre, um
mehrere gleichzeitig angeschlossene Tastaturen gezielt verschieden zu
behandeln. (Also z.B. eine Tastatur deutsch und die andere Englisch oder
eine Tastatur mit Funktionen zu belegen etc.) Da die Tastaturen ja
individuelle Adressen haben, sollte das grundsàtzlich möglich sein, das
Betriebssystem stellt eine solche Funktion aber nicht zur Verfügung.

Wàre sowas mit einem einfachen "Hack" zu erreichen oder müsste man da
ganz tief im System rumprogrammieren? (Man möge die naive Formulierung
eines Nichtprogrammierers entschuldigen.)



Dieses Problem hatte ich 2007 schonmal versucht zu lösen:

Betreff: [OT] Aluminium iMac keyboard
Datum: 18. September 2007 11:54:24 MESZ
An:

This is not really a Carbon question, but since the most knowledgeable
people in the Apple Universe are reading this...

I just recently got my new MacBook Pro (with german keyboard), and since
I like to use an english keyboard for programming I bought the new iMac
aluminium USB keyboard in "intl.engl.".
The keyboard driver is more than 30MB, and re-maps the function keys to
the system function imprinted on the keys regardless of what mapping I
set in system preferences for exposée, screensaver, etc. So the driver
clearly can differentiate between the keyboards.
But, the main keys still share the input source language. That is, I can
either set the language to german to match the MacBook internal
keyboard, or to english to match the external aluminium keyboard. But
this is quite useless - I bought the intl.engl. keyboard with the sole
purpose to have an english layout on it while still be able to have the
german layout (e.g. for umlauts àöüß) on the MacBook keyboard at the
same time without language switching.

With monitors, you can set different sizes and color depths for each
device. The same should be possible with input devices, at least with
keyboards.
Apple could make a fortune selling those intl.engl. aluminium keyboards
to programmers worldwide...
If you live in the US, UK or AUS you probably don't have this problem,
but everyone else does!


Is there a possibility to modify/patch the keyboard driver so it uses a
fixed key table (intl.engl.) for the external keyboard though the main
input source language is set to e.g. german and will be used for the
MacBook internal keyboard?

Or, are the sources of the aluminium keyboard driver in the Darwin
archives already? Then I would try to modify them myself...




Betreff: Re: [OT] Aluminium iMac keyboard
Datum: 18. September 2007 21:25:58 MESZ
An:


On 18.09.2007, at 17:22, Eric Schlegel wrote:

On Sep 18, 2007, at 2:54 AM, Marc Stibane wrote:

Is there a possibility to modify/patch the keyboard driver so it uses
a fixed key table (intl.engl.) for the external keyboard though the
main input source language is set to e.g. german and will be used for
the MacBook internal keyboard?



(I'm not an expert here, but I've worked with the experts, so here's my
understanding...)

The issue would probably not be in the keyboard driver itself (at the
IOKit/HID Manager level), but rather at the Text Services Manager and
Input Sources Manager level.

The keyboard driver will just generate virtual keycodes. Those aren't
in a US layout or a German layout or any other layout; they just
identify the physical keys on the keyboard.

Once the keycodes arrive at the application, they are mapped through
the current keyboard layout to generate actual Unichars. That's where
your problem would be.



Yes, probably. But the aluminium keyboard driver can re-map the function
keys of the external keyboard to their imprinted function (e.g. F3 Exposée and F12 = Volume increase) while the internal MacBook function
keys still have THEIR imprinted function (F3 = Mute) or the function I
have set in the system prefs (F12 = Exposée).

But I agree - those are all special functions which never make it to the
application.


There's only a single active keyboard layout; you'd need to have
support for multiple keyboard layouts, one for each keyboard. I don't
think that Input Sources actually supports that (although it is an
interesting idea).



Sure it is. The best example is what I want to achieve - my native
language on the MacBook Pro internal keyboard and english on the
intl.engl. aluminium keyboard I just use for programming. I really think
thousands of programmers worldwide would love this, too. You can keep
the idea and get the merits for selling some thousand keyboards ;-)

If you can have different settings for different output devices
(monitors) - why not for different keyboards?
And there's already different settings for trackpad and mouse, too.



Betreff: Re: [OT] Aluminium iMac keyboard
Datum: 19. September 2007 17:15:15 MESZ
An:
Kopie:

On 18.09.2007, at 21:41, Eric Schlegel wrote:
On Sep 18, 2007, at 12:25 PM, Marc Stibane wrote:

There's only a single active keyboard layout; you'd need to have
support for multiple keyboard layouts, one for each keyboard. I don't
think that Input Sources actually supports that (although it is an
interesting idea).



Sure it is. The best example is what I want to achieve - my native
language on the MacBook Pro internal keyboard and english on the
intl.engl. aluminium keyboard I just use for programming. I really
think thousands of programmers worldwide would love this, too. You can
keep the idea and get the merits for selling some thousand keyboards
;-)



Sure. File a bug! Maybe we can provide this in a future version of Mac
OS X.



rdar://5491599


Von:
Betreff: Re: [OT] Aluminium iMac keyboard
Datum: 18. September 2007 19:00:41 MESZ
An:

On Sep 18, 2007, at 8:22 AM, Eric Schlegel wrote:
On Sep 18, 2007, at 2:54 AM, Marc Stibane wrote:

Is there a possibility to modify/patch the keyboard driver so it uses
a fixed key table (intl.engl.) for the external keyboard though the
main input source language is set to e.g. german and will be used for
the MacBook internal keyboard?



(I'm not an expert here, but I've worked with the experts, so here's my
understanding...)

The issue would probably not be in the keyboard driver itself (at the
IOKit/HID Manager level), but rather at the Text Services Manager and
Input Sources Manager level.

The keyboard driver will just generate virtual keycodes. Those aren't
in a US layout or a German layout or any other layout; they just
identify the physical keys on the keyboard.

Once the keycodes arrive at the application, they are mapped through
the current keyboard layout to generate actual Unichars. That's where
your problem would be. There's only a single active keyboard layout;
you'd need to have support for multiple keyboard layouts, one for each
keyboard. I don't think that Input Sources actually supports that
(although it is an interesting idea).

-eric



I'll confirm what Eric says. The current keyboard layout is used for
System-provided key event translation, but you can perform your own key
translation (using UCKeyTranslate) using keyboard layout data for any
keyboard, not just the currently selected one. The TISInputSource API
in Leopard will help here... track down the desired keyboard layout
input source, extract its layout data, and use that with UCKeyTranslate.

You'd have to do the work to detect which keyboard originated the events
(perhaps using IOKit/HID). Then your app could translate events itself,
though there is a bit of work to replicate the behavior you get from the
System for free, such as dead-key handling and the UI for this.

If this is not app-specific, but for system-wide behavior, you could
look at implementing an input method using the (new in Leopard)
InputMethodKit, and implement 2 input modes. One mode could be a sort
of pass-thru mode that respects the user's selection (conceptually
similar to Apple's Japanese input method 's Romaji input in Kotoeri),
and the other mode for your fixed keyboard, implemented as a keyboard
layout "override". But you'd still have to do the work in your input
method to detect when to switch input modes. The advantage would be
that all key translation is taken care of for you.

Michael Grady

In a world without walls and fences,
who needs windows and gates?

Ähnliche fragen