XF4, SysRq, VT, mouse buttons, Keymaps and all that

XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Iain Sandoe]

Thanks to those who gave help in getting XF4 (basically) going.

I haven't been able to try Ani's patch yet - the xfree86.org cvs server
pings - but no response yet today to cvs login :-(

ati (mach64): (G3/beige, 2.4.4-pre3)

a kludge of putting the 4.0.99.1-0f libfbdevhw.a library into the latest
code gives me ati accel.  Thanks Kaoru & Scott. (Will try Ani's proper fix
as soon as I can co the XFree86 tree).

Michel's advice to "option XkbDisable" gives partial functionality (VT
switches, server re-start).... but... with no mouse button emulation or
SysRq. (haven't tried MoL yet).

===

I may be going blind - but I can't see _any_ locale-specific mac keycode
tables in the X11R6 tree...

So the next question set is...

1/ Is there a description anywhere of the flow of keycode translation
   adb -> linux_keycodes -> X  (there isn't in linux/Documentation AFAICT).
Especially:
    where to look for the tables to edit at each stage - and
    what exists to examine the codes.

2/ the (ISO Mac Keyboard) SysRq key is no longer a single value (according
to showkey it sends two codes) but this needs to be caught earlier on (in
the kernel) - so is this supposed to be before or after the translation
adb->linux_keycodes? ... or how can I find the value to modify the match
code in the kernel?  AFAICT SysRq is not working.

3/ how does one find the keycode values for <option>-key combinations so
that the mouse_button2 & 3 keycodes can be re-assigned (it is really
irritating losing them)...  [the kernel build has this emulation enabled]

4/ Notwithstanding the PMac-specific nature of some of these questions - Is
there a HOW-to on creating a keymap (I'm happy to do one for the UK keyboard
if someone can point at the mechanism).

5/ num-lock never worked for me (even under 3.3.6 - it put the keyboard
light on but made no difference to the retured codes) I'd like to get this
fixed because some apps (like cdp) use the keypad.

any pointers appreciated and thanks again for the help so far,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Michel Dänzer]

Iain Sandoe wrote:

> I haven't been able to try Ani's patch yet - the xfree86.org cvs server
> pings - but no response yet today to cvs login :-(

Yup, seems to be down again. :( Can you try the other methods or a mirror?


> ati (mach64): (G3/beige, 2.4.4-pre3)
>
> a kludge of putting the 4.0.99.1-0f libfbdevhw.a library into the latest
> code gives me ati accel.

The only changes between 4.0.99.1 and .2 there are an added function and two
cast changes from unsigned int to unsigned long, so I suspect the version that
works for you has been patched. I'd be interested to see those patches and
possibly include them for the 4.1.0 release.


> Michel's advice to "option XkbDisable" gives partial functionality (VT
> switches, server re-start).... but... with no mouse button emulation or
> SysRq. (haven't tried MoL yet).

The latter two aren't X but kernel issues.


--
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Martin Costabel]

Iain Sandoe wrote:
[]
> I may be going blind - but I can't see _any_ locale-specific mac keycode
> tables in the X11R6 tree...

Two (not helpful) answers: 1. The linux-keycodes stuff was supposed to
let Mac users use localised PC keymaps. A pious wish that didn't work.
For French Mac keyboards there is a XF4 (+console) keymap at
linux-france.fr in RPM form. I don't know about others, but 2. SuSE-ppc
is reported to contain working localised keymaps, but I haven't seen
them with my own eyes.

> So the next question set is...
>
> 1/ Is there a description anywhere of the flow of keycode translation
>    adb -> linux_keycodes -> X  (there isn't in linux/Documentation AFAICT).
> Especially:
>     where to look for the tables to edit at each stage - and
>     what exists to examine the codes.

I strongly suspect that the last guy who tried such a documentation had
to be put away into a safe institution :-) As for the tables to edit,
there is not much choice. For the console, everything is contained in
/usr/lib/kbd, and for X, in /usr/X11R6/lib/X11/xkb. After staring at
what's there for a while, you see some sort of logic at work that can be
used for modifications. All this, of course, is the layer above the
kernel keymaps that translate things several times back and forth before
userspace gets to see them. Except for the SysRq key, you probably don't
want to touch the latter.

> 2/ the (ISO Mac Keyboard) SysRq key is no longer a single value (according
> to showkey it sends two codes) but this needs to be caught earlier on (in
> the kernel) - so is this supposed to be before or after the translation
> adb->linux_keycodes? ... or how can I find the value to modify the match
> code in the kernel?  AFAICT SysRq is not working.

Can't help there, NoSuchKey(TM) on my iBook.

> 3/ how does one find the keycode values for <option>-key combinations so
> that the mouse_button2 & 3 keycodes can be re-assigned (it is really
> irritating losing them)...  [the kernel build has this emulation enabled]

The option key doesn't modify the keycode, only (if configured
correctly) the symbol associated with this keycode. The easiest way to
find the keycodes to put into the /proc/...*button*emulate slots is to
look them up in include/input.h in the kernel sources. This is the
console keycode, i.e. what you get from showkey. For most keys, it is
the X keycode (i.e. what you get from xev) minus 8. Used to be *all*
keys, but this is no longer so.

> 4/ Notwithstanding the PMac-specific nature of some of these questions - Is
> there a HOW-to on creating a keymap (I'm happy to do one for the UK keyboard
> if someone can point at the mechanism).

In XFree, there are always about 25 (conservative estimate) different
ways to achieve the same goal, so such a HOWTO would require some
lengthy explanations :-)
OTOH, you probably installed a dozen megabytes worth of XFree-doc, so
there might be something hidden in there for example
/usr/doc/XFree86-doc-4.0.99.1/XKB/XKBproto.ps.gz or similar.

> 5/ num-lock never worked for me (even under 3.3.6 - it put the keyboard
> light on but made no difference to the retured codes) I'd like to get this
> fixed because some apps (like cdp) use the keypad.

WorksForMe(TM).

> any pointers appreciated and thanks again for the help so far,
> Iain.

Sorry for not helping much.

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Iain Sandoe]

On Tue, Apr 17, 2001, Michel Dänzer wrote:
> Iain Sandoe wrote:
[..]
>> Michel's advice to "option XkbDisable" gives partial functionality (VT
>> switches, server re-start).... but... with no mouse button emulation or
>> SysRq. (haven't tried MoL yet).
>
> The latter two aren't X but kernel issues.

agreed - so how come installing a new version of X blows them away :-/
(maybe it's a co-incidence...  hmmm... did I try 2.4.4 _before_ I
upgraded... can't remember)...

AH! I know what I changed - I've left off the "Xpmac backward compatibility"
CONFIG option ... should I still use that with XF4 ?

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Michel Dänzer]

Iain Sandoe wrote:
>
> On Tue, Apr 17, 2001, Michel Dänzer wrote:
> > Iain Sandoe wrote:
> [..]
> >> Michel's advice to "option XkbDisable" gives partial functionality (VT
> >> switches, server re-start).... but... with no mouse button emulation or
> >> SysRq. (haven't tried MoL yet).
> >
> > The latter two aren't X but kernel issues.
>
> agreed - so how come installing a new version of X blows them away :-/
> (maybe it's a co-incidence...  hmmm... did I try 2.4.4 _before_ I
> upgraded... can't remember)...
>
> AH! I know what I changed - I've left off the "Xpmac backward compatibility"
> CONFIG option ... should I still use that with XF4 ?

Don't think so. The thing is XF4 doesn't do mouse button emulation, the kernel
does that. For SysRq I suspect that has to do with Linux keycodes?


--
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Iain Sandoe]

 Michel Dänzer wrote:
> Iain Sandoe wrote:
>> On Tue, Apr 17, 2001, Michel Dänzer wrote:
>> > Iain Sandoe wrote:
>> [..]
>> >> Michel's advice to "option XkbDisable" gives partial functionality (VT
>> >> switches, server re-start).... but... with no mouse button emulation or
>> >> SysRq. (haven't tried MoL yet).
>> >
>> > The latter two aren't X but kernel issues.
>>
>> agreed - so how come installing a new version of X blows them away :-/
>> (maybe it's a co-incidence...  hmmm... did I try 2.4.4 _before_ I
>> upgraded... can't remember)...
>>
>> AH! I know what I changed - I've left off the "Xpmac backward compatibility"
>> CONFIG option ... should I still use that with XF4 ?
>
> Don't think so. The thing is XF4 doesn't do mouse button emulation, the kernel
> does that.

Yep.  But maybe it puts the emulated button presses on different keys
with/without backward compat.  I'll have a look in a minute.

The frustration is that the keycodes are listed in
/proc/sys/dev/mac_hid/mouse_buttonX_keycode - but finding out which physical
key combination relates to the numbers doesn't appear to be trivial.

>For SysRq I suspect that has to do with Linux keycodes?

Not soley/directly - I've had linux keycodes enabled (and the new input
layer) for months... (including in 2.2.x back-ported version in Ben's old
tree).

I know I'm asking dumb questions... but it's gradually beginning to make
some sense..
thanks,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Tony Mantler]

