On Wed, Jul 07, 2010 at 06:54:17AM +0200, Henrik Rydberg wrote: > Peter Hutterer wrote: > > On Tue, Jul 06, 2010 at 08:29:34AM +0200, Henrik Rydberg wrote: > >> Peter Hutterer wrote: > >>> On Sat, Jul 03, 2010 at 01:10:24AM -0400, Rafi Rubin wrote: > >>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>> Hash: SHA1 > >>>> > >>>> On 07/02/10 05:59, Henrik Rydberg wrote: > >>>>> Peter Hutterer wrote: > >>>>> [...] > >>>>>> It'd be interesting to see how much work it is to have this API > >>>>>> _replace_ the current API. Gives us more exposure and better testing. > >>>>>> Note that I have some more API changes planned (not coded) that > >>>>>> simplify > >>>>>> the init process, they should all go in in one go. > >>>>>> Another change that goes with that is the ability to easily split up > >>>>>> devices into multiple X devices. This would make it easier to handle > >>>>>> devices that have both MT events and normal events - they would simply > >>>>>> end up being two devices, one normal one, one DID. > >>>>>> > >>>>>> Henrik, Rafi - do you think this would work for the MT devices we've > >>>>>> seen so far? > >>>>> From a device perspective, absolutely. In the kernel, a single device > >>>>> can have > >>>>> any combinations of BTN, ABS, and MT events. Keys are getting there as > >>>>> well, but > >>>>> are still normally separated by force. In other words, trusting the > >>>>> kernel to > >>>>> make a logical split of events which fits the X framework is not very > >>>>> fruitful. > >>>>> > >>>>> Going forward, I wonder why we split input into separate devices at > >>>>> all. We have > >>>>> different types, and different behavior based on capabilities, but > >>>>> input is > >>>>> becoming so intermixed that the notion of separated devices looses its > >>>>> meaning. > >>>>> Why not just put all input events into the same bucket, and let clients > >>>>> specify > >>>>> what event types to listen to? > >>>> I agree, I don't see the need to artificially separate keyboards and > >>>> pointers. > >>> say hello to my friend the core protocol. approximately 100% of all > >>> applications rely on it (rounded to the nearest percent) :) > >>> who needs enemies if you got friends like this. > >>> > >>> fwiw, about a year ago I had a private branch that gets rid of the > >>> pointer/keyboard distinction and provide a unified master device that's > >>> both > >>> pointer and keyboard. that didn't turn out well, grab synchronization is a > >>> nightmare. > >> I will take your word for it, but it does sound like there is not much of a > >> resistance against the idea. :-) > > > > I can give you the branch if you're really interested but it didn't get > > further than a lot of search/replace of inputInfo.pointer and > > inputInfo.keyboard. When I started sorting out how a single master device > > may be grabbed sync on the keyboard but async on the pointer with different > > replaying order or sync/async swapping I gave up. > > > > Branch date's back to march 2009, so it's a bit out of date. > > Oh, that would be nice. Not saying I would do anything with it, but I am > curious. :-)
people.freedesktop.org/~whot/xserver.git single-master-device don't expect too much ;) Cheers, Peter _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
