lkml.org 
[lkml]   [2005]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ioctl to keyboard device file
On Wed, 2005-05-11 19:53:20 +0200, Marcel Holtmann <marcel@holtmann.org> wrote:
> > >> 1) what is the device file corresponding to keyboard (is it
> > >> /dev/input/keyboard).
> > >> 2) where file operations structure is defined for that.
> > >> 3) where the those ioctls handled(not found in keyboard.c).
> > >>
> > >> Any small help is appreciated.
> > >
> > > why not using uinput for this job?
> >
> > Thanks for the solution. I did the above task, by defining a new
> > character device driver and sending ioctl to it. and calling
> > handle_scancode from it. Now I want
> > to do the same task with in the keyboard driver. For that I need to send
> > ioctl to keyboard device file.
> > For that only I asked the
> > above doubts.
>
> what your are trying to do looks wrong to me. Why don't you use uinput.
> It is there and it is the correct thing for the job.

I don't know what device the initial sender tries to support, but uinput
is only a solution for "normal" human input. I yet fail to see how
you'd support eg. keyboard-based magnetic stripe readers or barcode
scanners with it. These devices don't play nicely with atkbd: they send
some "random" make and break codes so you'd get some garbage from stdin.
But in reality, you'd rather prefer to (like for /dev/input/event*)
select() for a fully received magnetic stripe or barcode or the like.

Also, you may need to write (in terms of raw bytes) to the keyboard port
of the i8042 eg. to use keyboards with built-in displays.

Right now, I'm writing a driver (for 2.6.x) for some MSR. I'm attempting
to do this by having a "relay" serio port which is a serio client wrt.
the serio port registered by i8042. It shall register another serio port
(to which atkbd then connects) and supply an interface for some other
module to intercept/filter the make/break codes. It *could* be done with
serio_raw, but then you'd need to implement a full atkbd implementation
in userspace (which I consider being quite ugly...).

So the resumée is that the Input API is *really* cool for normal
devices, but from my point of view, it cannot really handle these
complicated Point of Sale devices nicely. Give us some days, we'll at
least put the serio_relay.c driver on the table. Maybe it's useful for
somebody else...

MfG, JBG

--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-05-11 20:23    [W:0.134 / U:6.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site