At 7:28 PM -0500 4/17/2001, Iain Sandoe wrote:
[...]
>The frustration is that the keycodes are listed in
>/proc/sys/dev/mac_hid/mouse_buttonX_keycode - but finding out which physical
>key combination relates to the numbers doesn't appear to be trivial.

I think if you enable linux keycodes on the console, then use showkeys, you
can get the proper values to plug into those files.

Bit of a PITA, but at least they'll (hopefully) always be consistant.


Cheers - Tony 'Nicoya' Mantler :)


--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Steven Hanley]

On Wed, Apr 18, 2001 at 01:28:52AM +0100, Iain Sandoe wrote:
> The frustration is that the keycodes are listed in
> /proc/sys/dev/mac_hid/mouse_buttonX_keycode - but finding out which physical
> key combination relates to the numbers doesn't appear to be trivial.

AFAIU the numbers there are identical to those in
/usr/src/linux/include/linux/input.h even when you have adb keycodes theya
re still the linux keycode numbers.

if you have the linux keycodes enabled using showkey in console will give
you the keycode for a key corresponding to what is in that header file.

	See You
	    Steve

--
sjh@wibble.net http://wibble.net/~sjh/
Look Up In The Sky
   Is it a bird?  No
      Is it a plane?  No
         Is it a small blue banana?
YES

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Iain Sandoe]

On  Wed, Apr 18, 2001, Tony Mantler wrote:
> At 7:28 PM -0500 4/17/2001, Iain Sandoe wrote:
> [...]
>>The frustration is that the keycodes are listed in
>>/proc/sys/dev/mac_hid/mouse_buttonX_keycode - but finding out which physical
>>key combination relates to the numbers doesn't appear to be trivial.
>
> I think if you enable linux keycodes on the console, then use showkeys, you
> can get the proper values to plug into those files.
>
> Bit of a PITA, but at least they'll (hopefully) always be consistant.

Well, I looked at the source and the mouse button emulation is OK (on
right-ctl, alt).  Don't quite understand when/how it moved from <alt-2,
alt-3> ;-)

====

The SysRq situation is more difficult to understand - but the code is very
readable (nice stuff from Franz) - I just need to draw myself a picture
(gave up at 3am this morning).

How about a revolution  ;-?

Could we come to a consensus about a key to use that will work for both
Laptops & desktops?

How about <Power> ?  It seems to send keycode 0x7f (or 0x7e on 3400)...

ciao,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Martin Costabel]

> The SysRq situation is more difficult to understand - but the code is very
> readable (nice stuff from Franz) - I just need to draw myself a picture
> (gave up at 3am this morning).
>
> How about a revolution  ;-?
>
> Could we come to a consensus about a key to use that will work for both
> Laptops & desktops?
>
> How about <Power> ?  It seems to send keycode 0x7f (or 0x7e on 3400)...

Very good idea. Except that it is already hijacked by xmon, IIUC. Maybe
one could make the use of SysRq and of xmon mutually exclusive :-)

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Iain Sandoe]

On  Wed, Apr 18, 2001,  Martin Costabel wrote:
>> The SysRq situation is more difficult to understand - but the code is very
>> readable (nice stuff from Franz) - I just need to draw myself a picture
>> (gave up at 3am this morning).
>>
>> How about a revolution  ;-?
>>
>> Could we come to a consensus about a key to use that will work for both
>> Laptops & desktops?
>>
>> How about <Power> ?  It seems to send keycode 0x7f (or 0x7e on 3400)...
>
> Very good idea. Except that it is already hijacked by xmon, IIUC. Maybe
> one could make the use of SysRq and of xmon mutually exclusive :-)

xmon uses <CMD aka pretzel>-power which causes an NMI - this is a hardware
thing AFAIK and can't be altered.

What I'm suggesting is <power> as a modifier (which is basically what SysRq
is)  so SysRq sequences would be like:

<power>-k  (SAK) ;  <power>-s (emergency sync). etc. etc.

