On Saturday 22 July 2006 04:09, Dmitry Torokhov wrote:
> Hi Magnus,
>
> On Friday 21 July 2006 17:13, Magnus Vigerlöf wrote:
> > I'd appreciate whether you think this is a viable idea to make it as a
> > generic driver instead or should I continue with the Wacom-specific
> > one. I know the 'right' thing would be to make X truly hot-plug aware,
> > but this driver is something that would be possible to use in current
> > systems without any problems.
>
> Yes, I think fixing X would ultimately be time better spent.
As a long term fix, I'll consider getting involved with that.. However, I'd
like to have something that works with my current setup, hence the..
temporary driver... Ok, I'm still going to use it as it solves one bad and
one annoying thing I have with my Wacom tablet, but I'll keep it outside the
kernel while better ways to solve this are made.
> > If it is a viable idea; Which other devices/types of device do you
> > think could be of interest to handle in a similar fashion? Tablets of
> > different makes/models are obvious, but are there any others that
> > would benefit from a similar driver?
>
> 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.
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?
Thanks
Magnus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
