All of lore.kernel.org
 help / color / mirror / Atom feed
From: bmeneguele@gmail.com (Bruno E. O. Meneguele)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Input device driver
Date: Fri, 29 Sep 2017 21:19:05 -0300	[thread overview]
Message-ID: <20170930001905.GA9452@glitch> (raw)
In-Reply-To: <45189.1506726543@turing-police.cc.vt.edu>

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 

  reply	other threads:[~2017-09-30  0:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-29 22:38 Input device driver Bruno E. O. Meneguele
2017-09-29 23:09 ` valdis.kletnieks at vt.edu
2017-09-30  0:19   ` Bruno E. O. Meneguele [this message]
2017-09-30  7:42     ` Greg KH
2017-09-30 12:05       ` Bruno E. O. Meneguele

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170930001905.GA9452@glitch \
    --to=bmeneguele@gmail.com \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.