linuxconsole-dev

Re: iforce compilation fixes for 2.5.25

[Johann D. <jo...@do...>]

On Sun, 7 Jul 2002, Brad Hards wrote:

> The iforce code in 2.5.25 won't compile unless both USB and RS232 versions are 
> built into the kernel.

Indeed. A user reported that bug this week, and I fixed it in the version
for 2.4.18. I have yet to include the fix in linuxconsole CVS.

> 
> This patch fixes the two issues:
> 1. IFORCE_232 and IFORCE_USB are used in iforce-packet.c without testing if 
> they exist.

Those symbols were both used as "enums" for bus types and as configuration
options. Now IFORCE_{232,USB} is used for the bus type only, and
CONFIG_JOYSTICK_IFORCE_{232,USB}.

> 2. IFORCE_232 needs to be defined when the Config.in option is set as a module 
> or when built into the kernel. Same for IFORCE_USB.

The Config.in option can only be set to "y" or "n". iforce.o is a
multi-part driver, and the choice for RS232 in Config.in just tells if
iforce-serio.o should be included in iforce.o. Another option decides
whether iforce.o should be a module or not.

> 
> Brad
> 
> 

-- 
Johann Deneux

iforce compilation fixes for 2.5.25

[Brad H. <bh...@bi...>]

The iforce code in 2.5.25 won't compile unless both USB and RS232 versions are 
built into the kernel.

This patch fixes the two issues:
1. IFORCE_232 and IFORCE_USB are used in iforce-packet.c without testing if 
they exist.
2. IFORCE_232 needs to be defined when the Config.in option is set as a module 
or when built into the kernel. Same for IFORCE_USB.

Brad

-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

Re: question about ruby's keyboard.c & keybdev.c

[James S. <jsi...@tr...>]

> > > for maintenance reasons. keybdev.c provides bridge code between input
> > > layer and old-style keyboard.c. In ruby this is no longer necessary as
> > > the new-style keyboard.c registers itself directly to the input layer.
> > >

You still need keybdev.c with 2.5.25. It will be a few weeks before we
will migrate the console system to the input api.

> > That's right, I'm working on the merge right now.
>
> And now part#1 is in 2.5.25!! Yaayyy! Thanks Vojtech!

Just a few more steps to go. I submited the console patches to Linus. Now
to wait for them to go in.

> While preparing the PPC part I noticed one thing though, how do you intend to
> handle the platforms (2 PPC embedded boards and MIPS AFAICS) that redefined
> kbd_read_input/kbd_read_status/kbd_write_output/kbd_write_command so far
> (using ioremap/readb/writeb and sometimes special access sequences)?

Why we break them. One thing I learned the hard way with the fbdev layer
is if you want to change the api you need to change the upper layer first
and break every driver. Its the only way it will work.

> Do you want #ifdefs in i8042.[ch]? Or separated includes and/or drivers like
> i8042-ppc.[ch]?

