newer xfree86 4.0.1 patches

newer xfree86 4.0.1 patches

[Olaf Hering]

Hi,

you can find a newer ajoshi patch against xf4.0.1 at www.penguinppc.org/~olaf/

It contains a driver for Matrox cards, the B50 works fine now. Ken Aaker
from IBM did the work.

There is also a keycode file for ps/2 based machines like PReP and CHRP,
called "powerpcps2". It is a workaround, the arrow keys and the page
up/down block are dead as example. I guess it is a kernel bug.

Please let me know if the international maps work for you. I created
some maps in symbols/macintosh/*.

The (xf4) keyboard section might look like that:

Section "InputDevice"
  Driver        "keyboard"
  Identifier    "Keyboard[0]"
  Option        "Protocol"      "Standard"
  Option        "XkbLayout"     "de"
#  Option        "XkbVariant"    "nodeadkeys"
  Option        "XkbModel"      "macintosh"
  Option        "XkbRules"      "xfree86"
EndSection

Replace the "macintosh" with "powerpcps2" when you have a ps/2 keyboard.
Be sure to disable the Xmodmap stuff in ~/.Xmodmap and
/usr/X11R6/lib/X11/Xmodmap.


Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...

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

Re: newer xfree86 4.0.1 patches

[Geert Uytterhoeven]

On Wed, 6 Sep 2000, Olaf Hering wrote:
> There is also a keycode file for ps/2 based machines like PReP and CHRP,
> called "powerpcps2". It is a workaround, the arrow keys and the page
> up/down block are dead as example. I guess it is a kernel bug.

So prefixed scancodes don't work? Sounds familiar. I guess this has something
to do with the X server putting the keyboard in RAW mode (send raw scancodes,
including prefixes) instead of MEDIUMRAW mode (send keycodes, 1 code for each
key pres/release) or vice versa.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

Re: newer xfree86 4.0.1 patches

[Olaf Hering]

On Thu, Sep 07, Geert Uytterhoeven wrote:

>
> On Wed, 6 Sep 2000, Olaf Hering wrote:
> > There is also a keycode file for ps/2 based machines like PReP and CHRP,
> > called "powerpcps2". It is a workaround, the arrow keys and the page
> > up/down block are dead as example. I guess it is a kernel bug.
>
> So prefixed scancodes don't work? Sounds familiar. I guess this has something
> to do with the X server putting the keyboard in RAW mode (send raw scancodes,
> including prefixes) instead of MEDIUMRAW mode (send keycodes, 1 code for each
> key pres/release) or vice versa.

Franz and me tried to find a solution a couple of weeks/months ago. The
codes above 0xe0 and above are not handled properly AFAIK.

Franz, can you remember that?


Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...

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

Re: newer xfree86 4.0.1 patches

[Franz Sirl]

At 11:53 07.09.00, Geert Uytterhoeven wrote:

>On Wed, 6 Sep 2000, Olaf Hering wrote:
> > There is also a keycode file for ps/2 based machines like PReP and CHRP,
> > called "powerpcps2". It is a workaround, the arrow keys and the page
> > up/down block are dead as example. I guess it is a kernel bug.
>
>So prefixed scancodes don't work? Sounds familiar. I guess this has something
>to do with the X server putting the keyboard in RAW mode (send raw scancodes,
>including prefixes) instead of MEDIUMRAW mode (send keycodes, 1 code for each
>key pres/release) or vice versa.

My xf4 work I did for the linux keycodes support fixes that. It's a
configurable option now (well, in 4.0.2 I hope). XkbModel "macintosh_old"
or XkbKeycodes "macintosh" for ADB keycodes/MEDIUMRAW mode, everything else
is Linux keycodes/RAW mode, or, if it can open the sysctl
/proc/sys/dev/mac_hid/keyboard_sends_linux_keycodes, it tries to
autodetect. This will make PReP and CHRP users with PS2 keyboards happy I
hope :-).

On my TODO list, I still have to make chrp_setup.c and prep_setup.c use
machid_init_hw() and friends in machid.c.

Franz.


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

Re: newer xfree86 4.0.1 patches

[Michel Dänzer]

Franz Sirl wrote:

> On my TODO list, I still have to make chrp_setup.c and prep_setup.c use
> machid_init_hw() and friends in machid.c.

While you're at it, can you do apus_setup.c as well please?


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Re: newer xfree86 4.0.1 patches

[Franz Sirl]

At 14:54 07.09.00, Michel Dänzer wrote:

>Franz Sirl wrote:
>
> > On my TODO list, I still have to make chrp_setup.c and prep_setup.c use
> > machid_init_hw() and friends in machid.c.
>
>While you're at it, can you do apus_setup.c as well please?

Sure I can, but APUS doesn't use either ADB or PS2 keyboards, or? I'm not
quite sure about the following:

- does Apus have it's own keycodes? If not, do you currently use ADB or AT
keycodes?
- what's the keycode situation in XF3/4 for Apus?
- if your developer repository for 2.4 is different from BK linuxppc_2_3,
did you integrate your input layer drivers in your trees and plan to submit
them for 2.4?

If you want to keep the current state of affairs I can see in the
linuxppc_2_3 tree, there's not much point in using machid.c, AFAICS. On the
other hand, if you plan to integrate your input drivers into 2.4, it makes
perfect sense.

So, I need a little bit more background information first.

Franz.


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

Re: newer xfree86 4.0.1 patches

[Michel Dänzer]

Franz Sirl wrote:

> > > On my TODO list, I still have to make chrp_setup.c and prep_setup.c use
> > > machid_init_hw() and friends in machid.c.
> >
> >While you're at it, can you do apus_setup.c as well please?
>
> Sure I can, but APUS doesn't use either ADB or PS2 keyboards, or?

No.


> I'm not quite sure about the following:
>
> - does Apus have it's own keycodes?

Yes, I think so. At least we need our own keymaps.

> If not, do you currently use ADB or AT keycodes?
> - what's the keycode situation in XF3/4 for Apus?

AFAIK it isn't very clean with either, the best bet is still to disable Xkb.


> - if your developer repository for 2.4 is different from BK linuxppc_2_3,
> did you integrate your input layer drivers in your trees and plan to submit
> them for 2.4?

We have a CVS repository at SourceForge. Roman Zippel integrates bitkeeper
into it, but unfortunately we don't have anyone for the reverse direction. How
could that be done?


> If you want to keep the current state of affairs I can see in the
> linuxppc_2_3 tree, there's not much point in using machid.c, AFAICS. On the
> other hand, if you plan to integrate your input drivers into 2.4, it makes
> perfect sense.

I think it would be nice, but to be honest I don't fully understand what would
be involved.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Re: newer xfree86 4.0.1 patches

[Geert Uytterhoeven]

On Thu, 7 Sep 2000, Michel [iso-8859-1] Dänzer wrote:
> Franz Sirl wrote:
> > I'm not quite sure about the following:
> >
> > - does Apus have it's own keycodes?
>
> Yes, I think so. At least we need our own keymaps.
>
> > If not, do you currently use ADB or AT keycodes?
> > - what's the keycode situation in XF3/4 for Apus?
>
> AFAIK it isn't very clean with either, the best bet is still to disable Xkb.

And Franz also wrote:
| My xf4 work I did for the linux keycodes support fixes that. It's a
| configurable option now (well, in 4.0.2 I hope). XkbModel "macintosh_old"
| or XkbKeycodes "macintosh" for ADB keycodes/MEDIUMRAW mode, everything else
                                                              ^^^^^^^^^^^^^^^
| is Linux keycodes/RAW mode, or, if it can open the sysctl
  ^^^^^^^^^^^^^^^^^^^^^^^^^^
| /proc/sys/dev/mac_hid/keyboard_sends_linux_keycodes, it tries to
| autodetect. This will make PReP and CHRP users with PS2 keyboards happy I
| hope :-).

APUS uses Amiga keyboards. There are lots of other machines who use their own
keymaps as well. If I only consider Linux/m68k, we have Atari, Sun-3, Apollo,
HP9000/[34]00, ...

I can't speak about XF4, but with XF3 all of these work out-of-the-box if you
disable Xkb (using kernel keycodes). If you enable Xkb, it also works, but
then you need the special X keymaps (for those that are available) (no
surprise).

And I'd say `everything else works fine if you use _MEDIUMRAW_ instead of RAW'.

> > If you want to keep the current state of affairs I can see in the
> > linuxppc_2_3 tree, there's not much point in using machid.c, AFAICS. On the
> > other hand, if you plan to integrate your input drivers into 2.4, it makes
> > perfect sense.
>
> I think it would be nice, but to be honest I don't fully understand what would
> be involved.

I hope this is _not_ about translating whatever-keyboard-type-keycodes to
PC-style keycodes? We (ehrm, I) already opened that can of worms somewhere in
1995, and closed it ASAP.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

Re: newer xfree86 4.0.1 patches

[Michael Schmitz]

> > > If you want to keep the current state of affairs I can see in the
> > > linuxppc_2_3 tree, there's not much point in using machid.c, AFAICS. On the
> > > other hand, if you plan to integrate your input drivers into 2.4, it makes
> > > perfect sense.
> >
> > I think it would be nice, but to be honest I don't fully understand what would
> > be involved.
>
> I hope this is _not_ about translating whatever-keyboard-type-keycodes to
> PC-style keycodes? We (ehrm, I) already opened that can of worms somewhere in
> 1995, and closed it ASAP.

I don't recall the details (and have no list archives that far back) but
it wasn't a bit pretty. But at that time there was no generic HID support
to use, and that might make a difference now (if it works for ADB
keyboards it might work for Amiga as well).

	Michael


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

Re: newer xfree86 4.0.1 patches

[Franz Sirl]

On Thu, 07 Sep 2000, Geert Uytterhoeven wrote:
> On Thu, 7 Sep 2000, Michel [iso-8859-1] Dänzer wrote:
> > Franz Sirl wrote:
> > > I'm not quite sure about the following:
> > >
> > > - does Apus have it's own keycodes?
> >
> > Yes, I think so. At least we need our own keymaps.
> >
> > > If not, do you currently use ADB or AT keycodes?
> > > - what's the keycode situation in XF3/4 for Apus?
> >
> > AFAIK it isn't very clean with either, the best bet is still to disable
> > Xkb.
>
> And Franz also wrote:
> | My xf4 work I did for the linux keycodes support fixes that. It's a
> | configurable option now (well, in 4.0.2 I hope). XkbModel "macintosh_old"
> | or XkbKeycodes "macintosh" for ADB keycodes/MEDIUMRAW mode, everything
> | else
>
>
> ^^^^^^^^^^^^^^^
>
> | is Linux keycodes/RAW mode, or, if it can open the sysctl
>
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> | /proc/sys/dev/mac_hid/keyboard_sends_linux_keycodes, it tries to
> | autodetect. This will make PReP and CHRP users with PS2 keyboards happy I
> | hope :-).
>
> APUS uses Amiga keyboards. There are lots of other machines who use their
> own keymaps as well. If I only consider Linux/m68k, we have Atari, Sun-3,
> Apollo, HP9000/[34]00, ...
>
> I can't speak about XF4, but with XF3 all of these work out-of-the-box if
> you disable Xkb (using kernel keycodes). If you enable Xkb, it also works,
> but then you need the special X keymaps (for those that are available) (no
> surprise).
>
> And I'd say `everything else works fine if you use _MEDIUMRAW_ instead of
> RAW'.

Nope, you need to compile xf3/4 with ASSUME_CUSTOM_KEYCODES undefined _and_
use RAW keyboard mode, otherwise it won't work correctly for some keys and
XKB. Tested that on PC and PMac, cause I wanted to be sure that my xf4 patch
is as short as possible.

> > > If you want to keep the current state of affairs I can see in the
> > > linuxppc_2_3 tree, there's not much point in using machid.c, AFAICS. On
> > > the other hand, if you plan to integrate your input drivers into 2.4,
> > > it makes perfect sense.
> >
> > I think it would be nice, but to be honest I don't fully understand what
> > would be involved.
>
> I hope this is _not_ about translating whatever-keyboard-type-keycodes to
> PC-style keycodes? We (ehrm, I) already opened that can of worms somewhere
> in 1995, and closed it ASAP.

Nope, Linux keycodes are linear keycodes from 0-511 (see
include/linux/input.h for a list), the range 1-127 is mostly PC compatible
though. Unfortunately NR_KEYS will probably not get bumped in 2.4, so
currently I have to map 5 keys back below 128.

Franz.

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

Re: newer xfree86 4.0.1 patches

[Kostas Gewrgiou]

On Thu, 7 Sep 2000, Franz Sirl wrote:

> > I can't speak about XF4, but with XF3 all of these work out-of-the-box if
> > you disable Xkb (using kernel keycodes). If you enable Xkb, it also works,
> > but then you need the special X keymaps (for those that are available) (no
> > surprise).
> >
> > And I'd say `everything else works fine if you use _MEDIUMRAW_ instead of
> > RAW'.
>
> Nope, you need to compile xf3/4 with ASSUME_CUSTOM_KEYCODES undefined _and_
> use RAW keyboard mode, otherwise it won't work correctly for some keys and
> XKB. Tested that on PC and PMac, cause I wanted to be sure that my xf4 patch
> is as short as possible.
>

  What is the problem with MEDIUMRAW in the input layer ? we still can't use
RAW for the old kernels so we will have to stick with MEDIUMRAW.
In your patch you use RAW only when the at keycodes are used so its ok.

PS> There is a discussion in xfree about redesigning the keyboard driver
but don't expect to see any changes in the near future.

 Kostas.


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

Re: newer xfree86 4.0.1 patches

[Franz Sirl]

At 11:57 08.09.00, Kostas Gewrgiou wrote:

>On Thu, 7 Sep 2000, Franz Sirl wrote:
>
> > > I can't speak about XF4, but with XF3 all of these work out-of-the-box if
> > > you disable Xkb (using kernel keycodes). If you enable Xkb, it also
> works,
> > > but then you need the special X keymaps (for those that are
> available) (no
> > > surprise).
> > >
> > > And I'd say `everything else works fine if you use _MEDIUMRAW_ instead of
> > > RAW'.
> >
> > Nope, you need to compile xf3/4 with ASSUME_CUSTOM_KEYCODES undefined _and_
> > use RAW keyboard mode, otherwise it won't work correctly for some keys and
> > XKB. Tested that on PC and PMac, cause I wanted to be sure that my xf4
> patch
> > is as short as possible.
> >
>
>   What is the problem with MEDIUMRAW in the input layer ? we still can't use
>RAW for the old kernels so we will have to stick with MEDIUMRAW.
>In your patch you use RAW only when the at keycodes are used so its ok.

Kostas, there's no problem with MEDIUMRAW and ADB keycodes, but we were
talking about CHRP/PReP, which use PS2 keyboards and must use RAW mode with
ASSUME_CUSTOM_KEYCODES undefined to work as expected with XKB. You should
know, you did extensive testing in this area :-).

>PS> There is a discussion in xfree about redesigning the keyboard driver
>but don't expect to see any changes in the near future.

Yeah, using the /dev/input/eventX devices for keyboard and mouse input
would greatly simplify the situation and prepare us for real
multihead/multiuser operation.

Franz.


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

Re: newer xfree86 4.0.1 patches

[Franz Sirl]

On Thu, 07 Sep 2000, Michel Dänzer wrote:
> Franz Sirl wrote:
> > > > On my TODO list, I still have to make chrp_setup.c and prep_setup.c
> > > > use machid_init_hw() and friends in machid.c.
> > >
> > >While you're at it, can you do apus_setup.c as well please?
> >
> > Sure I can, but APUS doesn't use either ADB or PS2 keyboards, or?
>
> No.
>
> > I'm not quite sure about the following:
> >
> > - does Apus have it's own keycodes?
>
> Yes, I think so. At least we need our own keymaps.
>
> > If not, do you currently use ADB or AT keycodes?
> > - what's the keycode situation in XF3/4 for Apus?
>
> AFAIK it isn't very clean with either, the best bet is still to disable
> Xkb.

On PPC we can switch the keycodes between ADB and Linux with a sysctl. Linux
keycodes are ~95% compatible with AT keycodes, so XKB will work.

> > - if your developer repository for 2.4 is different from BK linuxppc_2_3,
> > did you integrate your input layer drivers in your trees and plan to
> > submit them for 2.4?
>
> We have a CVS repository at SourceForge. Roman Zippel integrates bitkeeper
> into it, but unfortunately we don't have anyone for the reverse direction.
> How could that be done?

Via Linus probably, but in this special case we could arrange something.

> > If you want to keep the current state of affairs I can see in the
> > linuxppc_2_3 tree, there's not much point in using machid.c, AFAICS. On
> > the other hand, if you plan to integrate your input drivers into 2.4, it
> > makes perfect sense.
>
> I think it would be nice, but to be honest I don't fully understand what
> would be involved.

Actually not much, given the Apus input drivers in the linuxconsole
repository ("ruby") on sourceforge are already functional, it's simply a
matter of copying the files and modifying the configuration scripts. If you
want to continue to support Apus keycodes, you need some translation code in
input/keybdev.c too.

Franz.

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

Re: newer xfree86 4.0.1 patches

[Michel Dänzer]

Franz Sirl wrote:

> > > - what's the keycode situation in XF3/4 for Apus?
> >
> > AFAIK it isn't very clean with either, the best bet is still to disable
> > Xkb.
>
> On PPC we can switch the keycodes between ADB and Linux with a sysctl. Linux
> keycodes are ~95% compatible with AT keycodes, so XKB will work.

That would be great IMHO.


> > > - if your developer repository for 2.4 is different from BK
> > > linuxppc_2_3, did you integrate your input layer drivers in your trees
> > > and plan to submit them for 2.4?
> >
> > We have a CVS repository at SourceForge. Roman Zippel integrates bitkeeper
> > into it, but unfortunately we don't have anyone for the reverse direction.
> > How could that be done?
>
> Via Linus probably, but in this special case we could arrange something.

Please post to linux-apus-devel@lists.sourceforge.net what we'd have to do.


> > > If you want to keep the current state of affairs I can see in the
> > > linuxppc_2_3 tree, there's not much point in using machid.c, AFAICS. On
> > > the other hand, if you plan to integrate your input drivers into 2.4, it
> > > makes perfect sense.
> >
> > I think it would be nice, but to be honest I don't fully understand what
> > would be involved.
>
> Actually not much, given the Apus input drivers in the linuxconsole
> repository ("ruby") on sourceforge are already functional,

I don't know, so I assume not :(

> it's simply a matter of copying the files and modifying the configuration
> scripts. If you want to continue to support Apus keycodes, you need some
> translation code in input/keybdev.c too.

Thanks.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Re: newer xfree86 4.0.1 patches

[Franz Sirl]

At 03:23 08.09.00, Michel Dänzer wrote:

>Franz Sirl wrote:
>
> > > > - what's the keycode situation in XF3/4 for Apus?
> > >
> > > AFAIK it isn't very clean with either, the best bet is still to disable
> > > Xkb.
> >
> > On PPC we can switch the keycodes between ADB and Linux with a sysctl.
> Linux
> > keycodes are ~95% compatible with AT keycodes, so XKB will work.
>
>That would be great IMHO.

And easy to do. See below.

> > > > - if your developer repository for 2.4 is different from BK
> > > > linuxppc_2_3, did you integrate your input layer drivers in your trees
> > > > and plan to submit them for 2.4?
> > >
> > > We have a CVS repository at SourceForge. Roman Zippel integrates
> bitkeeper
> > > into it, but unfortunately we don't have anyone for the reverse
> direction.
> > > How could that be done?
> >
> > Via Linus probably, but in this special case we could arrange something.
>
>Please post to linux-apus-devel@lists.sourceforge.net what we'd have to do.

- get yourself the linuxconsole CVS from sourceforge (codename ruby)
- copy ruby/.../input/amikbd.c to apus24tree/.../char/
- copy ruby/.../input/amimouse.c to apus24tree/.../char/
- modify apus24tree/.../char/Config.in and apus24tree/.../char/Makefile in
a way that CONFIG_INPUT_AMIKBD and CONFIG_INPUT_AMIMOUSE replace the
current amikeyb.c and amigamouse.c
- compile & install the kernel, with the following minimum options:
         CONFIG_INPUT=y
         CONFIG_INPUT_AMIKBD=y
         CONFIG_INPUT_AMIMOUSE=y
         CONFIG_INPUT_KEYBDEV=y
         CONFIG_INPUT_MOUSEDEV=y

- make sure _absolutely no_ keymap is loaded on bootup, on RH style setups,
this means "rm -f /etc/sysconfig/keyboard
/etc/sysconfig/console/default.kmap" (it may be a bit different, I'm
quoting from memory). The default kernel keymap in pc_keyb.c has to be in
effect on reboot.
- reboot with new kernel

Now, with the new kernel, most of the keys and the mouse (/dev/input/mice,
protocol ImPS/2 for X, imps2 for gpm) should still work. There are for sure
pitfalls in the above description, but these should be solvable by someone
knowing the [Cc]onfig.in and Makefile setup for Apus. You should at least
get to a point where you can tell if the ami*.c input drivers in the
linuxconsole CVS are useable already.

For Apus keycodes backwards compatibility take a look at what I did in
apus24tree/.../input/keybdev.c and apus24tree/../macintosh/machid.c. To
generate a conversion table, goto ruby/utils and do the following:

         gcc -Dfrom=code -Dto=atari gencodes.c -o gencodes
         ./gencodes

> > > > If you want to keep the current state of affairs I can see in the
> > > > linuxppc_2_3 tree, there's not much point in using machid.c, AFAICS. On
> > > > the other hand, if you plan to integrate your input drivers into
> 2.4, it
> > > > makes perfect sense.
> > >
> > > I think it would be nice, but to be honest I don't fully understand what
> > > would be involved.
> >
> > Actually not much, given the Apus input drivers in the linuxconsole
> > repository ("ruby") on sourceforge are already functional,
>
>I don't know, so I assume not :(

Well, the code at least looks like someone already worked on it, so it may
be functional.

Franz.


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

Re: newer xfree86 4.0.1 patches

[Michel Dänzer]

Franz Sirl wrote:

> > > > > - what's the keycode situation in XF3/4 for Apus?
> > > >
> > > > AFAIK it isn't very clean with either, the best bet is still to
> > > > disable Xkb.
> > >
> > > On PPC we can switch the keycodes between ADB and Linux with a sysctl.
> > > Linux keycodes are ~95% compatible with AT keycodes, so XKB will work.
> >
> >That would be great IMHO.
>
> And easy to do. See below.

Thanks for the detailed description. Unfortunately, I'm currently very busy
with exams, work, DRI, APUS, ..., but if I can get some time I'll look into
it. Or better, I encourage the other APUS developers to do so.

BTW you mentioned that somebody apparently already worked on the Amiga part of
the linuxconsole code - do you know who did it?


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

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

Re: newer xfree86 4.0.1 patches

[Roman Zippel]

Hi,

> > We have a CVS repository at SourceForge. Roman Zippel integrates bitkeeper
> > into it, but unfortunately we don't have anyone for the reverse direction.
> > How could that be done?
>
> Via Linus probably, but in this special case we could arrange something.

Most of the changes are in the ppc subtree, so I would rather like to see
if they would go through one of the ppc trees, so they don't break
anything. On the other hand they also need a small cleanup especially some
mm part, as APUS is the only ppc machine where the memory doesn't start at
zero, but here I'm currently still looking for some strange bug - all
kernel virtual doesn't work (ioremap, vmalloc), but at least vmalloc did
work and I see nothing in the changes, what could have broken it, so I'm
still hunting...

bye, Roman


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