LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Dmitry Torokhov" <dmitry.torokhov@gmail.com>
To: "Ryan Lortie" <desrt@desrt.ca>
Cc: "Zephaniah E. Hull" <warp@aehallh.com>,
	linux-kernel@vger.kernel.org, "Vojtech Pavlik" <vojtech@suse.cz>,
	linux-input <linux-input@atrey.karlin.mff.cuni.cz>
Subject: Re: [PATCH] Input: Support for a less exclusive grab.
Date: Tue, 23 Oct 2007 14:10:58 -0400	[thread overview]
Message-ID: <d120d5000710231110u79ea11a8p38f1fc4654a7fac2@mail.gmail.com> (raw)
In-Reply-To: <1193155059.15426.15.camel@moonpix.desrt.ca>

On 10/23/07, Ryan Lortie <desrt@desrt.ca> wrote:
> On Tue, 2007-23-10 at 09:21 -0400, Dmitry Torokhov wrote:
> > Priority/filter idea is different matter. I don't think it is a giood
> > solution. There will always be an "arms race", new applications would
> > like to get in front of the queue all the time and it will be hard to
> > manage. X should just keep console open in raw mode and simply ignore
> > all events coming from it while using evdev driver. I understand that
> > X's hotplug support is getting there so you should be able to switch
> > to pure evdev setup pretty easy.
>
> The only reason that I don't like the numeric priority system is that I
> believe it is arbitrary and a bit kludgy.  I don't think an arms race
> will be a problem.  We don't have a lot of closed source applications
> running as root on Linux and open source projects either choose sane
> values or get patched (by users, distributions, etc) or don't get used.
>
> I do believe there needs to be some concept of filtering events in such
> a way that they reach some clients but not others -- that's half of the
> purpose of this thread.  rfkill wants to be able to see keypresses while
> they are kept away from X.

No, rfkill want to see keypresses, period. It does not care if there
are other applications also seeing the same keypresses, it just does
not want keypresses stolen from it.

Rfkill should work just fine if there is a debug application capturing
events or a OSD utility monitoring RF state. Actually it would be
great if amy of the control utililities were split in 2 parts - one is
daemon running even without X and controlling RF starte, brightness,
suspend, etc, etc, and another part running in X (or some other
environment) providing OSD services. I mean it is really annoying when
you realize you can't suspend witha keypress because you happen to be
a KDM promot and not fully logged into a KDE session...

>  I'd be open to another way of handling this
> but I think any other way will necessarily be more complex to use.
>
> As for X using evdev, it still puts you in a position of two pieces of
> software being required to know what events have been (conceptually)
> "filtered" by various filters running on the system.  ie: the filter
> itself needs to know, and also X needs to know so that it can remove
> those key events from normal delivery.
>

Yes, applications need to decide whether they want to process certain
events or not. But I think that they shodul do it for themselves, not
for other applications. Otherwise dependencies are just insane and you
risk to disturb the peace just by adding another piece in the mix.

-- 
Dmitry

  reply	other threads:[~2007-10-23 18:11 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-09  8:48 Zephaniah E. Hull
2007-06-12  5:07 ` Dmitry Torokhov
2007-06-12  5:12   ` Zephaniah E. Hull
2007-06-12  5:19     ` Dmitry Torokhov
2007-06-12  5:23       ` Zephaniah E. Hull
2007-06-12  5:35         ` Dmitry Torokhov
2007-06-12  5:40           ` Zephaniah E. Hull
2007-07-02 15:20             ` Vojtech Pavlik
2007-07-03 16:45               ` Zephaniah E. Hull
2007-07-03 22:15                 ` Vojtech Pavlik
2007-09-29  3:05                 ` Ryan Lortie
2007-10-23 13:21                   ` Dmitry Torokhov
2007-10-23 15:57                     ` Ryan Lortie
2007-10-23 18:10                       ` Dmitry Torokhov [this message]
2007-10-24  1:58                         ` Ryan Lortie
2007-10-24  3:33                           ` Dmitry Torokhov
2007-10-24 15:35                             ` Zephaniah E. Hull
2007-10-25  5:37                               ` Ryan Lortie
2007-10-26 16:44                                 ` Zephaniah E. Hull
2007-10-26 17:16                                   ` Ryan Lortie
2007-10-26 17:58                                     ` Zephaniah E. Hull
2007-10-26 17:29                                   ` 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=d120d5000710231110u79ea11a8p38f1fc4654a7fac2@mail.gmail.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=desrt@desrt.ca \
    --cc=linux-input@atrey.karlin.mff.cuni.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vojtech@suse.cz \
    --cc=warp@aehallh.com \
    --subject='Re: [PATCH] Input: Support for a less exclusive grab.' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).