:-(

> One more thing, CONFIG_SERIO_I8042 currently depends on CONFIG_ISA, does this
> really make sense?

??

Re: question about ruby's keyboard.c & keybdev.c

[Franz S. <Fra...@la...>]

On Dienstag, 2. Juli 2002 14:52, Vojtech Pavlik wrote:
> On Tue, Jul 02, 2002 at 01:03:06PM +0200, Franz Sirl wrote:
> > With ruby you shouldn't compile keybdev.c at all, it's only in ruby CVS
> > for maintenance reasons. keybdev.c provides bridge code between input
> > layer and old-style keyboard.c. In ruby this is no longer necessary as
> > the new-style keyboard.c registers itself directly to the input layer.
> >
> > Maybe you should just wait some more days, Vojtech should be merging this
> > to Linus any day now.
>
> That's right, I'm working on the merge right now.

And now part#1 is in 2.5.25!! Yaayyy! Thanks Vojtech!

While preparing the PPC part I noticed one thing though, how do you intend to  
handle the platforms (2 PPC embedded boards and MIPS AFAICS) that redefined 
kbd_read_input/kbd_read_status/kbd_write_output/kbd_write_command so far 
(using ioremap/readb/writeb and sometimes special access sequences)?

Do you want #ifdefs in i8042.[ch]? Or separated includes and/or drivers like 
i8042-ppc.[ch]?

One more thing, CONFIG_SERIO_I8042 currently depends on CONFIG_ISA, does this 
really make sense?

Franz.

Re: working sidewinder driver

[Johann D. <jo...@do...>]

On 5 Jul 2002, Fabien Brachere wrote:

> Hello,
> 
> I almost finish to write the sidewinder driver using the patch of J.
> Deneux which I would to thanks because this patch save me a lot of time,
> I was tired of trying to compile ruby or even 2.5 series ...
> The driver support all kind of sidewinder effects except custom.

Nice !

> 
> I need people to test it: here is the address:

You could put an announcement on happypenguin.org, for example. You are
more likely to find people able to test your driver there, IMO.

> http://madfab.free.fr/ff/patch-2.4.18-ff-2.gz

I can't test it, but I will add a link on my web page.

> 
> I add a GTK utility to test it:
> http://madfab.free.fr/ff/gforce-0.2.tar.gz
> I think this utility should work with other force feedback devices but
> I'm not sure at all.

A quick try with my weel was unsuccessful, unfortunately.


It's nice having a driver for MS joysticks ! My guess is that many people
will appreciate that.

-- 
Johann Deneux

[PATCH] New Console part One.

[James S. <jsi...@tr...>]

After some testings here is the start of the new console system.
The changes here are removal of struct kbd_struct from handler_sysrq. Only
two sysrq functions actually use it. Sysrq should work with any kind of
console system and the major of them will lack a physical keyboard. The
second change is a cleanup and preparation of moving the VT console system
input devices over to the input api.

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'\_   _/`\
 \___)=(___/


 arch/i386/kernel/apm.c         |    2
 arch/ppc/xmon/start.c          |    2
 arch/ppc64/xmon/start.c        |    2
 drivers/acpi/system.c          |    2
 drivers/char/console.c         |   82 ++--
 drivers/char/keyboard.c        |  781 +++++++++++++++++++++--------------------
 drivers/char/sysrq.c           |   46 +-
 drivers/char/tty_io.c          |   15
 include/linux/console_struct.h |    1
 include/linux/sysrq.h          |   13
 11 files changed, 487 insertions(+), 459 deletions(-)

The BK link is

http://linuxconsole.bkbits.net/dev

diff:

http://www.transvirtual.com/~jsimmons/console.diff.gz

working sidewinder driver

[Fabien B. <fab...@fr...>]

Hello,

I almost finish to write the sidewinder driver using the patch of J.
Deneux which I would to thanks because this patch save me a lot of time,
I was tired of trying to compile ruby or even 2.5 series ...
The driver support all kind of sidewinder effects except custom.

I need people to test it: here is the address:
http://madfab.free.fr/ff/patch-2.4.18-ff-2.gz

I add a GTK utility to test it:
http://madfab.free.fr/ff/gforce-0.2.tar.gz
I think this utility should work with other force feedback devices but
I'm not sure at all.

Fabien

[PATCH] Console/tty system patch. II

[James S. <jsi...@tr...>]

I fixed that bug with VT switching. Give the new patch a try so I can push
it to Linus. Thanks!!

BK:
	http://linuxconsole.bkbits.net:8080/dev

diff:
	http://www.transvirtual.com/~jsimmons/console.diff.gz

diffstat:

 arch/i386/kernel/apm.c         |    2
 arch/ppc/xmon/start.c          |    2
 arch/ppc64/xmon/start.c        |    2
 drivers/acpi/system.c          |    2
 drivers/char/console.c         |   82 ++--
 drivers/char/keyboard.c        |  781 +++++++++++++++++++++--------------------
 drivers/char/sysrq.c           |   46 +-
 drivers/char/tty_io.c          |   15
 include/linux/console_struct.h |    1
 include/linux/sysrq.h          |   13
 11 files changed, 487 insertions(+), 459 deletions(-)

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'\_   _/`\
 \___)=(___/

Re: [PATCH] New Console system BK

[James S. <jsi...@tr...>]

>  > Without the patch, I can hold down alt and hit F1, F2, F3, F4, then
>  > release the alt key and I will have switched to each of the VTs.
>  > With this patch, I have to press/release alt for each Fx key.
>
> Strange, that's a reoccurance of a bug that happened many moons ago
> circa 2.5.4-dj or so, which James then subsequently fixed. Seems he
> dropped a bugfix or two..

Ah. I was using the old patches. I will have to find the fix and put it
into the keyboard driver.

Re: [PATCH] New Console system BK

[Dave J. <da...@su...>]

On Mon, Jul 01, 2002 at 08:11:28PM -0400, Skip Ford wrote:
 > James Simmons wrote:
 > > 
 > > Since 2.5.1 I have placed into the kernel part of the new console system
 > > code into the DJ tree. So it has been well tested. I was hoping to have
 > > all the keyboard devices ported over to the input api and the fbdev
 > > drivers over to the new api. Unfortunely due to time restraints this will
 > > not be the case. So here goes the first installment of the new console
 > > system. Please test it yourselves and I will push it to Linus soon.
 > > 
 > >  http://www.transvirtual.com/~jsimmons/console.diff.gz
 > 
 > With your patch, I have to release the alt key between Fx keys to change
 > VTs.  Is that intentional?
 > 
 > Without the patch, I can hold down alt and hit F1, F2, F3, F4, then
 > release the alt key and I will have switched to each of the VTs.
 > With this patch, I have to press/release alt for each Fx key.

Strange, that's a reoccurance of a bug that happened many moons ago
circa 2.5.4-dj or so, which James then subsequently fixed. Seems he
dropped a bugfix or two..

        Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: question about ruby's keyboard.c & keybdev.c

[Vojtech P. <vo...@su...>]

On Tue, Jul 02, 2002 at 01:03:06PM +0200, Franz Sirl wrote:
> At 12:43 02.07.2002, Svetoslav Slavtchev wrote:
> >Hi ,
> >is it supposed drivers/input/keybdev.c to declare the functions and variables,
> >that are allready defined in drivers/char/keyboard.c , more precisely 
> >x86keycodes
> >and the problematic emulate_raw,
> >
> >and ...
> >how can one compile kebdev
> >it seems to me that drivers/input/keybdev.c comes from standart 2.5 or may 
> >be -dj
> >but not from ruby, what i mean is in emulate_raw it uses handle_scancode,
> >which doesn't exist in ruby but exist in 2.5 and -dj
> >and as far i understand the code is replaced by put_queue
> >so .. ? should handle_scancode in keybdev.c be replaced by put_queue
> >
> >and the other unresolved symbol in keybdev.c -- kbd_ledfunc
> >it appears to me that in keyboard.c kbd_ledfunc is replyced by ledstate
> >is this correct ?
> >
> >so
> >how should one compile keybdev.c ?
> 
> With ruby you shouldn't compile keybdev.c at all, it's only in ruby CVS for 
> maintenance reasons. keybdev.c provides bridge code between input layer and 
> old-style keyboard.c. In ruby this is no longer necessary as the new-style 
> keyboard.c registers itself directly to the input layer.
> 
> Maybe you should just wait some more days, Vojtech should be merging this 
> to Linus any day now.

That's right, I'm working on the merge right now.

-- 
Vojtech Pavlik
SuSE Labs

Re: question about ruby's keyboard.c & keybdev.c

[Franz S. <Fra...@la...>]

At 12:43 02.07.2002, Svetoslav Slavtchev wrote:
>Hi ,
>is it supposed drivers/input/keybdev.c to declare the functions and variables,
>that are allready defined in drivers/char/keyboard.c , more precisely 
>x86keycodes
>and the problematic emulate_raw,
>
>and ...
>how can one compile kebdev
>it seems to me that drivers/input/keybdev.c comes from standart 2.5 or may 
>be -dj
>but not from ruby, what i mean is in emulate_raw it uses handle_scancode,
>which doesn't exist in ruby but exist in 2.5 and -dj
>and as far i understand the code is replaced by put_queue
>so .. ? should handle_scancode in keybdev.c be replaced by put_queue
>
>and the other unresolved symbol in keybdev.c -- kbd_ledfunc
>it appears to me that in keyboard.c kbd_ledfunc is replyced by ledstate
>is this correct ?
>
>so
>how should one compile keybdev.c ?

With ruby you shouldn't compile keybdev.c at all, it's only in ruby CVS for 
maintenance reasons. keybdev.c provides bridge code between input layer and 
old-style keyboard.c. In ruby this is no longer necessary as the new-style 
keyboard.c registers itself directly to the input layer.

Maybe you should just wait some more days, Vojtech should be merging this 
to Linus any day now.

Franz.

question about ruby's keyboard.c & keybdev.c

[Svetoslav S. <ga...@st...>]

Hi , 
is it supposed drivers/input/keybdev.c to declare the functions and variables,
that are allready defined in drivers/char/keyboard.c , more precisely x86keycodes
and the problematic emulate_raw,

and ...
how can one compile kebdev
it seems to me that drivers/input/keybdev.c comes from standart 2.5 or may be -dj
but not from ruby, what i mean is in emulate_raw it uses handle_scancode, 
which doesn't exist in ruby but exist in 2.5 and -dj 
and as far i understand the code is replaced by put_queue
so .. ? should handle_scancode in keybdev.c be replaced by put_queue

and the other unresolved symbol in keybdev.c -- kbd_ledfunc
it appears to me that in keyboard.c kbd_ledfunc is replyced by ledstate
is this correct ?

so
how should one compile keybdev.c ?
 
thanks for any hints

regards 

svetljo

Re: ruby CVS compile error

[Aivils S. <Aiv...@un...>]

> Huh ? mousedev needed to get a USB keyboard working ?

Yep , I couldn't start any USB device wihout "XXXXX interface".
Keyboard interface is broken - this show up when ruby ally with linux-dj.
So  I use mousdev.
USB keyboard as USB-HID device work fine.

Aivils Stoss

p.s. Before linux-dj epoch Keyboard interface do not exist in ruby
makefiles

Re: ruby CVS compile error

[Johann D. <jo...@do...>]

On Tue, 2 Jul 2002, Aivils Stoss wrote:

> 
> Hi
> 
> Ruby keyboard drivesa never use "Keyboard interface" (TURN OFF!)
> All keyboards works fine without this.
> USB HID devices (USB keyboard) need "Mouse interface"

Huh ? mousedev needed to get a USB keyboard working ?


-- 
Johann Deneux

Re: ruby CVS compile error

[Aivils S. <Aiv...@un...>]

Hi

Ruby keyboard drivesa never use "Keyboard interface" (TURN OFF!)
All keyboards works fine without this.
USB HID devices (USB keyboard) need "Mouse interface"

Aivils

Re: [PATCH] New Console system BK

[Skip F. <ski...@ve...>]

James Simmons wrote:
> 
> Since 2.5.1 I have placed into the kernel part of the new console system
> code into the DJ tree. So it has been well tested. I was hoping to have
> all the keyboard devices ported over to the input api and the fbdev
> drivers over to the new api. Unfortunely due to time restraints this will
> not be the case. So here goes the first installment of the new console
> system. Please test it yourselves and I will push it to Linus soon.
> 
>  http://www.transvirtual.com/~jsimmons/console.diff.gz

With your patch, I have to release the alt key between Fx keys to change
VTs.  Is that intentional?

Without the patch, I can hold down alt and hit F1, F2, F3, F4, then
release the alt key and I will have switched to each of the VTs.
With this patch, I have to press/release alt for each Fx key.

-- 
Skip

[PATCH] New Console system BK

[James S. <jsi...@tr...>]

Since 2.5.1 I have placed into the kernel part of the new console system
code into the DJ tree. So it has been well tested. I was hoping to have
all the keyboard devices ported over to the input api and the fbdev
drivers over to the new api. Unfortunely due to time restraints this will
not be the case. So here goes the first installment of the new console
system. Please test it yourselves and I will push it to Linus soon.

The goal is to create a system we can use keyboards without the console
system and the same true for framebuffer devices. This is most helpful on
embedded devices. The other goals to make the VT console system more
modular and lighter weight. The other goal is to make the VT tty system
multi-desktop.

Here are the changes so far:

I) Removal of struct kbd_struct from the sysrq handler. Why drag itr along
   when only two sysrq functions actually use it.

II) Massive rewrite and cleanup of keybaord.c.

III) Place struct tty_struct into struct vc_data. This sets up a one to
     one relationship. Avoids the nasty tricks of playing with fields from
     console_driver.

IV) Cleanup of VT tty/console initialization. A vty_init function to make
    it cleaner.

diffstat:

 arch/i386/kernel/apm.c         |    2
 arch/ppc/xmon/start.c          |    2
 arch/ppc64/xmon/start.c        |    2
 drivers/acpi/system.c          |    2
 drivers/char/console.c         |   82 ++--
 drivers/char/keyboard.c        |  779 +++++++++++++++++++++--------------------
 drivers/char/sysrq.c           |   46 +-
 drivers/char/tty_io.c          |   15
 include/linux/console_struct.h |    1
 include/linux/sysrq.h          |   13
 11 files changed, 485 insertions(+), 459 deletions(-)


The BK patch is at:

 http://linuxconsole.bkbits.net/dev

diff:

 http://www.transvirtual.com/~jsimmons/console.diff.gz

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'\_   _/`\
 \___)=(___/

Re: ruby CVS compile error

[Boris B. <bo...@ki...>]

On Mon, Jul 01, 2002 at 12:12:31AM +0200, Svetoslav Slavtchev wrote:
> Quoting Boris Bezlaj <bo...@ki...>:
> 
> > On Sun, Jun 30, 2002 at 11:34:12PM +0200, Svetoslav Slavtchev wrote:
> > 
> > ---- snip snap ----
> > 
> > > how did you compiled keyboard interface,
> > > handle_scancode and kbd_ledfunc are still in drivers/input/keybdev.c,
> > but they
> > > are removed from drivers/char/keyboard.c where they used to be
> > exported, 
> > > -->> unresolved symbols in keybdev.o -->> the kernel doesn't support
> > keyboards
> > > 
> > > any ideas 
> > 
> > You mentioned you run ruby code on 2.4? maybe there's your problem with
> > unresolved symbols..
> > 
> > i applied ruby on top of vanilla 2.5.24 and the first problem i got was
> > keyboard/built_in.o..there was no such file, apparently Makefiles don't
> > match..
> > So i linked it to keybdev.o? (which was wrong) and got till atkbd.o
> > module.
> > The kernel image compiled/linked fine tho, but i didn't try it :)
> 
> i've tried 2.5 as well, but with the same result,
> have  you compiled keybdev in the kernel, or as modules,
> if as modules , what said depmod -a System.map at make modules_install
> the both functions are in keybdev.c and in normal 2.5 they are exported as
> symbols from drivers/char/keyboard.c but are missing in ruby
> in ruby they are not defined
> 

