Input device driver

Input device driver

[Bruno E. O. Meneguele]

Hi folks, 

I'm trying to write an input device driver basicaly to play with
interrupt handlers. The idea at first was to catch all keys pressed on
my keyboard, nothing else, but some doubts rised after I wrote the
driver and it didn't work out.

The code so far is as follows:
https://gist.github.com/bmeneguele/621d4bbbfa28fca200df6ba289cfb3fc

Now the questions:
1) from /proc/interrupts I saw the i8042 keyboard+mouse controller on
IRQ line 1 and 12:

CPU0   CPU1     CPU2     CPU3                                      
0:       55        0        0       0 IR-IO-APIC   2-edge      timer     
1:      101        5        7       2 IR-IO-APIC   1-edge      i8042     
8:        0        0        0       1 IR-IO-APIC   8-edge      rtc0      
9:     7216     3565    16517    3485 IR-IO-APIC   9-fasteoi   acpi      
12:     212       29      323      51 IR-IO-APIC   12-edge     i8042     
16:       0        0        0       0 IR-IO-APIC   16-fasteoi  i801_smbus
19:      15        0        6       3 IR-IO-APIC   19-fasteoi             
[...]

then I thought I could share the line along with it, once in
drivers/input/serio/i8042.c the request_irq() is being called with
IRQF_SHARED. Is there a problem here?

2) I'm using a USB keyboard as the testing device, and TBH I got
confused if I could actually use the input subsystem for that or I
_should_ use HID instead (considering the keyboard is HID compliant).

3) the output I'm receiving is just one message regardless the number of
keys I press:

[... (make && insmod) ...]
$ dmesg | tail
[75013.625311] input: Bmeneg's Keyboard as /devices/virtual/input/input25
[75056.682676] [my_kbd] kbd_irq_handler:22:: irq 12 occured!             
[... (rmmod && make && insmod) ...]
[75132.203324] input: Bmeneg's Keyboard as /devices/virtual/input/input26
[75149.669112] [my_kbd] kbd_irq_handler:22:: irq 1 occured!              
[... (rmmod && make && insmod) ...]
[75164.213562] input: Bmeneg's Keyboard as /devices/virtual/input/input27
[75168.720791] [my_kbd] kbd_irq_handler:22:: irq 1 occured!              
[... (rmmod && make && insmod) ...]
[75390.584746] input: Bmeneg's Keyboard as /devices/virtual/input/input28
[75397.149047] [my_kbd] kbd_exit:73:: irq reference counter: 1           
[... (rmmod && make && insmod) ...]
[79146.583034] input: Bmeneg's Keyboard as /devices/virtual/input/input29
[79159.647871] [my_kbd] kbd_exit:73:: irq reference counter: 1           

as you can see I tried with prints inside IRQ handler, that I changed to
a ref counter considering a previous knowledge from embedded systems
that prints inside IRQs are bad :D (is it still true for linux kernel?),
and the output from prints (inside IRQs) just appears after I `rmmod`
the driver. 

Of course something is wrong in my code, but what? (handle kbd as input
device? IRQ shared with i8042? wrong way to handle IRQ?)

Well, this is my first time trying to accomplish something using real
hardware in kernel space, not using just tutorial copy/paste or
software-only things like timers. Because of that any info would be
really great. What I'm trying to get here is just dive into
bottom-helves execution (work queues) to understand how they actually
works and of course more advanced things later!

Thanks in advance!

Note: using kernel 4.12.12 here.

-- 
bmeneg 
PGP Key: http://bmeneg.com/pubkey.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170929/6e264833/attachment.bin 

Input device driver

[valdis.kletnieks at vt.edu]

On Fri, 29 Sep 2017 19:38:49 -0300, "Bruno E. O. Meneguele" said:

> 2) I'm using a USB keyboard as the testing device, and TBH I got
> confused if I could actually use the input subsystem for that or I
> _should_ use HID instead (considering the keyboard is HID compliant).

Step 0: Decide if you're writing an interrupt handling driver, a USB driver, or
an HID driver - the three live at different levels of abstraction, and
confusing them will also confuse both you and your kernel.

Step 1: Whichever level you decide on, your kernel probably already has a
driver that will gladly grab onto a USB keyboard at that level.  Find out how
to tell your kernel to not grab the device, as sharing a device between two
drivers never works out well, no matter what abstraction you're using.

Step 2: Take a backup of your system, just in case (which you should be doing
*anyhow* - neither spinning oxide disks nor flash-based drives are perfect).

Step 3: Write the driver....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170929/9de0d3f6/attachment.bin 

Input device driver

[Bruno E. O. Meneguele]

On 29-09, valdis.kletnieks at vt.edu wrote:
> On Fri, 29 Sep 2017 19:38:49 -0300, "Bruno E. O. Meneguele" said:
> 
> > 2) I'm using a USB keyboard as the testing device, and TBH I got
> > confused if I could actually use the input subsystem for that or I
> > _should_ use HID instead (considering the keyboard is HID compliant).
> 
> Step 0: Decide if you're writing an interrupt handling driver, a USB driver, or
> an HID driver - the three live at different levels of abstraction, and
> confusing them will also confuse both you and your kernel.
> 

I don't know why I didn't realize earlier the two counterparts:
interruption vs USB, USB devices are handled in polling mode, not
with IRQs.

So, I could try something else to dive in IRQ's world, like 'timers' or
stick with USB world for now, let's say I choose: USB driver in this
step.

> Step 1: Whichever level you decide on, your kernel probably already has a
> driver that will gladly grab onto a USB keyboard at that level.  Find out how
> to tell your kernel to not grab the device, as sharing a device between two
> drivers never works out well, no matter what abstraction you're using.
> 

Right.

> Step 2: Take a backup of your system, just in case (which you should be doing
> *anyhow* - neither spinning oxide disks nor flash-based drives are perfect).
> 

SSD here, I hope I don't destroy it :). But thanks for the advice.

> Step 3: Write the driver....

Sounds like a plan. 

If I had realized earlier about what I said in 'step 0' I could've
figured out why what I was trying to do wasn't working. Actually another
point I didn't pay attention was to the fact that i8042 is a PS/2
controller and not an USB one.. I'm using a USB keyboard attached to a
laptop which has the trackpad and keyboard as PS/2 devices, of course
things won't work.

Well, I'm sorry for that! But at same time thank you very much :)!

I think I'll be back soon, but hopefuly with better questions.

Thanks.

-- 
bmeneg 
PGP Key: http://bmeneg.com/pubkey.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170929/49f7896f/attachment-0001.bin 

Input device driver

[Greg KH]

On Fri, Sep 29, 2017 at 09:19:05PM -0300, Bruno E. O. Meneguele wrote:
> On 29-09, valdis.kletnieks at vt.edu wrote:
> > On Fri, 29 Sep 2017 19:38:49 -0300, "Bruno E. O. Meneguele" said:
> > 
> > > 2) I'm using a USB keyboard as the testing device, and TBH I got
> > > confused if I could actually use the input subsystem for that or I
> > > _should_ use HID instead (considering the keyboard is HID compliant).
> > 
> > Step 0: Decide if you're writing an interrupt handling driver, a USB driver, or
> > an HID driver - the three live at different levels of abstraction, and
> > confusing them will also confuse both you and your kernel.
> > 
> 
> I don't know why I didn't realize earlier the two counterparts:
> interruption vs USB, USB devices are handled in polling mode, not
> with IRQs.

It's not that simple.  USB devices only work when the host asks them for
data, so yes, that can be called "polling", but on the host (i.e. your
computer), IRQs are used to get the data from the USB host controller.
The USB driver is notified with the data from the mouse in IRQ context,
so you do have to be aware of IRQ issues when dealing with USB devices.

best of luck,

greg k-h

Input device driver

[Bruno E. O. Meneguele]

On 30-09, Greg KH wrote:
> On Fri, Sep 29, 2017 at 09:19:05PM -0300, Bruno E. O. Meneguele wrote:
> > On 29-09, valdis.kletnieks at vt.edu wrote:
> > > On Fri, 29 Sep 2017 19:38:49 -0300, "Bruno E. O. Meneguele" said:
> > > 
> > > > 2) I'm using a USB keyboard as the testing device, and TBH I got
> > > > confused if I could actually use the input subsystem for that or I
> > > > _should_ use HID instead (considering the keyboard is HID compliant).
> > > 
> > > Step 0: Decide if you're writing an interrupt handling driver, a USB driver, or
> > > an HID driver - the three live at different levels of abstraction, and
> > > confusing them will also confuse both you and your kernel.
> > > 
> > 
> > I don't know why I didn't realize earlier the two counterparts:
> > interruption vs USB, USB devices are handled in polling mode, not
> > with IRQs.
> 
> It's not that simple.  USB devices only work when the host asks them for
> data, so yes, that can be called "polling", but on the host (i.e. your
> computer), IRQs are used to get the data from the USB host controller.
> The USB driver is notified with the data from the mouse in IRQ context,
> so you do have to be aware of IRQ issues when dealing with USB devices.
> 

Ah ok, I understand. Considering I'm going to write an USB device now
I'll dive in LDD3 and other docs to better understand USB subsystem.

Thank you very much for this clarification gregkh. 

> best of luck,
> 

Thanks! :) I hope be back "soon" with some progress.

-- 
bmeneg 
PGP Key: http://bmeneg.com/pubkey.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170930/fd2b726a/attachment.bin