Menu
▾
▴
linux-apus-devel
|
From: Michel <dae...@st...> - 2000-09-07 15:14:49
|
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 |
|
From: Michel <dae...@st...> - 2000-09-08 01:27:23
|
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 lin...@li... 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
|
|
From: Franz S. <Fra...@la...> - 2000-09-08 14:31:47
|
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 lin...@li... 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.
|
|
From: Michel <dae...@st...> - 2000-09-08 16:21:09
|
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 |
|
From: Franz S. <Fra...@la...> - 2000-09-07 21:47:17
|
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.
|
|
From: Roman Z. <zi...@fh...> - 2000-09-09 10:26:35
|
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 |
|
From: Geert U. <ge...@li...> - 2000-09-07 20:05:33
|
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 -- ge...@li...
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
|
|
From: Michael S. <sc...@op...> - 2000-09-07 21:43:44
|
> > > 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 |
|
From: Franz S. <Fra...@la...> - 2000-09-07 22:00:33
|
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. |
|
From: Kostas G. <gew...@im...> - 2000-09-08 10:02:01
|
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. |
|
From: Franz S. <Fra...@la...> - 2000-09-08 10:34:10
|
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. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X