On Wed, Oct 10, 2001 at 08:21:45PM -0500, Branden Robinson wrote:
>On Wed, Oct 10, 2001 at 04:05:23PM -0800, Ethan Benson wrote:
>> the trouble is nobody can agree whether `command == meta' is `wrong'
>> or not.
>>
>> given the option key is the one with `alt' engraved on it one would
>> presume
On Thu, 11 Oct 2001, Charles Sebold wrote:
> > Please note that the Capslock -> Control thing will only work if you
> > use a hacked kernel...
>
> Or if you have one of the new full-size Apple keyboards, in which
> CapsLock is a normal key, or replace your Apple keyboard with somebody
> else's PC-
On 24 Tishrei 5762, Gregory P. Keeney wrote:
> Please note that the Capslock -> Control thing will only work if you
> use a hacked kernel...
Or if you have one of the new full-size Apple keyboards, in which
CapsLock is a normal key, or replace your Apple keyboard with somebody
else's PC-style USB
On Thu, 2001-10-11 at 09:16, Wilhelm *Rafial* Fitzpatrick wrote:
> How do you set this up? By default alt == meta, so I'm currently
> using emacs that way, but my fingers really want meta to be the
> command key. How can I tell emacs to use the command key instead?
If you have your modifier bi
At 7:58 AM -0700 10/11/01, Gregory P. Keeney wrote:
Of course us poor incorrigible emacs user are quite happy with the
command key being were it is, and making option Alt... That way, the
command key becomes Meta, and we have both Meta and Alt... (Throw in a
Hyper and Super, and let the custom ke
On Thu, 2001-10-11 at 02:43, Ethan Benson wrote:
> I agree, the key labeled alt should be alt by default. However the
> fact is Apple's keyboards put alt in the wrong damn place and anyone
> who has ever typed on a normal keyboard will be annoyed as hell at
> this and thus need a trivial and quick
Ethan Benson wrote:
>
> On Wed, Oct 10, 2001 at 06:49:26PM -0500, Branden Robinson wrote:
> >
> > As far as hacking keymaps goes, yes. If the xkb data is wrong for a
> > model of keyboard, I think it should be fixed and I'd like to receive
> > patches to this effect.
>
> the trouble is nobody ca
On Wed, Oct 10, 2001 at 08:21:45PM -0500, Branden Robinson wrote:
>
> These are easily taken care of with little option files that you can
> manipulate with XKbOption. Like "ctrl:nocaps" on the PC keyboard.
>
> It's not an insuperable problem at all.
>
> (Though how anyone can expect the "alt"
On Wed, Oct 10, 2001 at 04:05:23PM -0800, Ethan Benson wrote:
> the trouble is nobody can agree whether `command == meta' is `wrong'
> or not.
>
> given the option key is the one with `alt' engraved on it one would
> presume it should be treated as alt, regardless of the fact that apple
> put it
On Wed, Oct 10, 2001 at 06:49:26PM -0500, Branden Robinson wrote:
>
> As far as hacking keymaps goes, yes. If the xkb data is wrong for a
> model of keyboard, I think it should be fixed and I'd like to receive
> patches to this effect.
the trouble is nobody can agree whether `command == meta' is
On Wed, Oct 10, 2001 at 03:26:30PM -0800, Ethan Benson wrote:
> what for? Branden has already `fixed' the Xsession scripts to ignore
> /etc/X11/Xmodmap as well as the ~/.Xmodmap (or whatever) since xmodmap
> is allegedly `deprecated'
>
> apparently were supposed to just hack the raw keymaps themse
On Wed, Oct 10, 2001 at 03:25:33PM -0400, Adam C Powell IV wrote:
> Ethan Benson wrote:
>
> >http://master.penguinppc.org/~eb/Xmodmap
> >
> Thanks very much, this looks great! I'll fiddle with it slightly on my
> setup so both alt and meta are on 115 and 116.
>
> Can we suggest that to Branden
On Wed, Oct 10, 2001 at 03:25:33PM -0400, Adam C Powell IV wrote:
> That's very odd. ~/.Xmodmap still seems to work, are you saying
> /etc/X11/Xmodmap will no longer be used? Bummer!
xmodmap is now deprecated but not difficult to support. I continue to
ship the old /etc/X11/Xmodmap in xfree86-
Ethan Benson wrote:
http://master.penguinppc.org/~eb/Xmodmap
Thanks very much, this looks great! I'll fiddle with it slightly on my
setup so both alt and meta are on 115 and 116.
Can we suggest that to Branden for (commented) inclusion in
/etc/X11/Xmodmap (or have you done so already)?
> keycode 115 = Alt_L
> keycode 125 = Alt_L
> keycode 126 = Alt_L
>
> The command keys do nothing here... Any ideas?
Try adding the following line after the above:
add mod1 = Alt_L
See 'man xmodmap' for details.
http://master.penguinppc.org/~eb/Xmodmap
note this won't work with the XFree packages in sid since xmodmap
support has been removed from the Xsession scripts since its allegedly
`deprecated' and as far as anyone has told me no replacement has been
documented. (other then fscking with the keymap
Greetings,
Using Linux keycodes, I'm trying to map the command keys (next to the
spacebar on an ADB keyboard) to alt using xmodmap, but nothing I've
tried works. [I use the alt keys for button emulation, keycodes 56 and
100; would like command for alt since alt is next to the sp
On Mon, Sep 17, 2001 at 11:24:03PM +0200, Michael Schmitz wrote:
> > > That'll bring you back to default booting MacOS if a) you keep it
> > > installed and b) your boot-device variable ever gets reset (a hard
> > > kernel crash often does that for me). OF seems to default to the
> > > first 'bless
> > That'll bring you back to default booting MacOS if a) you keep it
> > installed and b) your boot-device variable ever gets reset (a hard
> > kernel crash often does that for me). OF seems to default to the
> > first 'blessed' filesystem it can find, that's why having the
> > bootstrap partition
Michael Schmitz <[EMAIL PROTECTED]> writes:
> That'll bring you back to default booting MacOS if a) you keep it
> installed and b) your boot-device variable ever gets reset (a hard
> kernel crash often does that for me). OF seems to default to the
> first 'blessed' filesystem it can find, that's w
On Mon, Sep 17, 2001 at 09:53:09AM +0200, Michael Schmitz wrote:
> Regardless of what Ethan thinks, I'm a far cry from a clueless newbie.
i don't think your a clueless newbie.
> Now imagine the newbie, having partitioned and set up his system the Wrong
> Way (tm), then forgotten about the detai
> > crash often does that for me). OF seems to default to the first 'blessed'
> > filesystem it can find, that's why having the bootstrap partition first is
> > nicer.
>
> Um. You still have Command-Option-O-F, which will get you to an OF prompt,
> at which point you can do 'boot hd:13,\\:tbxi' (ch
On Sun, Sep 16, 2001 at 09:53:15AM +0200, Michel Lanners wrote:
>
> Remember that physical order on disk doesn't necessarily mean the same
> thing as order in the partition map.
correct.
> AFAIR, you can have your partitions physically in any order you want
> (with the one exception beeing the f
Folks,
On 15 Sep, this message from Ethan Benson echoed through cyberspace:
> On Sat, Sep 15, 2001 at 12:50:28PM -0600, Derrik Pates wrote:
>>
>> The partition's location doesn't matter. Remember, you don't have to deal
>
> yes it does. OF won't boot it by default from default settings if its
On Sat, Sep 15, 2001 at 02:23:09PM -0600, Derrik Pates wrote:
> On Sat, 15 Sep 2001, Michael Schmitz wrote:
>
> > That'll bring you back to default booting MacOS if a) you keep it
> > installed and b) your boot-device variable ever gets reset (a hard kernel
> > crash often does that for me). OF se
On Sat, Sep 15, 2001 at 12:50:28PM -0600, Derrik Pates wrote:
>
> The partition's location doesn't matter. Remember, you don't have to deal
yes it does. OF won't boot it by default from default settings if its
not first.
--
Ethan Benson
http://www.alaska.net/~erbenson/
pgpQhk6aRFkiU.pgp
De
On Sat, Sep 15, 2001 at 08:01:07PM +0200, Roland Wegmann wrote:
> /dev/hda1 Apple_partition_map Apple
> /dev/hda2 Apple_Driver43 Macintosh
> /dev/hda3 Apple_Driver43 Macintosh
> /dev/hda4 Apple_Driver_ATA Macintosh
> /dev/hda5 Apple_Driver_ATA Macintosh
> /dev/hda6 Apple_FWDri
On Sat, 15 Sep 2001, Michael Schmitz wrote:
> That'll bring you back to default booting MacOS if a) you keep it
> installed and b) your boot-device variable ever gets reset (a hard kernel
> crash often does that for me). OF seems to default to the first 'blessed'
> filesystem it can find, that's w
> The partition's location doesn't matter. Remember, you don't have to deal
> with the broken BIOS that x86's have, and all the ass-backwards
> limitations of real mode, so it can be at the beginning or the end (on an
> iBook I've been using, the Apple_Bootstrap partition is the last one on
> the d
On Sat, 15 Sep 2001, Roland Wegmann wrote:
> Now I can't use vi anymore. But I need it to modify "yaboot.conf" etc. When
> I type for example "vi sources.list" I got the message "vi: wrapper couldn't
> execute /usr/bin/vi nor /bin/elvis-tiny". What's wrong with vi?
Do you have nvi installed? If s
Roland Wegmann wrote:
> Secondly, I want to change my keyboard layout from US to Swiss german (or at
> least German). On this maillist I heard a lot about linux keycodes. After my
> difficulties with "console common" I may ask you if linux keycodes are
> another way to a
erman (or at
least German). On this maillist I heard a lot about linux keycodes. After my
difficulties with "console common" I may ask you if linux keycodes are
another way to adapt the keyboard? Are there any howto's or examples on this
topic?
Thirdly, I have a semi installed yaboo
> I tried using the 0xff keycode first, to no effect. I looked at the
> iControl code and saw that the key code used was 127 (0x7f); that
The keycode is masked with 0x7f as the high bit is used to distinguish
press from release.
> worked. I have a TiBook... Are the keycodes different, or am I mis
> On Fri, 31 Aug 2001 10:15:11 -0700, "Gregory P. Keeney" <[EMAIL
> PROTECTED]> said:
g> I tried using the 0xff keycode first, to no effect. I looked at the
g> iControl code and saw that the key code used was 127 (0x7f); that
g> worked. I have a TiBook... Are the keycodes different, or am
On 30 Aug 2001 23:57:16 -0700, [EMAIL PROTECTED] wrote:
> What problems did you experience? My first attempt was
> similar and I noticed that it would occassionally get into a bad
> state, as if a spurious 0xff keycode has caused the temp state
> variable for the CapsLock key to be "invert
> On Wed, 29 Aug 2001 11:01:35 +0200 (CEST), Michael Schmitz <[EMAIL
> PROTECTED]> said:
[clone keyboard:]
>> >> 1st press:0x39
>> >> 1st release: 0x80
>> >> 2nd press:0xb9
>> >> 2nd release: 0x80
>>
>> As noted previously, the PowerBook CapsLock generates:
>>
>> 1st press:
> On Tue, 28 Aug 2001 09:05:36 -0700, "Gregory P. Keeney" <[EMAIL
> PROTECTED]> said:
g> I would recomend not using the diff I posted... There are some problems
g> (which others, more wise than I,predicted). I really don't know anything
g> of how ADB works, and I have no previous experien
> Thanks for answering my silly question. I've got this three button
> adb mouse, you see, but I've never been able to get the other two
> mouse buttons to do anything other than act like the first one. I'd
This usually means the mouse powers up in a Mac mouse compatible mode, and
the MacOS driv
Michael Schmitz wrote:
>
> > What about mouse data on the adb bus? Would the device address be
> > the resolution for whether it is mouse or keyboard?
>
> The mouse data packets will have a different device address
> (data[0]>>4) & 0xf, so you can filter on that for debugging purpose (the
> adbh
> What about mouse data on the adb bus? Would the device address be
> the resolution for whether it is mouse or keyboard?
The mouse data packets will have a different device address
(data[0]>>4) & 0xf, so you can filter on that for debugging purpose (the
adbhid input routine returns if the device
What about mouse data on the adb bus? Would the device address be
the resolution for whether it is mouse or keyboard?
a
Michael Schmitz wrote:
>
> > >From the iControl code, it would appear that there is more to an ADB
> > event than just the key code... And that there is enough extra
> > infor
> >From the iControl code, it would appear that there is more to an ADB
> event than just the key code... And that there is enough extra
> information to determine whether the event is a caps-lock event or not.
What additional information would there be? (The only place it could
possibly be is the
I would recomend not using the diff I posted... There are some problems
(which others, more wise than I,predicted). I really don't know anything
of how ADB works, and I have no previous experience working with the
linux kernel. I really had no grounds to expect my code to work
correctly.
>From the
> >> 1st press:0x39
> >> 1st release: 0x80
> >> 2nd press:0xb9
> >> 2nd release: 0x80
>
> As noted previously, the PowerBook CapsLock generates:
>
> 1st press:0x39
> 1st release: 0xff
> 2nd press:0xff
> 2nd release: 0xb9
>
> Note the difference in order of events for second
> On Wed, 29 Aug 2001 09:47:43 +0200 (CEST), Michael Schmitz <[EMAIL
> PROTECTED]> said:
>> Well, I know of at least one other type of ADB keyboard where
>> this wouldn't work. The keyboard on my old PowerWave generates
>> different events for CapsLock:
>>
>> 1st press:0x39
>> 1st r
> Well, I know of at least one other type of ADB keyboard where
> this wouldn't work. The keyboard on my old PowerWave generates
> different events for CapsLock:
>
> 1st press:0x39
> 1st release: 0x80
> 2nd press:0xb9
> 2nd release: 0x80
>
> So that requires a different hack to
> On Tue, 28 Aug 2001 14:47:45 +0200 (CEST), Michael Schmitz <[EMAIL
> PROTECTED]> said:
m> Caution with the 0xff response byte - I think I've seen that as first byte
m> for a number of 'sporadic' ADB events as well, such as regular interrupts
m> from the ADB controller once a second (on
Richard Clamp wrote:
Don't just tease, please post a patch, and we'll love you forever :)
Below is my attempt to implement the Cap Lock fix. It seems to work on
my TiBook (but then again I have only been using my modified kernel
for about 5 minutes...).
Hope this is usefull.
Gregory P. Keen
> > So, I tried a quick hack in adbhid_input_keycode
> > (drivers/macintosh/adbhid.c)
> > to translate the events appropriately and it seems to work (at last!).
>
> Don't just tease, please post a patch, and we'll love you forever :)
Caution with the 0xff response byte - I think I've seen that as
On Mon, Aug 27, 2001 at 10:06:00PM -0700, Gregorio Gervasio Jr. wrote:
> So, I tried a quick hack in adbhid_input_keycode (drivers/macintosh/adbhid.c)
> to translate the events appropriately and it seems to work (at last!).
Don't just tease, please post a patch, and we'll love you forever :)
--
> On Mon, 27 Aug 2001 19:55:01 -0400, Adam Lazur <[EMAIL PROTECTED]> said:
>> That is sort of what I did. However, the way the caps lock key works
>> makes it impracticle: The keypress event is sent when you first press
>> the key... The key release event is sent when the key is released the
>
Gregory P. Keeney ([EMAIL PROTECTED]) said:
> That is sort of what I did. However, the way the caps lock key works
> makes it impracticle: The keypress event is sent when you first press
> the key... The key release event is sent when the key is released the
> second time. This leads to rather inco
Gregory P. Keeney writes:
> [Albert Cahalan]
>> So for a Ctrl-A you get:
>>
>> 1. crummy key down
>> 2. 'A' key down
>> 3. 'A' key up
>> 4. generate synthetic key-up event for the crummy key
>
> That is sort of what I did. However, the way the caps lock key works
> makes it impracticle: The keypre
Michael Schmitz wrote:
Haven't we hashed this out previously here?
Michael
A couple times...
Thanks for the more accurate description of the problem.
Gregory P. Keeney
> That is sort of what I did. However, the way the caps lock key works
> makes it impracticle: The keypress event is sent when you first press
> the key... The key release event is sent when the key is released the
Nope, it's subtly different: a release event is inserted each time the key
is press
"Gregory P. Keeney" <[EMAIL PROTECTED]> writes:
> Particularly, the following post:
> http://www.macslash.com/comments.pl?sid=01/08/23/1916219&cid=7
Um, wow. I don't think I'm quite ready to go there yet :)
That is sort of what I did. However, the way the caps lock key works
makes it impracticle: The keypress event is sent when you first press
the key... The key release event is sent when the key is released the
second time. This leads to rather inconsistant behaivior. The
workaround would be to tra
Gregory P. Keeney writes:
> Particularly, the following post:
> http://www.macslash.com/comments.pl?sid=01/08/23/1916219&cid=7
>
> Well, now I know where to begin. The only thing stopping me from doing
> this tonight is the cost of a backup keyboard... Maybe I will pick up
> an inexpensive USB ke
I just found the following on MacSlash:
http://www.macslash.com/articles/01/08/23/1916219.shtml
Particularly, the following post:
http://www.macslash.com/comments.pl?sid=01/08/23/1916219&cid=7
Well, now I know where to begin. The only thing stopping me from doing
this tonight is the cost of a b
Ethan Benson wrote:
On Mon, Aug 20, 2001 at 02:26:45AM +0900, Marshal Wong wrote:
I'm running a PowerBook Prismo, and I have a Japanese USB Apple Pro
Keyboard. Under the new keycodes, everything seems to work fine under
the console, but under X, only the main keyboard works correctly. The
On Mon, Aug 20, 2001 at 12:20:22 -0700, NeilFred Picciotto wrote:
> but! "alt" is now the option key instead of the command key...
On my iBook Dual USB with US keyboard, the option key is:
/\
| alt|
| option |
\/
Sound keymap does right thing now ;-)
--
E
On Mon, Aug 20, 2001 at 12:20:22PM -0700, NeilFred Picciotto wrote:
> just made the switch to linux keycodes on my Pismo running woody with
> benh's rsync kernel. i've got the "keyboard_sends_linux_keycodes=1" thing
> in the append line of my yaboot.conf, an
On 1 Elul 5761, Colin Walters wrote:
> But the real solution is to send mail to Apple and ask them to fix
> their hardware.
Sad, because they finally shipped a keyboard for their desktop
machines that handles this correctly (the "new" Apple keyboard which
has been shipping with everything for the
NeilFred Picciotto <[EMAIL PROTECTED]> writes:
> but! "alt" is now the option key instead of the command key...
> searching the archive of this list, i see mentions of this fact,
> including someone saying it's easy to switch that back. but they
> didn't say *how* to do so, only that it's easy..
> On Mon, 20 Aug 2001 13:13:07 -0700, "Gregory P. Keeney" <[EMAIL
> PROTECTED]> said:
g> Sadly, this nasty business of the Caps-Lock key is done in the
g> hardware on Powerbooks. This is causes me incredible frustration with
g> my TiBook (especially after a long session in emacs...). I ha
"Gregory P. Keeney" <[EMAIL PROTECTED]> writes:
> Sadly, this nasty business of the Caps-Lock key is done in the
> hardware on Powerbooks. This is causes me incredible frustration
> with my TiBook (especially after a long session in emacs...).
Yeah, I agree completely. One thing that has made i
NeilFred Picciotto wrote:
> but! "alt" is now the option key instead of the command key...
Try an Apple USB keymap in console. In X, you'll have to use xmodmap(1x).
> searching the archive of this list, i see mentions of this fact, including
> someone saying it's easy to switch that back. but
"Colin Walters" <[EMAIL PROTECTED]> writes:
> NeilFred Picciotto <[EMAIL PROTECTED]> writes:
>
> > oh, and on the subject of the keyboard, is it still the case that
> > there's no way to make Pismo's caps-lock key be control?
>
> Yep, I believe this is because they key press generates one hard
t made the switch to linux keycodes on my Pismo running woody with
benh's rsync kernel. i've got the "keyboard_sends_linux_keycodes=1" thing
in the append line of my yaboot.conf, and i've got "powerpcps2" in my
XF86Config-4, so for the most part keys work, both
NeilFred Picciotto <[EMAIL PROTECTED]> writes:
> oh, and on the subject of the keyboard, is it still the case that
> there's no way to make Pismo's caps-lock key be control?
Yep, I believe this is because they key press generates one hardware
interrupt, but the key-up never generates an interru
just made the switch to linux keycodes on my Pismo running woody with
benh's rsync kernel. i've got the "keyboard_sends_linux_keycodes=1" thing
in the append line of my yaboot.conf, and i've got "powerpcps2" in my
XF86Config-4, so for the most part keys work,
On Mon, Aug 20, 2001 at 02:26:45AM +0900, Marshal Wong wrote:
> I'm running a PowerBook Prismo, and I have a Japanese USB Apple Pro
> Keyboard. Under the new keycodes, everything seems to work fine under
> the console, but under X, only the main keyboard works correctly. The
> "extended" part, l
Hi everyone,
I just updated console-data from testing, and I followed the
instructions, but it foobared the keyboard. BUT, no worries, I was
able to boot off a rescue disk and everything is fine now, except for
one thing...
I'm running a PowerBook Prismo, and I have a Japanese USB Apple Pro
Keyb
Geert Uytterhoeven wrote:
> I still have the idea that Linux keycodes are the evil PC AT keycodes we
> once wanted to use on m68k, but ditched very soon thereafter.
I'm pretty sure that they're not 100% the same. Let's hope that makes the
difference. :)
> If not, should
'powerpc/prep' => [ 'pc' ],
> > > >
> > > > Hmm, most are using 'pc' already; do the current Mac keymaps even make
> > > > sense anymore?
> > >
> > > Let's ask the CHRP guy(s) (hi Geert :). At any rate,
are using 'pc' already; do the current Mac keymaps even make
> > > sense anymore?
> >
> > Let's ask the CHRP guy(s) (hi Geert :). At any rate, I think we should
> > leave them available for those who absolutely want to still use ADB
> > keycodes.
>
On Thu, 2 Aug 2001, Michel Dänzer wrote:
> Martin Michlmayr wrote:
> > I'm not sure I understand you. If we add them to the specific keymap
> > list, to which one? pc or mac? i.e. where are people most likely to
> > use those keyboards?
> >
> > 'powerpc/a
; Without the mac- prefix? So for the i386/pc keymaps?
Yes, the maps are for Linux keycodes.
> > make that a suffix to add them to the choice of the specific keymap,
> > but I don't know enough about console-{data,common} to be sure.
>
> I'm not sure I understand
On Mon, Jul 30, Stefan Haller wrote:
> > this also eliminates the need to maintain separate keymaps for
> > standard keyboards, no more need for a mac version and a i386 version
> > and a sparc version etc etc.
>
> Ethan, you keep ignoring the fact that this is only true for US
> keyboards. We
On Mon, Jul 30, 2001 at 11:03:23AM +0200, Stefan Haller wrote:
> > this also eliminates the need to maintain separate keymaps for
> > standard keyboards, no more need for a mac version and a i386 version
> > and a sparc version etc etc.
>
> Ethan, you keep ignoring the fact that this is only tru
> this also eliminates the need to maintain separate keymaps for
> standard keyboards, no more need for a mac version and a i386 version
> and a sparc version etc etc.
Ethan, you keep ignoring the fact that this is only true for US
keyboards. We do need separate keymaps for non-US Apple keyboar
the main differences between the Mac OS keycodes and those of Linux?
linux keycodes are the same as used on i386, this way you can take any
USB keyboard plug it in your mac and have it work properly. that
won't work with adb keycodes.
this also eliminates the need to maintain separate keymaps fo
Hello everyone,
I'm reading all this discussion on the keycodes and such...but I don't quite
understand. If there's some basic docs about this, point me to them. If there
is a keymap (similar to the Mac OS desk accessory that shows each key and
what it is and where it is on the keyboard, and ev
On Mon, Jul 02, 2001 at 07:22:32PM -0700, Matt Brubeck wrote:
> On Mon, 2 Jul 2001, Ethan Benson wrote:
>
> > * console-data when upgraded from previous versions will check the
> > status of the dev/mac_hid/keyboard_sends_linux_keycodes sysctl:
> > - If the sysctl does not exist at all we ha
On Mon, 2 Jul 2001, Ethan Benson wrote:
> * console-data when upgraded from previous versions will check the
> status of the dev/mac_hid/keyboard_sends_linux_keycodes sysctl:
> - If the sysctl does not exist at all we have either a custom,
> misconfigured kernel, or a very old pota
I believe you meant to send this to the list...
- Forwarded message from Duncan Sands <[EMAIL PROTECTED]> -
Date: Mon, 2 Jul 2001 21:38:21 +0200
To: "David J. Roundy" <[EMAIL PROTECTED]>
Subject: Re: [RFC] Proposed transition plan for adb -> linux keycodes
F
On Mon, Jul 02, 2001 at 04:45:56AM -0800, Ethan Benson wrote:
>
> One other possibility is have Option 1 also create a new temporary
> initscript with the following and link it to 06 in runlevel S:
>
> /etc/init.d/keycode-fix.sh
> #!/bin/sh
>
> if [ "$(/sbin/sysctl -n dev/mac_hid/keyboard_sends_
eded as, even with linux keycodes, PC keymaps
> won't be ok for a lot of international Mac keyboards. Apple tend to
> use a different layout.
are there any maps available anywhere? from what i have heard the
other distros have already, or will shortly switch to linux keycodes,
are they
>This is all still a bit rough, I am looking for comments and
>suggestions on how to proceed. I want this transition to occur for
>woody so it needs to start ASAP.
Additional maps are needed as, even with linux keycodes, PC keymaps
won't be ok for a lot of international Mac ke
Since there appears to be no objections to moving away from the
deprecated adb keycodes over to linux keycodes I have been thinking
about a way to make the transition as painless as possible.
Problems:
1) the kernel needs to be reconfigured with CONFIG_MAC_ADBKEYCODES=n
this will require that
>As far as I can tell, this problem could only be solved by continuing to
>provide separate keymaps for Intel and Mac, at least for non-US
>keyboards.
Yes, it's necessary to ship both four countires where the layout differ.
Note that Linux keycodes are still a good thing for othe
On Monday, June 11, 2001, at 04:29 PM, Michel Lanners wrote:
At one point, there was an inversion of some mode shift keys in some
keymaps (my memory is fuzzy...).
Have you tried all the different mode keys?
Basically, on the PB there are only Opt and Cmd available. I have not
experimented a
Ethan Benson <[EMAIL PROTECTED]> wrote:
> I am wondering if there is any reason we should not switch woody to
> use linux keycodes by default and finally abandon the adb keycodes?
If this means that on my German keyboard I have to type special
characters such as { } [ ] \ | etc wi
On 10 Jun, this message from [EMAIL PROTECTED] echoed through cyberspace:
> Thanks, I checked the qwertz/mac-de-latin1.kmap and
> de-latin1-nodeadkeys.kmap,
> and was unable to produce any of the special (modeshift) characters with
> them.
> As mentioned in the other thread Re: special sybols
I consider it still an issue.
> > OTOH, I am not sure that even the existing ADB keymaps have a 100% correct
> > layout (I am mostly using my own ones), so if that work is to be done
> > anyway, it would surely make most sense to do it for the Linux keycodes
> > righ
On Thu, 7 Jun 2001, Geert Uytterhoeven wrote:
> On Thu, 7 Jun 2001, Michael Schmitz wrote:
> > > > I am all for this - APUS not having Linux keycodes yet is not an issue,
> > > > it
> > > > will keep Amiga keycodes, right?
> > >
> > >
these in mind, I suggest that you go ahead with this change.
> (And maybe figure out what's wrong with xkb?)
theres one vote in favor
>
> Adam
>
>
> On Tue, Jun 05, 2001 at 03:04:27PM -0800, Ethan Benson wrote:
> >
> > Hi,
> >
> > I am wonderin
testing, and am using linux keycodes.
In order to get my arrow keys working correctly, and be able to use the
command key as meta in emacs, I wound up creating the following .Xmodmap =
keycode 104 = KP_Enter
keycode 111 = Up
keycode 116 = Down
keycode 113 = Left
keycode 114 = Right
clear mod1
7;t find that information.
This fixes X for me, although xkeycaps still reports the wrong raw keycodes.
And yes, the linux console works perfectly, keycode for keycode the same
as my Pentium II laptop. So odd...
Adam
>
> Note the arrows and such seem to work fine in console with linux ke
> Hi,
>
> I am wondering if there is any reason we should not switch woody to
> use linux keycodes by default and finally abandon the adb keycodes?
>
> AFAICT all that needs to be changed is dbootstrap to use i386 keymaps
> on macs, the kernel-images to turn off CONFIG_MAC_A
1 - 100 of 113 matches
Mail list logo
