hai,
I want to add a new ioctl to keyboard driver device file which will
perform the work of copying user space data sent to it into kernel
space and send those characters to handle_scancode function of keyboard
driver.. Now I want to know
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.
Thanks&Regards,
P.Manohar,
Hi,
> I want to add a new ioctl to keyboard driver device file which will
> perform the work of copying user space data sent to it into kernel
> space and send those characters to handle_scancode function of keyboard
> driver.. Now I want to know
>
> 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?
Regards
Marcel
n Wed, 11 May 2005, Marcel Holtmann wrote:
> Hi,
>
>> I want to add a new ioctl to keyboard driver device file which will
>> perform the work of copying user space data sent to it into kernel
>> space and send those characters to handle_scancode function of keyboard
>> driver.. Now I want to know
>>
>> 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?
Hai,
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.
regards,
P.Manohar.
Hi,
> >> I want to add a new ioctl to keyboard driver device file which will
> >> perform the work of copying user space data sent to it into kernel
> >> space and send those characters to handle_scancode function of keyboard
> >> driver.. Now I want to know
> >>
> >> 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.
Regards
Marcel
On Wed, 2005-05-11 19:53:20 +0200, Marcel Holtmann <[email protected]> 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 [email protected] . +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));