All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maurus Cuelenaere <mcuelenaere@gmail.com>
To: Henrik Rydberg <rydberg@euromail.se>
Cc: linux-input@vger.kernel.org, Dmitry Torokhov <dmitry.torokhov@gmail.com>
Subject: Re: [RFC] Microsoft Touch Mouse driver [was: Re: your mail]
Date: Tue, 07 Feb 2012 22:09:08 +0100	[thread overview]
Message-ID: <4F3192F4.1040401@gmail.com> (raw)
In-Reply-To: <20120207161231.GA13128@polaris.bitmath.org>

Op 07-02-12 17:12, Henrik Rydberg schreef:
>> Ok, so it's pretty clear the consensus is that there should be a
>> different interface to push the data to user space.
>> My initial reaction is V4L, as the data is basically a stream of
>> monochrome frames, this kind of fits the video description. Also,
>> this could be of some benefit to all those
>> emulate-multi-touch-using-webcam projects.
> On the other hand, your device, and the ones to come, are likely not
> normal ccd cameras, and the interface is bound to be different; you
> would most likely prefer the stream to be silent when there are no
> touches, for instance, and only generate interrupts or new-data events
> as there is something to react to.

True, I had forgotten about that. There are no HID packets sent when 
nothing touches the surface and the CPU shouldn't needlessly spent 
cycles on parsing an empty stream.

>> Other options I see are mmap on the input device, creating a
>> separate (char?) device, UIO or even having the whole thing in
>> userspace.
> Personally, I think mmapped input devices would be a great extension
> to the input subsystem. I am thinking event types distributed in a 2D
> plane, maybe one node per type, and signalled by normal input events
> of the data-to-read type.

Ok, I'll look into that!

>> However, there's one tiny hack I'd like to have and I'm unsure
>> whether this can be done from userspace: as the mouse has only one
>> physical push button, it can't distinguish between left, middle or
>> right click.
>> Obviously, it can do this based on the information it gathers from
>> its touch surface, however the firmware has only the following dumb
>> implementation: when only one finger is present on the right part of
>> the surface, assume right click; otherwise assume left click. This
>> means that you need to lift your left finger when performing a right
>> click.
>>
>> Now, the receiver is represented as 3 HID devices: one keyboard
>> descriptor, one mouse descriptor and one miscellaneous/control
>> descriptor (containing touch surface data). My plan was to intercept
>> mouse clicks on the mouse descriptor and look at what part of touch
>> surface (left/right) has the most pressure and, if needed, swap the
>> click to a right click.
>>
>> Any hints on how to do this in userspace? Of course I could hack up
>> xf86-input-evdev, but I'd like to do this at the highest possible
>> layer, ie the input subsystem.
> The application you describe could well be implemented in the driver
> you submitted; a simple handling of the MT data resulting in normal
> input events.

Yes, that was my initial idea. But as I had the impression that an 
userspace solution was preferred, I wondered how to solve that.

-- 
Maurus Cuelenaere


  reply	other threads:[~2012-02-07 21:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <BROWNM3h3vLgAusVxON00000cfa@brown.emailprod.vodafone.se>
2012-01-25 13:26 ` your mail Henrik Rydberg
2012-01-25 14:09   ` Maurus Cuelenaere
2012-01-25 14:13     ` Fwd: " Maurus Cuelenaere
2012-01-25 15:00     ` [RFC] Microsoft Touch Mouse driver [was: Re: your mail] Henrik Rydberg
2012-01-29 21:19       ` Maurus Cuelenaere
2012-01-30  7:27       ` Dmitry Torokhov
2012-02-07 12:07         ` Maurus Cuelenaere
2012-02-07 16:12           ` Henrik Rydberg
2012-02-07 21:09             ` Maurus Cuelenaere [this message]
2012-02-07 22:38               ` Henrik Rydberg
2012-02-08 17:09                 ` Dmitry Torokhov

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=4F3192F4.1040401@gmail.com \
    --to=mcuelenaere@gmail.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=rydberg@euromail.se \
    /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.