Hi All, I was eagerly waiting for some advice, but I note thatmy post never made it : The post is below :
Subject: Is now, how to send HID kbd stream to stdin from tty1 ? -------- Original Message -------- Subject: Mail delivery failed: returning message to sender Date: Wed, 13 Jan 2010 07:12:45 +0100 From: Mail Delivery System <[email protected]> To: [email protected] This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: pipe to |/opt/ecartis/ecartis -s kernelnewbies generated by [email protected] local delivery failed ------ This is a copy of the message, including all the headers. ------ Return-path: <[email protected]> Received: from smtp.virginbroadband.com.au ([123.200.191.11]) by humbolt.nl.linux.org with esmtp (Exim 4.22) id 1NUvXB-0007GM-9w for [email protected]; Wed, 13 Jan 2010 06:12:45 +0100 Received: from [192.168.1.2] (unknown [121.91.39.79]) by smtp.virginbroadband.com.au (Postfix) with ESMTP id D3F8E68F818A for <[email protected]>; Wed, 13 Jan 2010 16:11:58 +1100 (EST) Subject: Is now, how to send HID kbd stream to stdin from tty1 ? From: Microbit_Ubuntu <[email protected]> Reply-To: [email protected] To: [email protected] In-Reply-To: <1263290536.6890.16.ca...@development> References: <1263279212.1954.27.ca...@development> <1263290536.6890.16.ca...@development> Content-Type: text/plain; charset="UTF-8" Organization: Microbit Date: Wed, 13 Jan 2010 16:11:23 +1100 Message-ID: <1263359483.1940.8.ca...@development> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Received-SPF: 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 [email protected] Please read the FAQ at http://kernelnewbies.org/FAQ
