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. :-) Thanks, Henrik _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
