All of lore.kernel.org
 help / color / mirror / Atom feed
From: Henrik Rydberg <rydberg@euromail.se>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jiri Kosina <jkosina@suse.cz>,
	Mika Kuoppala <mika.kuoppala@nokia.com>,
	Benjamin Tissoires <tissoire@cena.fr>,
	Rafi Rubin <rafi@seas.upenn.edu>
Subject: Re: [PATCH 0/3] input: evdev: Dynamic buffers (rev4)
Date: Tue, 15 Jun 2010 11:43:13 +0200	[thread overview]
Message-ID: <4C174B31.6040403@euromail.se> (raw)
In-Reply-To: <201006101211.51395.dmitry.torokhov@gmail.com>

Dmitry Torokhov wrote:
> On Saturday, June 05, 2010 04:04:26 am Henrik Rydberg wrote:
>> Dmitry,
>>
>> Please find enclosed the fourth version of the evdev buffer patches.
>>
>> This version implements buffer locking using event_lock as you
>> suggested, such that we can proceed with fixing the evdev buffer
>> problem independently from providing a suitable one-to-many buffer.
>>
>> The first patch converts the per-client buffers to a common buffer,
>> and adds a fixme since the code is expected to be further
>> improved. The second and third patch includes your review comments.
> 
> Henrik,
> 
> Applied to .36 queue with minor adjustments, please take a peek in my
> 'for-linus' branch and see if you spot anything wrong.

We are talking about your tree @kernel.org, right? Nothing appeared there...

> The changes have
> been made with an eye of implementing a per-client event filters which
> would again require using private event queues (but only by clients that
> request filtering).

Would not having the separate reader tails suffice? Implementing the filtering
during client read?

> The desire for allowing event filtering in kernel is to avoid waking up
> HAL-ish processes (ones that only interested in certain special events, 
> like KEY_SUSPEND, KEY_WIFI, KEY_MUTE, etc) needlessly. Not sure if I am
> going to have time to actually implement it though, anyone wants to
> take a stab?

I see. Something like a lovely new ioctl() command, setting the evbits on a per
client basis?

Henrik


  reply	other threads:[~2010-06-15  9:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-05 11:04 [PATCH 0/3] input: evdev: Dynamic buffers (rev4) Henrik Rydberg
2010-06-05 11:04 ` [PATCH 1/3] input: evdev: Use multi-reader buffer to save space (rev4) Henrik Rydberg
2010-06-05 11:04   ` [PATCH 2/3] input: evdev: Convert to dynamic event buffer (rev4) Henrik Rydberg
2010-06-05 11:04     ` [PATCH 3/3] input: Use driver hint to compute the evdev buffer size (rev2) Henrik Rydberg
2010-06-10 14:21 ` [PATCH 0/3] input: evdev: Dynamic buffers (rev4) Chase Douglas
2010-06-10 19:11 ` Dmitry Torokhov
2010-06-15  9:43   ` Henrik Rydberg [this message]
2010-06-16 20:34     ` Dmitry Torokhov
2010-06-16 14:46   ` Jiri Kosina
2010-06-16 16:17     ` Henrik Rydberg
2010-06-16 20:31       ` 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=4C174B31.6040403@euromail.se \
    --to=rydberg@euromail.se \
    --cc=dmitry.torokhov@gmail.com \
    --cc=jkosina@suse.cz \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.kuoppala@nokia.com \
    --cc=rafi@seas.upenn.edu \
    --cc=tissoire@cena.fr \
    /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.