<power> has the right "feel" to it (i.e. "don't touch unless you know what
you're doing").

I don't think it should interfere with the use of <CMD>-power for xmon
interrupt - MacOS manages to use it for NMI for MacsBug and <power> for
triggering a shutdown dialogue...

Although, I suppose from a User's POV - we might want (one day) to trigger a
shutdown dialogue as well ... ho hum... although a well-designed dialogue
could include the SysRq actions (which are emergency stuff) as options.

I guess we could use <CNTL>-power as the SysRq modifier - but it starts to
become a little unwieldy - because you need to hold down three keys to get
the SysRq action (well, you do now as it happens)...

so, perhaps, <CNTL>-<Power>-k etc.

thoughts?

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Michel Dänzer]

Iain Sandoe wrote:

> I guess we could use <CNTL>-power as the SysRq modifier - but it starts to
> become a little unwieldy - because you need to hold down three keys to get
> the SysRq action (well, you do now as it happens)...
>
> so, perhaps, <CNTL>-<Power>-k etc.

I'd like to propose something like this as well. It's also three keys on i386.


--
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Tony Mantler]

At 7:03 AM -0500 4/18/2001, Iain Sandoe wrote:
[...]
>I guess we could use <CNTL>-power as the SysRq modifier - but it starts to
>become a little unwieldy - because you need to hold down three keys to get
>the SysRq action (well, you do now as it happens)...
>
>so, perhaps, <CNTL>-<Power>-k etc.
>
>thoughts?

On my Apple Adjustable keyboard, control and power are about as far away
from eachother as you can get and still be on the same keyboard. Not
exactly 2-of-3-key-combo material. I don't have very small hands, but even
on my AppleDesign, it's a bit of a stretch.

Also, what happens if someone wants to hook up a PC USB keyboard to their
mac? Obviously not generating an NMI is a given, but no access to SAK is
avoidable. (Also can't forget non-mac PPCs)


Cheers - Tony 'Nicoya' Mantler :)


--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Iain Sandoe]

>>I guess we could use <CNTL>-power as the SysRq modifier - but it starts to
>>become a little unwieldy - because you need to hold down three keys to get
>>the SysRq action (well, you do now as it happens)...
>>
>>so, perhaps, <CNTL>-<Power>-k etc.
>>
>>thoughts?
>
> On my Apple Adjustable keyboard, control and power are about as far away
> from eachother as you can get and still be on the same keyboard. Not
> exactly 2-of-3-key-combo material. I don't have very small hands, but even
> on my AppleDesign, it's a bit of a stretch.

yeah, on mine too - which is why I was originally attracted to just <power>
as the modifier.

> Also, what happens if someone wants to hook up a PC USB keyboard to their
> mac? Obviously not generating an NMI is a given, but no access to SAK is
> avoidable.

Apparently, some Apple keyboards don't have a <power> key either.

Anyway the SysRq key for USB must be handled somewhere else - I'm looking at
the mac_hid/adb/mac_keyb code which is specific to adb-based machines IIUC.

>(Also can't forget non-mac PPCs)

Which must handle it in their hid section... depending on whether they have
serial or USB (or something special).

Ben just mailed me a much better suggestion:

"Pass the SysRq combination in as a kernel argument".

This would allow those with SysRQ keys (e.g. ISO/ANSI kbds) to use it, power
books could have something that actually exists etc. etc.

It would also mean that users could be supported with a "HOW-to" instead of
"look at the code & rebuild the kernel"...

A bit more wide-reaching than just changing a value somewhere - but probably
worth it - since this discussion comes up every few months ;-)

I'll have a (wider) look at what's needed later on...
ciao,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Tony Mantler]

At 7:44 AM -0500 4/18/2001, Iain Sandoe wrote:
[...]
>> Also, what happens if someone wants to hook up a PC USB keyboard to their
>> mac? Obviously not generating an NMI is a given, but no access to SAK is
>> avoidable.
>
>Apparently, some Apple keyboards don't have a <power> key either.

The Happy-Hacking ADB keyboard for one (just looked at the web page, was
the first that came to mind).

I'm not sure about apple designed keyboards besides those on the Mac+ and
like machines (non-adb). All the ones I've seen - FrogDesign/IIGS, Apple
Extended II, AppleDesign, Apple Adjustable, etc - have it. I haven't seen
an Apple Extended I or a non-extended (was there one?) for years, so I
can't say about those ones.


>Anyway the SysRq key for USB must be handled somewhere else - I'm looking at
>the mac_hid/adb/mac_keyb code which is specific to adb-based machines IIUC.

