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)
--
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