i nevere got to modules_install as i have atkbd.c as module (which failed to build)

looks like current CVS version is "in between" ..better to wait some time

-- 
With best regards,

		Boris B.

Re: ruby CVS compile error

[Svetoslav S. <ga...@st...>]

> On Sun, Jun 30, 2002 at 11:34:12PM +0200, Svetoslav Slavtchev wrote:
> 
> ---- snip snap ----
> 
> > how did you compiled keyboard interface,
> > handle_scancode and kbd_ledfunc are still in drivers/input/keybdev.c,
> but they
> > are removed from drivers/char/keyboard.c where they used to be
> exported, 
> > -->> unresolved symbols in keybdev.o -->> the kernel doesn't support
> keyboards
> > 
> > any ideas 
> 
> You mentioned you run ruby code on 2.4? maybe there's your problem with
> unresolved symbols..
> 
> i applied ruby on top of vanilla 2.5.24 and the first problem i got was
> keyboard/built_in.o..there was no such file, apparently Makefiles don't
> match..
> So i linked it to keybdev.o? (which was wrong) and got till atkbd.o
> module.
> The kernel image compiled/linked fine tho, but i didn't try it :)

i've tried 2.5 as well, but with the same result,
have  you compiled keybdev in the kernel, or as modules,
if as modules , what said depmod -a System.map at make modules_install
the both functions are in keybdev.c and in normal 2.5 they are exported as
symbols from drivers/char/keyboard.c but are missing in ruby
in ruby they are not defined

[root@svetljo v2.5]# cat ruby/linux/drivers/input/keybdev.c | grep -n3
handle_scancode
104-            if (keycode > 255 || !mac_keycodes[keycode])
105-                    return -1;
106-
107:            handle_scancode((mac_keycodes[keycode] & 0x7f), down);
108-            return 0;
109-    }
110-#endif      /* CONFIG_MAC_ADBKEYCODES || CONFIG_ADB_KEYBOARD */
--
113-            return -1;
114-
115-    if (keycode == KEY_PAUSE) {
116:            handle_scancode(0xe1, 1);
117:            handle_scancode(0x1d, down);
118:            handle_scancode(0x45, down);
119-            return 0;
120-    }
121-
122-    if (keycode == KEY_SYSRQ && x86_sysrq_alt) {
123:            handle_scancode(0x54, down);
124-
125-            return 0;
126-    }
--
133-#endif
134-
135-    if (x86_keycodes[keycode] & 0x100)
136:            handle_scancode(0xe0, 1);
137-
138:    handle_scancode(x86_keycodes[keycode] & 0x7f, down);
139-
140-    if (keycode == KEY_SYSRQ) {
141:            handle_scancode(0xe0, 1);
142:            handle_scancode(0x37, down);
143-    }
144-
145-    if (keycode == KEY_LEFTALT || keycode == KEY_RIGHTALT)
[root@svetljo v2.5]#cat ruby/linux/drivers/input/keybdev.c | grep -n3
kbd_ledfunc
249-static int __init keybdev_init(void)
250-{
251-    input_register_handler(&keybdev_handler);
252:    kbd_ledfunc = keybdev_ledfunc;
253-    return 0;
254-}
255-
256-static void __exit keybdev_exit(void)
257-{
258:    kbd_ledfunc = NULL;
259-    input_unregister_handler(&keybdev_handler);
260-}
261-
[root@svetljo v2.5]#

Re: pretty sad + Re: HELP with aiptek and keybdev

[Brad H. <bh...@bi...>]

On Sun, 30 Jun 2002 04:29, Svetoslav Slavtchev wrote:
> and what does this mean
>
> Unable to handle kernel NULL pointer dereference*pde = 000
> 00000
It means what it says. You have a pointer that is not initialised, or is 
initialised to zero, and it is being dereferenced. Could be just about 
anything, although the most common error is to forget to kmalloc a structure, 
and then reference an element.

> Oops: 0000
> CPU:    1
> EIP:    0010:[<c0216111>]    Not tainted
> EFLAGS: 00010297
> eax: 0000007e   ebx: 00000000   ecx: 0000007e   edx: 00000001
> esi: c2ad1010   edi: 0000007e   ebp: c12d7d58   esp: c12d7d40
> ds: 0018   es: 0018   ss: 0018
> Process swapper (pid: 0, stackpage=c12d7000)
> Stack: c12d7d58 00000001 0000007e 00000001 c2ad1010 0000007e c12d7d6c
> c021635a 00000000 0000007e 00000001 c12d7d9c c0265ffd c2269ce0 00000001
> 0000007e 00000001 00000000 33323130 c2269ce0 c24e2460 00000001 c24e2500
> c12d7dcc Call Trace: [<c021635a>] [<c0265ffd>] [<c0265b98>] [<c02629ba>]
> [<c0262ae7>] [<c0240a28>] [<c0262d14>] [<c0262d38>] [<c28e31b2>]
> [<c28e357e>] [<c28e3621>]
>
>    [<c010a004>] [<c010a34b>] [<c010c638>] [<c0106eb4>] [<c0106ef7>]
> [<c011b2a8>]
>
>    [<c011b112>] [<c0105000>]
>
> Code: 8b 33 74 12 0f b6 45 f0 00 c0 30 d0 0f b6 c0 50 e8 ac 49 ff
>  Kernel panic: Aiee, killing interrupt handler!
> In interrupt handler - not syncing
You can figure out where the problem is by running this through a program 
called ksymoops, which turns these stack variables back into a call trace. 
You _must_ do this yourself, with a System.map file that matches your kernel 
compile.

Brad

-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

Re: ruby CVS compile error

[Boris B. <bo...@ki...>]

On Sun, Jun 30, 2002 at 11:34:12PM +0200, Svetoslav Slavtchev wrote:

---- snip snap ----

> how did you compiled keyboard interface,
> handle_scancode and kbd_ledfunc are still in drivers/input/keybdev.c, but they
> are removed from drivers/char/keyboard.c where they used to be exported, 
> -->> unresolved symbols in keybdev.o -->> the kernel doesn't support keyboards
> 
> any ideas 

You mentioned you run ruby code on 2.4? maybe there's your problem with unresolved symbols..

i applied ruby on top of vanilla 2.5.24 and the first problem i got was keyboard/built_in.o..there was no such file, apparently Makefiles don't match..
So i linked it to keybdev.o? (which was wrong) and got till atkbd.o module.
The kernel image compiled/linked fine tho, but i didn't try it :)

-- 
With best regards,

		Boris B.

Re: ruby CVS compile error

[Svetoslav S. <ga...@st...>]

Quoting Boris Bezlaj <bo...@ki...>:

> On Sun, Jun 30, 2002 at 08:35:41PM +0200, Svetoslav Slavtchev wrote:
> > Quoting Boris Bezlaj <bo...@ki...>:
> > 
> > > Hi all.
> > > 
> > > During compile i get this error. I choosed AT keyb as module..
> > > Anyone else got this or is it just me ?
> > > 
> > Hi
> > i'm running it curruntly with a custom 2.4,
> > ( only under X with the patched X server wich supports event
> interface,
> >  thanks to Miguel Freitas
> http://cambuca.ldhs.cetuc.puc-rio.br/multiuser)
> > but due to keyboard interface ( which AFAIK can not be compiled ) 
> > under console or normal X i have no keyboard
> > may be it is a problem from 2.5.24 , you probbably should try the
> patches from
> > linuxHQ or may be to adopt ruby to the -dj tree
> 
> you mean linuxhq.com ?

right :)
http://www.linuxhq.com/kernel/v2.5/unofficial/v2.5.24/

