For pointer-emulating touches, no raw events are generated. Assume that raw events are handled like pointer events. Raw touch events are virtually identical to pointer/keyboard raw events and do not require specific handling. Note that due to the grab semantics, touch events may be submitted from the DIX with the client-ID as identifier. DDX touchpoints are separate from the DIX, so pointer emulation and other information is transferred via event flags. Otherwise, or if the device is a DependendTouch device, pointer emulation is disabled. Pointer emulation is decided on DDX touchpoint creation - if the touchpoint is the first one on the device pointer emulation is enabled. Once that's done, the (server-assigned) client ID is the only one that matters. The driver's touch ID is irrelevant outside the event generation code, it is only used for matching TouchUpdate/TouchEnd events to the matching touch points. Either must be unique but they are unlikely to ever be identical. Each DDX touchpoints has two touch IDs, the driver's touch ID and the protocol-visible client ID. These touchpoints are not affected by grabs, they begin on a driver-submitted TouchBegin and end on a driver-submitted TouchEnd event. DDX touchpoints are the equivalent to last.valuators. DDX TouchPointsĮach touch-capable device has a number of DDX touchpoints which represent the physical touchpoints as seen by the driver. This is the same process as for other input events.ĭrivers cannot generate TouchOwnership events, they are generated in the server only. During event processing time the events come out of the event queue, where they affect the logical state of the device and are sent to the clients. Driver events are usually submitted in a SIGIO handler, valuator data is converted into an InternalEvent ( DeviceEvent) and appended to the event queue. This is a wrapper around the DIX' GetTouchEvent()_ which is the main event generation function. The xfree86 input API has a single call for drivers to submit touch events: xf86PostTouchEvent(). Once a touchid is used for a XI_TouchEnd event, the driver can re-use it. Touch IDs must be new for XI_TouchBegin events and one of the currently used ones for XI_TouchUpdate or XI_TouchEnd events. Each touch event must have touch ID unique for the duration of the touch. Touch events can be submitted to the server with xf86PostTouchEvent(). For the actual valuators, the drivers should use the existing API xf86InitValuatorAxisStruct, just as they did before. The driver API consists of one new call to set up the device: InitTouchClassDeviceStruct. The reason is simple - if an event is replayed, we need to know that the original event was a touch event to make sure we deliver the right type to the next client. If a pointer-emulating touch should send pointer events, this conversion happens quite late and only for the wire protocol. Furthermore, the events the server deals with internally are always touch events. two touch device submitting their first event through the master, both will assume pointer emulation. This code has a few corner cases that will be buggy. Pointer emulation is decided on in the event generation code: if a new TouchBegin is submitted and no other emulating touchpoint is currently active, the new touchpoint becomes the emulating touchpoint. Pointer emulation is the most complicated part of the code since it needs to transparently work around pointer grabs in all three protocols (core, xi2, xi). Many of the terms used here will not make sense otherwise. In order to understand this text, you need to be familiar with the XI 2.2 protocol specification. Documentation may get out of date, assume that the final reference is always the code. This page describes the server internals of multitouch event processing for XI 2.2.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |