Input Server (standalane like pulseaudio, cups, xfs)

[kuranes]

Isn't there any sort of input driver in X ?
That can accept network input, multiple drivers, etc ?
Is it mandatory to be to stied with X ?

PulseAudio, Xfs, Cups are all standalone server, that can be networked, so It's strange input isn't ?

(I already use Synergy to share input, and it being another lyer doens't help speed/latency/responsivness.)

I have many computer, but one RSI free mouse (wowpen), a media server, a eee pc... and all in all I would like to be able to share input from one to another.

network input, mutliple input, multiple drivers (touch, wiimouote, keyboard (complex languages handling), mouses, joysticks, pads, webcam gestures, gestures libs, etc...

I wonder if it doesn't exists already, why not and where would be agreat place to start/discuss project, gather people and all ?

[elanthis]

The first thing for you to do is actually come up with a reason why an entire separate server process is needed for what you want, instead of the existing hotplug input support and its upcoming additions.

[kuranes]

All reasons that mades pulseaudio/xfs being separate server ? Sharing resources among network/application with cleanest KISS design possible.

1/ Network sharing of just input on its own, as it synergy downloads counts attests. withtout the latency induced by being slave of X server. (input needs the less latency possible).

2/ putting input server aside from graphic server (xorg, X, FB, etc) would help sharing the work on all linux programs, not just Xorg. (and as linux is very embedded device prone, it means a lot.) Just look at how wiimote was used on linux... X hoptlug driver ? no. c libraries... so every application wanting to use it has to create a specific version...

3/ Clear separation means better and cleaner sources both for Xorg and input code, letting external contributor able to plug any sort of input more flawlessly (no need to understand whole X architecture), therefore perhaps more contributors too. and as Input is a very hot top?c now, (search opencv multitouch webcam wiimote gesture recognition on youtube...) that would give many student that doesn't feel confident to dive in X sources, the chance to try something.


4/ Dedicated commuty/project that woul help opensource bazzaar interaction.

5/ its own scheme of server update/upgrade, not having to wait Xorg next release.

[elanthis]

All reasons that mades pulseaudio/xfs being separate server ? Sharing resources among network/application with cleanest KISS design possible.

xfs is essentially dead. pulseaudio isn't a "separate server" from anything -- it's supposed to be the one and only server you run for audio. and then only because putting all of its logic into the kernel is considered just as bad of an idea as putting all of X into the kernel would be.

1/ Network sharing of just input on its own, as it synergy downloads counts attests. withtout the latency induced by being slave of X server. (input needs the less latency possible).

Who needs network sharing of input? I've never once heard of anybody wanting that without also wanting a display for each input, which is exactly what networked X can provide right now.

Your latency stuff makes no sense whatsoever. Maybe you're just not explaining it well enough (no offense, but your English is not so great).

2/ putting input server aside from graphic server (xorg, X, FB, etc) would help sharing the work on all linux programs, not just Xorg. (and as linux is very embedded device prone, it means a lot.)

Not following. If you're talking about better use of multiple cores, there's already an input thread project for X to help separate it from the drawing code. Maybe that'll help with whatever latency concerns you have, too.

Just look at how wiimote was used on linux... X hoptlug driver ? no. c libraries... so every application wanting to use it has to create a specific version...

That makes no sense. If it's a C library, why would apps need to make separate versions? And why couldn't X just use that library to expose the Wiimote as an X input driver? Maybe it just wasn't possible due to the limited feature set of X input drivers, but that's being solved right now. X.org 1.6 is supposed to have extended properties, and 1.7 should have MPX and other input enhancements.

3/ Clear separation means better and cleaner sources both for Xorg and input code, letting external contributor able to plug any sort of input more flawlessly (no need to understand whole X architecture), therefore perhaps more contributors too.

So instead of having to learn the X architecture, they have to learn some arbitrary input server architecture. Either way, they have to learn something. The X architecture doesn't require users to know how to program graphics drivers in order to write input drivers, either, btw.

4/ Dedicated commuty/project that woul help opensource bazzaar interaction.

You mean a split community with artificial barriers, because now someone has to create logins, mailing list accounts, etc. for two totally separate projects where before they needed only one.

5/ its own scheme of server update/upgrade, not having to wait Xorg next release.

Instead of waiting for X, you'd have to wait for the input server updates. Either way, you have to wait. Keep in mind that it's not like the new X input code has been ready to go and just waiting on an X release -- the X releases are having to drop the new input code because it's not ready yet. You're talking about a problem that doesn't actually exist.

[kuranes]

pulseaudio isn't a "separate server" from anything -- it's supposed to be the one and only server you run for audio. and then only because putting all of its logic into the kernel is considered just as bad of an idea as putting all of X into the kernel would be.

Why that wouldn't be the same for input ?

Who needs network sharing of input?

At least users with multiple computers on their desk since each system uses its own monitor(s). (programmers, sysadmins, etc...)
(check Synergy sourceforge page (http://synergy2.sourceforge.net/) , it's 4000 downloads a day... not counting others site/distrubtion schemes.)

Your latency stuff makes no sense whatsoever.

Each layer of software add latency between input movement and any response. (may be it visual or not). "Hardware Cursor" is the answer to better responsivness, but less code between input driver and cursor move implies better responsivness, not speaking of eaiser code profiling/optimisations.

(no offense, but your English is not so great)

Thanks for reading/responding even if I'm not clear enough.

there's already an input thread project for X to help separate it from the drawing code. Maybe that'll help with whatever latency concerns you have, too.

That's great and would have been a side benefit of standalone server (more multicore friendly).

But I was speaking all non-X based programs here, that could have access to all input drivers that are only available to X programs for now. Pure Console, DirectFB, etc...
So X abstraction would be interesting I think... and why not OS abstraction.(like pulse audio is trying to do)

If it's a C library, why would apps need to make separate versions?

I was meaning that Each App has to integrate that library, recompiles against it at each new version and so on.

And why couldn't X just use that library to expose the Wiimote as an X input driver

That was my point.
If despite the big buzz on wiimote linux, no X input driver attempts wasn't even tried... That is a sign of the existance a "complexity barrier" in having to dive into X code (build system barrier, code complexity barrier, documentation size, etc...).
I can tell that only the "build system" barrier is enough to stop people trying/writing code.

Idea is the simpler, the better, and standalone input server is simpler to diver than X code.

You mean a split community with artificial barriers, because now someone has to create logins, mailing list accounts, etc. for two totally separate projects where before they needed only one.

That's a minimal price of specialization.
People only interested in input, won't have to follow the enourmous X community traffic.

Instead of waiting for X, you'd have to wait for the input server updates....You're talking about a problem that doesn't actually exist.

Having two separate project cannot give more wait, on the contrary, it can give only less.
Having more flexibility cannot be seen negatively, specially if the goal of separate community/code/architecture is to get more dynamic evolutions...

[elanthis]

Each layer of software add latency between input movement and any response.

This is the biggest reason why an input server sounds silly to me. You're asking to have MORE layers, not less.

But I was speaking all non-X based programs here, that could have access to all input drivers that are only available to X programs for now. Pure Console, DirectFB, etc...

Well, technically, I think that's what X is moving towards anyway. Putting all the input event detection into the kernel, keeping device enumeration in hal, and then letting X mostly just deal with dispatching events and organizing application handling of input.

I was meaning that Each App has to integrate that library, recompiles against it at each new version and so on.

It probably just needs to be integrated into the kernel and X. I'm willing to bet it's a separate library more because it's just a quick, dirty hack, rather than some real need to be separate from X. Reading up on it quickly, it sounds like it just needs a small specialized kernel driver, as it claims to be a HID-compliant device but isn't; blacklist it from the HID driver and add in a small driver to convert Wiimote events to something compatible, and you'd probably be in business.

That is a sign of the existance a "complexity barrier" in having to dive into X code (build system barrier, code complexity barrier, documentation size, etc...).

It could mean any of a number of things, including quite simply that nobody actually even bothered to try. Instead of making assumptions, it would be better to get a statement from the actual developers themselves. Their reasoning for not making an X driver could be something as simple as "we're not ready for it yet, we're still working on getting a fully functional prototype working, including a kernel driver."