> i will look in the -dj tree for changes..
> 
> > 
> > and i think it is a good idea to compile it in, not as module,
> > cause until the kernel loads it ( if it loads it ) you don't have a
> keyboard
> 
> i thought of that..i insmod it early in rc scripts
> OTOH, you are right..
how did you compiled keyboard interface,
handle_scancode and kbd_ledfunc are still in drivers/input/keybdev.c, but they
are removed from drivers/char/keyboard.c where they used to be exported, 
-->> unresolved symbols in keybdev.o -->> the kernel doesn't support keyboards

any ideas 

Re: ruby CVS compile error

[Boris B. <bo...@ki...>]

On Sun, Jun 30, 2002 at 08:35:41PM +0200, Svetoslav Slavtchev wrote:
> Quoting Boris Bezlaj <bo...@ki...>:
> 
> > Hi all.
> > 
> > During compile i get this error. I choosed AT keyb as module..
> > Anyone else got this or is it just me ?
> > 
> Hi
> i'm running it curruntly with a custom 2.4,
> ( only under X with the patched X server wich supports event interface,
>  thanks to Miguel Freitas http://cambuca.ldhs.cetuc.puc-rio.br/multiuser)
> but due to keyboard interface ( which AFAIK can not be compiled ) 
> under console or normal X i have no keyboard
> may be it is a problem from 2.5.24 , you probbably should try the patches from
> linuxHQ or may be to adopt ruby to the -dj tree

you mean linuxhq.com ?
i will look in the -dj tree for changes..

> 
> and i think it is a good idea to compile it in, not as module,
> cause until the kernel loads it ( if it loads it ) you don't have a keyboard

i thought of that..i insmod it early in rc scripts
OTOH, you are right..

> 
> > BUILD_BASENAME=atkbd   -c -o atkbd.o atkbd.c
> > atkbd.c:123: field `tq' has incomplete type
> > atkbd.c: In function `atkbd_interrupt':
> > atkbd.c:164: warning: implicit declaration of function `queue_task'
> > atkbd.c:164: `tq_immediate_R0da0dcd1' undeclared (first use in this
> > function)
> > atkbd.c:164: (Each undeclared identifier is reported only once
> > atkbd.c:164: for each function it appears in.)
> > make[3]: *** [atkbd.o] Error 1
> > 

-- 
With best regards,

		Boris B.

Re: ruby CVS compile error

[Svetoslav S. <ga...@st...>]

Quoting Boris Bezlaj <bo...@ki...>:

> Hi all.
> 
> During compile i get this error. I choosed AT keyb as module..
> Anyone else got this or is it just me ?
> 
Hi
i'm running it curruntly with a custom 2.4,
( only under X with the patched X server wich supports event interface,
 thanks to Miguel Freitas http://cambuca.ldhs.cetuc.puc-rio.br/multiuser)
but due to keyboard interface ( which AFAIK can not be compiled ) 
under console or normal X i have no keyboard
may be it is a problem from 2.5.24 , you probbably should try the patches from
linuxHQ or may be to adopt ruby to the -dj tree

and i think it is a good idea to compile it in, not as module,
cause until the kernel loads it ( if it loads it ) you don't have a keyboard

> BUILD_BASENAME=atkbd   -c -o atkbd.o atkbd.c
> atkbd.c:123: field `tq' has incomplete type
> atkbd.c: In function `atkbd_interrupt':
> atkbd.c:164: warning: implicit declaration of function `queue_task'
> atkbd.c:164: `tq_immediate_R0da0dcd1' undeclared (first use in this
> function)
> atkbd.c:164: (Each undeclared identifier is reported only once
> atkbd.c:164: for each function it appears in.)
> make[3]: *** [atkbd.o] Error 1
> 
> -- 
> With best regards,
> 
> 		Boris B.
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> No, I will not fix your computer.
> http://thinkgeek.com/sf
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
>