Ah, ok. Wasn't sure about that.


[...]
>Ben just mailed me a much better suggestion:
>
>"Pass the SysRq combination in as a kernel argument".
>
>This would allow those with SysRQ keys (e.g. ISO/ANSI kbds) to use it, power
>books could have something that actually exists etc. etc.
[...]

Very nice idea.

...hopefully defaulted to the standard Alt-f13/printscreen/sysrq-key in the
absense of the kernel commandline.


Cheers - Tony 'Nicoya' Mantler :)


--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Gabriel Paubert]

On Wed, 18 Apr 2001, Iain Sandoe wrote:

>
> >>I guess we could use <CNTL>-power as the SysRq modifier - but it starts to
> >>become a little unwieldy - because you need to hold down three keys to get
> >>the SysRq action (well, you do now as it happens)...
> >>
> >>so, perhaps, <CNTL>-<Power>-k etc.
> >>
> >>thoughts?
> >
> > On my Apple Adjustable keyboard, control and power are about as far away
> > from eachother as you can get and still be on the same keyboard. Not
> > exactly 2-of-3-key-combo material. I don't have very small hands, but even
> > on my AppleDesign, it's a bit of a stretch.
>
> yeah, on mine too - which is why I was originally attracted to just <power>
> as the modifier.
>
> > Also, what happens if someone wants to hook up a PC USB keyboard to their
> > mac? Obviously not generating an NMI is a given, but no access to SAK is
> > avoidable.
>
> Apparently, some Apple keyboards don't have a <power> key either.

Unless I missed it there is no power key on the keyboard delivered with my
2001 G4/466 (109 keys including volume/mute/media-eject, but nothing
looking like a power key.)

> Anyway the SysRq key for USB must be handled somewhere else - I'm looking at
> the mac_hid/adb/mac_keyb code which is specific to adb-based machines IIUC.
>
> >(Also can't forget non-mac PPCs)
>
> Which must handle it in their hid section... depending on whether they have
> serial or USB (or something special).

If somebocy is going to touch the input layer, I would like the raw
keyboard mode to stay raw. Right now in some configuration combinations
there is no difference between raw and medium-raw (used by X). They both
return medium-raw keycodes, I can't get to the scancodes.

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Franz Sirl]

At 15:39 18.04.2001, Gabriel Paubert wrote:
>If somebocy is going to touch the input layer, I would like the raw
>keyboard mode to stay raw. Right now in some configuration combinations
>there is no difference between raw and medium-raw (used by X). They both
>return medium-raw keycodes, I can't get to the scancodes.

Which config combinations? Which keys? PMAC, CHRP or PREP? ADB, USB or PS2
keyboard?

Additionally note that XF 4.0.99 and later only will use MEDIUMRAW if you
give "Option CustomKeycodes".

God, I'll be *really* glad when the 2.5 kernel is started and support for
ADB keycodes, the MEDIUMRAW mode and mouse button emulation in the kernel
will be gone forever...

Franz.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Gabriel Paubert]

On Wed, 18 Apr 2001, Franz Sirl wrote:

> At 15:39 18.04.2001, Gabriel Paubert wrote:
> >If somebocy is going to touch the input layer, I would like the raw
> >keyboard mode to stay raw. Right now in some configuration combinations
> >there is no difference between raw and medium-raw (used by X). They both
> >return medium-raw keycodes, I can't get to the scancodes.
>
> Which config combinations? Which keys? PMAC, CHRP or PREP? ADB, USB or PS2
> keyboard?

Can't test for one week (I'm at the telescope until next Tuesday). But
this affected basically all the keys on a PMAC G4 with standard (latest)
Apple USB keyboard.

AFAIR compiling with CONFIG_ADB off butchered everything: CONFIG_MAC_HID
was Y in .config but there was no mac_hid in /proc/sys/dev and the
keyboard was crazy.

> Additionally note that XF 4.0.99 and later only will use MEDIUMRAW if you
> give "Option CustomKeycodes".

Didn't know, so X is going to use raw ?

But now raw means cooked ?

>
> God, I'll be *really* glad when the 2.5 kernel is started and support for
> ADB keycodes, the MEDIUMRAW mode and mouse button emulation in the kernel
> will be gone forever...

Fine for most of these, but how do you get to the raw scancodes if you
want them ? I mean raw byte for byte from the hardware, anything else
cannot be called raw in my opinion.

