On Tue, Jun 15, 2010 at 11:43:13AM +0200, Henrik Rydberg wrote: > 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... > Right, haven't actually pushed yet, queued e-mail leakage ;) > > 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? No, because that would cause waking up the reader thread, which is the whole goal of the change. > > > 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? Yep, exactly. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
