On Tue, 2010-01-12 at 21:02 +1100, Microbit_Ubuntu wrote:
> As follow up,
>
> On Tue, 2010-01-12 at 17:53 +1100, Microbit_Ubuntu wrote:
> > Hi all,
> >
> > I've recently started using USB keyboard on my embedded SAM9-L9260
> > board. Part reason is that I can send certain "hard" codes that are less
> > practical to send via serial ttyS0.
> >
> > Having studied the relevant code and docs for a few days, the
> > implication seems to be that after kernel setup of HID, a keyboard
> > should readily work, but it certainly doesn't on stdin.
> > I'm using kernel 2.6.31.6 - and FWIW, the docs
> > in /documentation/input.txt are outdated for a change - there is no
> > keybdev module anymore.. :-) (except for Mac I see)
> > Note : A ctrl-alt-del from the USB keyboard does cause a reboot on the
> > system, so some scan codes do find their way to stdin it seems ?
> >
> > The idea is that stdin/stdout/stderr still flow through the serial,
> > ttyS0/115200, but the kdb handler should equally input keyboard data on
> > stdin.
> >
> > I've avoided enabling kernel hiddev or hidraw, as I don't see any
> > benefit. I'm actually using a spare wireless keyboard/mouse device.
> > Hotplugging results in proper registration, and the device correctly
> > appears on /dev/input/event0 & /dev/input/event1.
> > An od -x on event0 indicates proper raw scancode traffic.
> > I compiled evtest.c and that comes out 100% fine too when run on my
> > target. All keys from HID are properly picked up and displayed on
> > terminal by evtest.
> >
> > Main question :
> > --------------
> >
> > Do I really need to start a daemon in user space, similar to evtest ie.
> > run an event handler on kbd ?
> > It seems keyboard.c should already be converting the raw scan codes and
> > send them on ?
> >
> > Or, perhaps, is it standard practice to enable atkbd in kernel and
> > 'pretend' that stdin ascii traffic is entering the kernel via this
> > (virtual) PS/2 keyboard ?
> > (Note that I don't enable input devices -> AT keyboard in kernel setup)
> >
> > Connecting the same device to my Ubuntu 9.10 host results in immediate
> > entry of HID keyboard data onto a terminal etc. But I noticed in PC
> > syslog that a couple of rules around 'xkbd' activate and handle that
> > traffic redirecting.
> >
> > Am I overlooking something silly, or does using a USB HID keyboard for
> > stdin on my embedded board really _does_ dictate a userspace utility to
> > convert scan code and redirect to stdin (so it displays on ttyS0
> > terminal output as echo AND results in system commands, as if it were
> > regular ttyS0 input) ????
> >
> > I would really appreciate any help, I've spent several days on this but
> > I don't seem to hit home on this one.....
> >
> >
>
> > Note : A ctrl-alt-del from the USB keyboard does cause a reboot on the
> > system, so some scan codes do find their way to stdin it seems ?
>
> A propos,
> I noticed that the func ptr array fn_handler[] in keyboard.c has an entry (fn_boot_it)
> (index 12). Seems this func simply calls ctrl_alt_del(), while ignoring vc_data struct *.
> /proc does indicate that kbd is registered.
>
> So, another solution would be to figure out which scan code generates
> calls for the func ptrs : fn_dec_console, fn_inc_console & fn_spawn_con.
> (index 16, 17 & 18).
> Going through k_spec, I can't seem to figure out what key/keys on the
> keyboard should call these functions ?
> I was in the belief that kbd_connect() takes care of setting VT.
> Yet, in /proc/class I have only one entry under vtcons folder
> <name> indicates <dummy device>, while uevent doesn't define 13:64 as my
> HID keyboard should be.
> Am I supposed to find an extra entry under {vtcons} ???
>
> I've been trying tracing how far the call : schedule_console_callback();
> in kbd_event() gets, but I seem to be still in the dark...
>
> Any gurus here that can give a nudge in the right direction ?
> (or if there is a simple solution that I'm missing, lost of searching on
> Google has come up empty so far)
>
Ok, to try simplify further, I've traced all scancode and keycode
conversion/lookup and kbd_event stuff all the way up to producing keysym
properly -- can't find anything wrong there either.
The console part of kernel command line : console=ttyS0,115200
has been extended to : console=tty1 console=ttyS0,115200
Testing like so :
cat /dev/tty1
prints out whatever I've entered on the HID keyboard after <CR> is
pressed.
So, this all seems OK - but still I can't give commands through HID.. ??
shift-ScrollLock and Ctrl-ScrollLock produces the output mem-info and
stat respectively. (keyboard.c)
I'm really stuck.. anyone has an idea why the /dev/tty1 can't drive my
command line ????
--
Best regards,
Kris
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
