On Tue, 2009-01-13 at 22:37 +1000, Peter Hutterer wrote: > The idea here was to be able to filter easily. I expect that many clients > won't care much about reattachment, but they would care about new MDs. > Having this information may prove useful. As for the deviceids - same idea.
I guess this kinda depends on how we expect to implement things on the client side. If we want to mirror the server device hierarchy in the client library, it might be easier to just take the 'something changed' event and reconstruct the whole client state than attempt to patch things with incremental data. Dunno. > Not having this state makes us prone for race conditions. Class changes are > expected to happen often, and a different XDCE may be generated while the > request is waiting to be processed. In this case, the client cannot process > events with the correct axis information. > At least for XDCE, it is mandatory that the new information is part of the > event. XDHCE is less frequent, justifying the query. Less frequent doesn't mean non-racy though; we've had this problem with X key mapping forever, and worse now that keymap notify events are happening more often. > > Send these in floating point so we capture sub-pixel positions > > trivially? > > ok. Or perhaps fixed point? That eliminates problems with different precision in different parts of the screen. > > Uh. What about absolute devices? Can those send XRelativeMotionEvents? > > If so, this seems more like an XIDeviceRawEvent. > > (same comments about last_* apply here) > > Good point. I will revise. Oh, are these INT32 here (for relative devices)? And, if so, do we use INT32 in the non-raw event for consistency? > I don't have an answer for all that yet and it strikes me as one of those > things that just need testing to see what works best. Ok, sounds like we need to figure out how grabs work for devices which are both pointer and keyboard then. I can't, frankly, think of a better way than having them appear as two logical SDs. Which leaves us with slightly weird event delivery, but that seems better than complicated grab semantics? > The main point of input classes in XI2 would be to specifiy capabilities in > detail. Some of the input classes aren't particularly great for that so they > could do with a redesign. Example here is the ValuatorInfo that only allows > for a single state across all axes. With the above discussion, it seems like SDs are either 'pointer' or 'keyboard' devices, and beyond that, they've got a collection of keys or buttons/axes. Making sure the per-axis information isn't constrained by some global device information seems like a requirement here. > Current deviceids are CARD8, so CARD32 would still require a reimplementation. > Now, at least for XI2 this may not be a problem as we could decide the upper > 24 bit as "reserved for future use" and continue to only use 8 bits in > requests and replies - until those are reimplemented at a later point in time. I guess I don't see any huge 're-implementation' here -- you're just widening a data type. It may cause a flag-day for input devices, but we've been there before. > 16 bit ids were chosen mainly because the fit nicely after the event type in > the GenericEvent. Before we run out of 2^16 deviceids per X server, we run > into other issues anyway. Ok, seems fairly reasonable. > XI valuators are already 32 bits, and we probably shouldn't scale down. > we accept integer-only format in the valuator Right, so we use 16.16 fixed point for their screen coordinates then and get plenty of sub-pixel position. > Another thing discussed briefly was the use of a separate format internal to > the server, i.e. the XI events are assembled at delivery time, not carried > through the server. This is an implementation detail though and shouldn't be > too hard to support. Hmm. With the generic event stuff fixing the list-of-events disaster, is there some other format you'd prefer? Adding a gratuitous data type doesn't seem like a winning plan here. -- keith.pack...@intel.com
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg