Hello Norbert,
I did some more testing with kbdmux.
1. I wait for the screen saver becoming active.
2. I press the control key.
3. All keys, I press after that,
come as control keys, e.g.
I press 'j' or 'J' and see a
linefeed, I press 'I' and see a tab.
4. I wait a second time for the
Hello,
I did some more testing with kbdmux.
1. I wait for the screen saver becoming active.
2. I press the control key.
3. All keys, I press after that,
come as control keys, e.g.
I press 'j' or 'J' and see a
linefeed, I press 'I' and see a tab.
4. I wait a second time for the screen save
> >In gdb "bt" only shows two entries. The function where the panic
> >occurred and 0x0!
> >
> >
>
> that is normal
> you don't want to jump into gdb that soon.
> there is hardly anything set up.
>
> use the sysctl to enter gdb later.
>
> >BTW, after boot -gd, when gdb attaches I have a kernel pani
Norbert Koch wrote:
When quickly connecting/disconnecting
i guess you mean here unplug the keyboard and then immediately plug it
back, right?
sounds like he means "repeatedly."
yes
booting with -gd drops you into the (gdb) debugger immediatly..
I presume you ha
> > When quickly connecting/disconnecting
>
> i guess you mean here unplug the keyboard and then immediately plug it
> back, right?
I mean plug in / plug out, repeat for ever.
> can you tell what value "pipe" handle has? i suspect its NULL
yes
> can you tell what value "iface" handle has? i s
> >
> >> When quickly connecting/disconnecting
> >
> >
> > i guess you mean here unplug the keyboard and then immediately plug it
> > back, right?
> >
>
> sounds like he means "repeatedly."
yes
> booting with -gd drops you into the (gdb) debugger immediatly..
>
> I presume you have a gdb looki
Maksim Yevmenkin wrote:
Norbert,
I am observing spurious crashes in usb0 under FreeBSD 4.11.
Kernel configuration/hardware:
HZ=400, NO_SWAPPING, DEVICE_POLLING (with kern.polling.user_frac=90),
fxp ethernet, 6x sio, ohci, Pentium MMX 166 MHz
could you try to compile kernel with de
Norbert,
The ukbd-specific detaching only works, because I implemented
something in ukbd.c, that Hans Petter Selasky [EMAIL PROTECTED]
suggested in thread "usbd.conf: detach ukbd". (See the patch files,
I posted there)
When the kernel panics, it does this in usb0 kernel thread. I
figured out th
> The ukbd-specific detaching only works, because I implemented something in
> ukbd.c,
> that Hans Petter Selasky [EMAIL PROTECTED] suggested in thread
> "usbd.conf:
> detach ukbd".
> (See the patch files, I posted there)
>
> When the kernel panics, it does this in usb0 kernel thread.
> I figured o
> > seems to work, although I still have some stability issues with
> > dynamically attaching/detaching a usb keyboard. For your reference I
>
> would you share with us what sort of issues you are having? feel free to
> move this into private email if you are not comfortable discussing it on
> publ
Hi Norbert,
you also might want to look at experimental keyboard mux drivers.
it is based on vkbd(4) and uses the idea of one super-keyboard that
consumes scancodes from other keyboards. there are still a few
issues i need to fix, but, in general, it works.
http://www.geocities.com/m_evmenkin/k
> you also might want to look at experimental keyboard mux drivers. it is
> based on vkbd(4) and uses the idea of one super-keyboard that consumes
> scancodes from other keyboards. there are still a few issues i need to
> fix, but, in general, it works.
>
> http://www.geocities.com/m_evmenkin/k
Norbert,
I am trying to use vkbd to multiplex
an at keyboard and an usb keyboard
into syscons.
ok
Vkbd's control device's write routine
expects ints to queue to the slave device.
correct
As I understand, those ints map 1:1
to the chars I read from a keyboard device, right?
yes, the int
Hello,
I am trying to use vkbd to multiplex
an at keyboard and an usb keyboard
into syscons.
Vkbd's control device's write routine
expects ints to queue to the slave device.
As I understand, those ints map 1:1
to the chars I read from a keyboard device, right?
So I open, for example, /dev/kbd0,
14 matches
Mail list logo