Do we need a new mode for this (crude?) or did I miss the way to get at
the scancodes ?

	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Iain Sandoe]

>>Anyway the SysRq key for USB must be handled somewhere else - I'm looking at
>>the mac_hid/adb/mac_keyb code which is specific to adb-based machines IIUC.
>
> Ah, ok. Wasn't sure about that.

duh... neither am I ;-) ... but I'll check later.

>
> [...]
>>Ben just mailed me a much better suggestion:
>>
>>"Pass the SysRq combination in as a kernel argument".
>>
>>This would allow those with SysRQ keys (e.g. ISO/ANSI kbds) to use it, power
>>books could have something that actually exists etc. etc.
> [...]
>
> Very nice idea.
>
> ...hopefully defaulted to the standard Alt-f13/printscreen/sysrq-key in the
> absense of the kernel commandline.

what about defaulting to <cntl>-<power> if CONFIG_POWERBOOK is set on the
kernel build?
- the power key is not too far from cntl on newer PowerBook keyboards -
anyone know about older ones?
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Tony Mantler]

At 8:16 AM -0500 4/18/2001, Iain Sandoe wrote:
[...]
>>>"Pass the SysRq combination in as a kernel argument".
>>>
>>>This would allow those with SysRQ keys (e.g. ISO/ANSI kbds) to use it, power
>>>books could have something that actually exists etc. etc.
>> [...]
>>
>> Very nice idea.
>>
>> ...hopefully defaulted to the standard Alt-f13/printscreen/sysrq-key in the
>> absense of the kernel commandline.
>
>what about defaulting to <cntl>-<power> if CONFIG_POWERBOOK is set on the
>kernel build?
>- the power key is not too far from cntl on newer PowerBook keyboards -
>anyone know about older ones?

Maybe just make the default a seperate compile-time option, rather than
CONFIG_POWERBOOK. It wouldn't be very clear to someone why sysrq stopped
working on their desktop when they purposely or accidentally compiled a new
kernel with pbook support turned on. :)


Cheers - Tony 'Nicoya' Mantler :)


--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Michel Dänzer]

Iain Sandoe wrote:

> >>Ben just mailed me a much better suggestion:
> >>
> >>"Pass the SysRq combination in as a kernel argument".
> >>
> >>This would allow those with SysRQ keys (e.g. ISO/ANSI kbds) to use it,
> >>power books could have something that actually exists etc. etc.
> > [...]
> >
> > Very nice idea.
> >
> > ...hopefully defaulted to the standard Alt-f13/printscreen/sysrq-key in
> > the absense of the kernel commandline.
>
> what about defaulting to <cntl>-<power> if CONFIG_POWERBOOK is set on the
> kernel build?
> - the power key is not too far from cntl on newer PowerBook keyboards -
> anyone know about older ones?

Shouldn't really matter as ctrl is close to the keys used for Sysrq. ;)


--
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Iain Sandoe]

Hi Franz,

copied to the list - since I think I've resolved the issues now ;-)

Franz wrote:
>I wrote:
>> I've figured out the mouse key emulation, and VT switches (by using Option
>> XkbDisable) - but I can't figure out where SysRq has ended up... and anyway
>> the idea was to see if there's a way of dealing with it so that Laptops can
>> use it too...
>
> Well, just try to setup your configuration files correctly. See the excerpt
> from my XF86Config-4 below. VT switches happen with alt(option)-ctrl-Fx if
> configured correctly.

OK.  What's happened is that the VT combination has shifted from
<CMD>-<CNTL>-Fx to <ALT>-<CNTL>-Fx ... all OK now.  (the config was correct)

[...]

>> For use of >4.0.99.x should I have CONFIG_ADB_KEYCODE disabled?
>
> For maximum compatibility options to be active you need:
>
> CONFIG_INPUT_ADBHID=y
> CONFIG_MAC_ADBKEYCODES=y
> CONFIG_MAC_EMUMOUSEBTN=y

This is what I've had (or the equivalent) since the input layer back-port to
2.2.x...

and Option "XkbModel" "macintosh"

> This will give you all the /proc entries.

yep. it does.

>> the SysRq needs to be quite low-level to be a fairly guaranteed way of
>> doing 'emergency' syncs and so on ... I'm assuming it's done individually
>> for each of the possible hid input sources.
>
> But is it enabled at all? Check /proc/sys/kernel/sysrq.

