public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dtor@insightbb.com>
To: "Magnus Vigerlöf" <wigge@bigfoot.com>
Cc: linux-input@atrey.karlin.mff.cuni.cz, linux-kernel@vger.kernel.org
Subject: Re: [RFC] input: Wacom tablet driver for simple X hotplugging
Date: Sun, 23 Jul 2006 01:24:55 -0400	[thread overview]
Message-ID: <200607230124.56094.dtor@insightbb.com> (raw)
In-Reply-To: <200607221200.51700.wigge@bigfoot.com>

On Saturday 22 July 2006 06:00, Magnus Vigerlöf wrote:
> On Saturday 22 July 2006 04:09, Dmitry Torokhov wrote:
> >
> > I do not think that creating device-specific "drivers" is a good idea
> > even short term, especially in kernel. If you want a "persistent"
> > device just create a userspace daemon and listen for hotplug events.
> > When you see the input device you interested in grab it and pipe all
> > data into somewhere. Next time you see hotplug event for the same
> > device release the old instance and grab the new one. In cases when
> > final recepient of events uses ioctls to query input devices capabilities
> > you can create uinput feed back into kernel. This way your program will
> > work for all types of input devices and no kernel changes are needed.
> 
> Creating userspace device drivers is something new for me. If you have some 
> pointers to information about it I would be grateful (I've found the FUSD 
> framework through google). From what I can read from the doc of FUSD, I'll 
> have to open the inputX device if I want events from the tablet to propagate, 
> and I'm afraid I might hit the oops in evdev I described in my previous 
> thread if I do that.
> 

No, I was not talking about FUSD, just uinput driver that is in kernel
proper. Take a look at this:

	http://svn.navi.cx/misc/trunk/inputpipe/

It allows making input devices "network-transparent" and for example
use joystick physically connected to one box to play game on another.
Hmm, actually it is almost what you need, you just need modify server
to multiplex events into single device instead of creating separate
input devices.

> So.. Are the locking issues in evdev something that is about to be fixed soon 
> or should I contribute? Or do you think the issue will be completely 
> irrelevant for a user-space driver?
> 

No, I think you will still have the same issues with locking, unfortunately
I can't commint on a specific date when they will be resolved. Patches are
always welcome of course.

-- 
Dmitry

  reply	other threads:[~2006-07-23  5:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-21 21:13 [RFC] input: Wacom tablet driver for simple X hotplugging Magnus  Vigerlöf
2006-07-22  2:09 ` Dmitry Torokhov
2006-07-22 10:00   ` Magnus Vigerlöf
2006-07-23  5:24     ` Dmitry Torokhov [this message]
2006-07-24 16:28       ` Magnus Vigerlöf
2006-07-25 18:00         ` Zephaniah E. Hull
2006-07-24 15:11   ` Daniel Stone
2006-07-24 15:22     ` Dmitry Torokhov
2006-07-24 15:23     ` Odd values in /proc Damien Pacaud
2006-07-25 19:56       ` Jan Engelhardt
2006-07-25 19:06 ` [RFC] input: Wacom tablet driver for simple X hotplugging Andrew Morton
2006-07-29 23:45   ` Magnus Vigerlöf

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=200607230124.56094.dtor@insightbb.com \
    --to=dtor@insightbb.com \
    --cc=linux-input@atrey.karlin.mff.cuni.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wigge@bigfoot.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox