Menu
▾
▴
linux-apus-devel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(210) |
Jun
(169) |
Jul
(167) |
Aug
(128) |
Sep
(218) |
Oct
(120) |
Nov
(86) |
Dec
(71) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(91) |
Feb
(179) |
Mar
(52) |
Apr
(56) |
May
(183) |
Jun
(62) |
Jul
(63) |
Aug
(49) |
Sep
(36) |
Oct
(35) |
Nov
(72) |
Dec
(30) |
| 2002 |
Jan
(53) |
Feb
(61) |
Mar
(56) |
Apr
(13) |
May
(1) |
Jun
(7) |
Jul
(80) |
Aug
(73) |
Sep
(30) |
Oct
(29) |
Nov
(8) |
Dec
(40) |
| 2003 |
Jan
(10) |
Feb
(2) |
Mar
(4) |
Apr
(9) |
May
(3) |
Jun
(19) |
Jul
(64) |
Aug
(53) |
Sep
(28) |
Oct
(7) |
Nov
(3) |
Dec
(21) |
| 2004 |
Jan
(11) |
Feb
(30) |
Mar
(18) |
Apr
(1) |
May
(13) |
Jun
(18) |
Jul
(13) |
Aug
|
Sep
(9) |
Oct
(5) |
Nov
|
Dec
|
| 2005 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(10) |
Aug
(21) |
Sep
(7) |
Oct
(10) |
Nov
(6) |
Dec
|
| 2006 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(2) |
Sep
(6) |
Oct
(10) |
Nov
(8) |
Dec
(3) |
| 2007 |
Jan
(3) |
Feb
(6) |
Mar
(1) |
Apr
(6) |
May
(10) |
Jun
(7) |
Jul
(13) |
Aug
(8) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
|
From: Alan B. <al...@ms...> - 2000-09-11 14:08:55
|
hi, > > could some people please download or read the docs and we can then startup > > a discussion of changes to be made/added to this.... > > One thing that bothers me is that both the 'Kernels' & 'Boothack' and 'Docs' & > 'FAQ" links point to the same location. do they? ouch. the kernel should point to the modules page, as should the boothack really. the FAQ should point to the documents that we currently have, and the docs should point ot a new page that cotains documents about other bits....info about the bootstrap/kernels etc for example. alan |
|
From: Michel <dae...@st...> - 2000-09-11 14:04:54
|
Alan Buxey wrote: > the documentation is now back online at http://linux-apus.sourceforge.net Thanks Alan. > could some people please download or read the docs and we can then startup > a discussion of changes to be made/added to this.... One thing that bothers me is that both the 'Kernels' & 'Boothack' and 'Docs' & 'FAQ" links point to the same location. BTW, I've finally come around to converting the site to use a template for all pages. It's done in PHP (which also does the 'last updated' thing automagically :), please have a look at the new files. In case I've done something wrong, I've moved the old plain HTML files to a new obsolete/ dir. Oh, and Sinan: Please stop writing the HTML files back again ;) Michel PS: If you don't like that the names of the files have changed, I can revert them easily... -- 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: 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: Ken T. <ke...@we...> - 2000-09-08 22:25:31
|
On Fri, 8 Sep 2000, Alan Buxey wrote: > can you please clarify. the modules contain the files, no readmes - they > should be in the docs section - unless they are in archives (not something > you want to do with ramdisk images I guess!) the README details can be > added to the documentation tree as soon as, i guess. OK, I didn't realise that's how it worked. I've put the files in the ftp area, please feel free to move/copy them at your pleasure. > the docs are now up by the way, but boy! do they need some modification! > > (I think we should keep the FAQ...just upgrade it!...and have a seperate > entry for Docs...as there is already designed on the linux-apus frontend > web page....under which we have the documents relating to ramdisk > installers etc) I'm quite happy to take on the FAQ but got no where with Jesper's Docbook magic. I think we should keep the sgml version and generate html, txt, whatever from it. I don't feel like generating a pure text version by hand from the sgml and updating it, and then doing it all again if I ever get Docbook to work. Ken. |
|
From: Ken T. <ke...@we...> - 2000-09-08 22:17:09
|
On Fri, 8 Sep 2000, Michel [iso-8859-1] Dänzer wrote: > Are you trying to use debug=mem ? That didn't work for me the last time I > tried. I'll try without it. Ken. |
|
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: Michel <dae...@st...> - 2000-09-08 16:13:47
|
Ken Tyler wrote: > I compiled a 2.3 kernel after switching to 2.95-2 but it won't boot. > > Tried all the possible binaries, vmapus, zvmliux and vmliunx compressed > and decompressed with the latest boothack. > > Bootmesg gets to k (K?) but no life after that, no dmesgs are generated > either. Are you trying to use debug=mem ? That didn't work for me the last time I tried. 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: Alan B. <al...@ms...> - 2000-09-08 15:07:46
|
hi, > Give me an hour and I'll add that and a couple of other things to the > README then can you copy all the ftp install to the module place please ? can you please clarify. the modules contain the files, no readmes - they should be in the docs section - unless they are in archives (not something you want to do with ramdisk images I guess!) the README details can be added to the documentation tree as soon as, i guess. the docs are now up by the way, but boy! do they need some modification! (I think we should keep the FAQ...just upgrade it!...and have a seperate entry for Docs...as there is already designed on the linux-apus frontend web page....under which we have the documents relating to ramdisk installers etc) alan |
|
From: Ken T. <ke...@we...> - 2000-09-08 14:54:02
|
On Fri, 8 Sep 2000, Alan Buxey wrote: > > Can't see a precompiled kernel with that date... > > if you look at the actual linux-apus project page, rather than the FTP > region, and choose the 'files' menu, it'll bring up a list in which theres > vmapus-2.2.10-000814.lha and vmapus-2.2.10-000815.tar.gz, same contents, > different upload date Give me an hour and I'll add that and a couple of other things to the README then can you copy all the ftp install to the module place please ? > > Hope its a monolithic kernel too... > > the important parts are in there :-) Fine. Ken. |
|
From: Ken T. <ke...@we...> - 2000-09-08 14:49:23
|
Hello, I compiled a 2.3 kernel after switching to 2.95-2 but it won't boot. Tried all the possible binaries, vmapus, zvmliux and vmliunx compressed and decompressed with the latest boothack. Bootmesg gets to k (K?) but no life after that, no dmesgs are generated either. Ken. |
|
From: Alan B. <al...@ms...> - 2000-09-08 14:46:36
|
hi, > > I'm doing that now.... so dont worry Ken! :-) > > Good, no idea how to get it into a module ! that's okay, it is tricky/fiddly > > - also moving the 'old' to the obsolete as asked > > Too late ! :) i noticed! :-) alan |
|
From: Ken T. <ke...@we...> - 2000-09-08 14:45:46
|
Hi, Didn't we used to have a patch in the 2.2 tree to turn off the heart beat when sound was playing ? If we did it got lost. I've patched my source with a patch that 'someone' posted about 12 months ago. Can the originator own up for credit ? If I can figure out how to stop the kb beep/crsshhsss noise when sound is playing I'll work that in. Ken. |
|
From: Alan B. <al...@ms...> - 2000-09-08 14:45:44
|
hi, > Can't see a precompiled kernel with that date... if you look at the actual linux-apus project page, rather than the FTP region, and choose the 'files' menu, it'll bring up a list in which theres vmapus-2.2.10-000814.lha and vmapus-2.2.10-000815.tar.gz, same contents, different upload date > Hope its a monolithic kernel too... the important parts are in there :-) alan |
|
From: Ken T. <ke...@we...> - 2000-09-08 14:42:18
|
On Fri, 8 Sep 2000, Alan Buxey wrote: > hi, > > > Can you please also upload the stuff to the Ramdisks SourceForge module, and > > what about announcing it on the user list? > I'm doing that now.... so dont worry Ken! :-) Good, no idea how to get it into a module ! > I've also stuck a news release on site and released info to others OK. > - also moving the 'old' to the obsolete as asked Too late ! :) Ken |
|
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: Ken T. <ke...@we...> - 2000-09-08 14:29:59
|
On Fri, 8 Sep 2000, Alan Buxey wrote: > just to verify: the latest kernel (000814/15) archives have kernels with > HFS support. noone has reported this as broken, so this means the LinuxPPC > 2000 installer should work fine. Can't see a precompiled kernel with that date... If there is one I'll give it a try and put the exact name in the README (hope its 2.2, still can't boot 2.3). Hope its a monolithic kernel too... > PS in the README, it would be good to add the CD mount demonstration > for the kernel+ramdisk Done. Ken. |
|
From: Alan B. <al...@ms...> - 2000-09-08 14:26:44
|
hi, > Can you please also upload the stuff to the Ramdisks SourceForge module, and > what about announcing it on the user list? I'm doing that now.... so dont worry Ken! :-) I've also stuck a news release on site and released info to others - also moving the 'old' to the obsolete as asked alan |
|
From: Ken T. <ke...@we...> - 2000-09-08 14:15:30
|
On Fri, 8 Sep 2000, Michel [iso-8859-1] Dänzer wrote: > Ken Tyler wrote: > > > I've uploaded ramdisks, diffs, READMEs and a source tree for the Apus > > installer to the redhat subdir of install. There are two of everything, > > one for 1999 and one for 2000 LinuxPPC Cds. > > Can you please also upload the stuff to the Ramdisks SourceForge module, and > what about announcing it on the user list? OK, I'll work on it. > > I moved the existing contents to 'old' > > That's fine, though maybe moving it to the top-level 'obsolete' would be > better? Also OK. Ken. |
|
From: Michel <dae...@st...> - 2000-09-08 13:25:44
|
Ken Tyler wrote: > I've uploaded ramdisks, diffs, READMEs and a source tree for the Apus > installer to the redhat subdir of install. There are two of everything, > one for 1999 and one for 2000 LinuxPPC Cds. Can you please also upload the stuff to the Ramdisks SourceForge module, and what about announcing it on the user list? > I moved the existing contents to 'old' That's fine, though maybe moving it to the top-level 'obsolete' would be better? 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: Alan B. <al...@ms...> - 2000-09-08 13:11:01
|
hi, > I've uploaded ramdisks, diffs, READMEs and a source tree for the Apus > installer to the redhat subdir of install. There are two of everything, > one for 1999 and one for 2000 LinuxPPC Cds. > > I moved the existing contents to 'old' just to verify: the latest kernel (000814/15) archives have kernels with HFS support. noone has reported this as broken, so this means the LinuxPPC 2000 installer should work fine. PS in the README, it would be good to add the CD mount demonstration for the kernel+ramdisk mount -t hfs /dev/hdb /mnt alan |
|
From: Ken T. <ke...@we...> - 2000-09-08 12:26:59
|
Hello, I've uploaded ramdisks, diffs, READMEs and a source tree for the Apus installer to the redhat subdir of install. There are two of everything, one for 1999 and one for 2000 LinuxPPC Cds. I moved the existing contents to 'old' Ken. |
|
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. |
|
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: Ken T. <ke...@we...> - 2000-09-08 03:45:40
|
On Thu, 7 Sep 2000, Michel [iso-8859-1] Dänzer wrote: > > What's the significance of the floating point message ? > > AFAIK, kernel code shouldn't contain floating point code to reduce the > overhead for context switches etc. . arch/ppc/Makefile sets -msoft-float for > that, have you been playing with it? Ahhh, I see, you mean playing with the flag, No. The message appears when the kernel is compiled with egcs or gcc but only after an X crash - what does this suggest ? Ken |
|
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
|
107 messages has been excluded from this view by a project administrator.