OK.  It isn't by default (which was catching me out)

Shouldn't it be enabled by default if the kernel is built CONFIG_SYSRQ?

Additionally, like VT-switching, the modifier key appears to have changed to
<ALT> from <CMD>...

SysRq doesn't appear to have _exactly_ the same behaviour as before (but
this may be a consequence of the change of Xserver - no longer using
fbdevhw).

The SysRq messages no longer break through onto the screen (I did get them
on VT-1 at one point - but couldn't reproduce it).

- and once you've got into SysRq mode it appears to be 'sticky' - i.e.
commands accepted with a single keypress until you do SysRq again.  Hmmm.
It might have been like that before - and I never noticed - because I always
did three-key-presses.

----

The issue of a "GoodWay" (tm) to support Laptops with SysRq remains - I'd
like to be able to use it on my Lombard...

====

So, now the correct place to make changes to get the right symbols out for
~/` ±/§ and so on is in  /usr/X11R6/..../xkb/symbols/gb - I assume.

====

I guess that I must have missed a place to look for the changes that
occurred to the modifier keys etc.... perhaps Kaoru should add this
information to his ftp directory.  If people who monitor the -dev list don't
know, what chance have Users got ;-?

====

anyway, thanks for the help - I'm now the proud owner of a nicely
accelerated, non-flickering, ati mach64 XF4 installation.... *and* know
which keys to press ;-))

next time I have some time - I'll do the Lombard & the 9600 (imstt could be
amusing)...

BTW: It runs MoL (almost fine) too.

ciao,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Martin Costabel]

Iain Sandoe wrote:
[]
> OK.  What's happened is that the VT combination has shifted from
> <CMD>-<CNTL>-Fx to <ALT>-<CNTL>-Fx ... all OK now.  (the config was correct)
[]
> Additionally, like VT-switching, the modifier key appears to have changed to
> <ALT> from <CMD>...
[]
> I guess that I must have missed a place to look for the changes that
> occurred to the modifier keys etc.... perhaps Kaoru should add this
> information to his ftp directory.  If people who monitor the -dev list don't
> know, what chance have Users got ;-?

The inversion of Alt and Cmd is actually mentioned in one if the
LinuxPPC2000Q4 Readme files.
And it is one of the first things I am always changing back in the
keymaps. There is really no sane reason for it, and you *have* to undo
it if you want a modifier key to get non-US characters on a US keyboard
or an Apple-like keyboard layout on a non-US keyboard.

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Franz Sirl]

At 21:32 19.04.2001, Martin Costabel wrote:
>Iain Sandoe wrote:
>[]
> > OK.  What's happened is that the VT combination has shifted from
> > <CMD>-<CNTL>-Fx to <ALT>-<CNTL>-Fx ... all OK now.  (the config was
> correct)
>[]
> > Additionally, like VT-switching, the modifier key appears to have
> changed to
> > <ALT> from <CMD>...
>[]
> > I guess that I must have missed a place to look for the changes that
> > occurred to the modifier keys etc.... perhaps Kaoru should add this
> > information to his ftp directory.  If people who monitor the -dev list
> don't
> > know, what chance have Users got ;-?
>
>The inversion of Alt and Cmd is actually mentioned in one if the
>LinuxPPC2000Q4 Readme files.
>And it is one of the first things I am always changing back in the
>keymaps. There is really no sane reason for it, and you *have* to undo
>it if you want a modifier key to get non-US characters on a US keyboard
>or an Apple-like keyboard layout on a non-US keyboard.

Please stop this keyboard layout bashing! I'm a getting bored by your wrong
patches on the lists. You can blame Apple for labeling the OPT key with
ALT, but that's it. Every linux doc talks about using ALT-CTRL-Fx for VT
switching and that's how it works now.

If you want to have it different, create a "XkbVariant SwitchOptCmd",
"XkbVariant Powerbook" etc. and _submit_ it to the XFree86 project.

If you are too lazy to fix it correctly, that's ok, but keep your hacks
private and stay off the lists with wrong patches (that will break on every
upgrade) that just confuse people.

Franz.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Martin Costabel]

Franz Sirl wrote:

> Please stop this keyboard layout bashing! I'm a getting bored by your wrong
> patches on the lists.

Ouch. I guess I asked for this, having used some strong language myself.
If I have offended you, I am sorry.

But I am not quite sure what "patches" you are talking about. The only
keyboard-related things I remember having sent to the linuxppc lists in
the last couple of months were two tiny keymaps for the console and XF4,
respectively, that adapt the US keyboard on my iBook to my taste, and a
more or less complete XF4 keymap for French Macintosh keyboards that was
the first of its kind, AFAICT. I would not consider these as "patches",
but as legitimate user modifications of configuration files. I think I
even have occasionally tried to discourage people from patching the
Linux kernel or the XFree86 sources just for small modifications of the
keyboard layout. And I never sent these things out to preach to the
masses, but only to users that were, like me earlier, in a situation
where things just did not work.

What you can blame me for is having been too tired this week to pay
attention to which list I was answering. I shouldn't have written to the
dev list. But when even seasoned developers seem to have the same
keyboard problems as newbies... :-)

>                        You can blame Apple for labeling the OPT key with
> ALT, but that's it. Every linux doc talks about using ALT-CTRL-Fx for VT
> switching and that's how it works now.

Beyond questions of style and personal taste(*), I think there remains a
real problem. I am talking about the 2 keys labelled alt/option and
<Apple>/<Cloverleaf> on my iBook keyboard, using recent kernels and XF4.
Please correct me if I am wrong here, but I think the situation is as
follows:

The 2 keys produce in X the keycodes 64 and 115, respectively, and with
the standard macintosh/us symbols file, this results in the keysyms
"Alt_L" and "NoSymbol". The latter one is not very useful. There are a
couple of variants on this in the PC style symbol file collection, but
in NONE of the keymaps that come with XFree86 (in kfukui's excellent
precompiled version), is either one of these keys mapped to the keysym
"Mode_switch" that seems to be necessary in order to produce more than 2
symbols per key. The problem is that Apple keyboards don't have an AltGr
key that is used for this purpose on PC keyboards. Apple keyboards
traditionally use the alt key for this same purpose.

In the console, the situation is similar. The keycodes are 56 and 125,
and they are mapped to Alt and Decr_Console, respectively. This gives me
the possibility to switch consoles in two ways, either by pressing
alt-Fx or by repeatedly hitting the Apple key, but I don't get an AltGr
key.

> If you want to have it different, create a "XkbVariant SwitchOptCmd",
> "XkbVariant Powerbook" etc. and _submit_ it to the XFree86 project.

I am sorry, but I don't have enough time (or call me lazy if you prefer)
to lift myself to the level I consider necessary to act as an XFree
developer. I will remain on the level of a user who struggles to get
things working so that he can use them for his daily work.

> If you are too lazy to fix it correctly, that's ok, but keep your hacks
> private and stay off the lists with wrong patches (that will break on every
> upgrade) that just confuse people.

Time permitting, I think I shall continue to offer help to fellow Linux
users. From the feedback I got so far, I do not get the impression that
I confused anyone who wasn't much more confused before. I made it always
clear that these were just "my private hacks". And I just upgraded a few
minutes ago to XFree86-4.0.99.3-0a (thanks Kaoru!) without any problem
and without breaking my "patches", thank you.

--
Martin

(*) I don't care which key is used to switch consoles, but there is a
question of taste or style here: I prefer consistency of keyboard use
betweeen my Mac under Linux and the same Mac under MacOS. You seem to
prefer consistency with other Linux boxes with PC keyboards. As an
example, in Netscape, I like to be able to use Apple-x/c/v for
cut/copy/paste or Apple-q/w for quit/close, under both Linux and MacOS
(Mozilla adopted the Microsoft Ctrl-x/c/v/q/w, unfortunately). Likewise,
I like to have alt-shift-L for the pipe symbol on a French Mac keyboard
under both Linux and MacOS. This used to be the standard until very
recently. If this is no longer the default now, then I think I have the
right to apply some simple modifications to the keymaps in order to keep
my preferred behavior. And I think I have the right to explain to others
what I did.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4, SysRq, VT, mouse buttons, Keymaps and all that

[Michel Dänzer]

Martin Costabel wrote:

> > If you want to have it different, create a "XkbVariant SwitchOptCmd",
> > "XkbVariant Powerbook" etc. and _submit_ it to the XFree86 project.
>
> I am sorry, but I don't have enough time (or call me lazy if you prefer)
> to lift myself to the level I consider necessary to act as an XFree
> developer. I will remain on the level of a user who struggles to get
> things working so that he can use them for his daily work.

You don't need to be a developer to submit patches. fixes@xfree86.org is the
patch submission address for non-members.


--
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/