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 ????
[ FWIW, I dumped contents of current tty at runtime (from vc_tty) and tty1
remains a <NULL> in its name
member. Strangely, inc-console to tty3 prints out the proper name tty3.
It's like vc_tty does not get bound properly, because printing out the
<index> member of current tty results in seg fault ??? ]
--
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
