Re: Input device driver
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.kletni...@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 signature.asc Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Input device driver
On Fri, Sep 29, 2017 at 09:19:05PM -0300, Bruno E. O. Meneguele wrote: > On 29-09, valdis.kletni...@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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Input device driver
On 29-09, valdis.kletni...@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 signature.asc Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Input device driver
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 pgpHwM1msjXVB.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Input device driver
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: 5500 0 IR-IO-APIC 2-edge timer 1: 10157 2 IR-IO-APIC 1-edge i8042 8:000 1 IR-IO-APIC 8-edge rtc0 9: 7216 3565165173485 IR-IO-APIC 9-fasteoi acpi 12: 212 29 323 51 IR-IO-APIC 12-edge i8042 16: 000 0 IR-IO-APIC 16-fasteoi i801_smbus 19: 1506 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 signature.asc Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
