Peter Hutterer wrote: [...] >>> Will all drivers with ABS_MT_TRACKING_ID use slots? if not, how can I know >>> in advance if a device may use slots or not? >> Eventually, this might become true, but you are pointing at one of the weaker >> points of the current setup. There is no bit field for the EV_SYN events, so >> there is no way to know in advance if SYN_MT_SYNC or SYN_MT_SLOT is used. This >> could quite possibly be added to the EVIO interface. Meanwhile, the method I use >> is to detect the first SYN_MT_SLOT and select parser based on that information. > > I'd really prefer if there was some way to detect this. While I'm not quite > sure how the matching X drivers would look like it's likely that the setups > will be different for drivers that support slots and those that don't. > e.g. those that don't have slots simply send events as valuators, those that > do may split into multiple devices. > > Doing this at runtime - after the device has been set up is...tricky. Changing SYN_MT_SLOT to ABS_MT_SLOT will take care of this. >> If you are thinking of a setup where one program is already hooked up to the >> device, and a new one comes in just as the message in question appears on the >> wire, it just means the new program will have to spend some time catching up. If >> this should ever become a problem, one could possibly add a send-full-state >> method to the input layer, to be issued when the new program opens the device. I >> doubt this will be needed in practice though, since contacts change all the time. > > This was the case I was wondering about. While I agree with the last part > (contacts change all the time) the side-effect that you'll get from this is > that devices can seemingly be non-responsive for random periods of time. > > If you have a finger down when the X server starts or after a VT switch (or > even a fast user switch), the driver will have to drop events. So you can > wriggle your finger around and nothing happens, but once you lift it goes > "well, now it works again". Since this happens only once in a while, it can > make the whole lot appear flaky. Especially if one finger works and the > other one doesn't. > > So I guess it comes down to whether sending SYN_MT_SLOT with every event > costs too much compared to these admittedly rare use-cases. They're not much > different to the current button events either, if you weren't there when a > button was pressed you won't know. So I'm somewhat indifferent about this > bit. Yes, it is a inherent property of the input protocol between the kernel and user space. A different problem, in other words. > And yes, you could add it once we find it's an issue, but by then someone > has already spent time to work around this. And when you then start sending > slot events all the time, you admit that writing the workaround was just a > time waster :) Work around what, exactly? >> As a side note, the notion of a used slot depends on how the attributes of the >> slot are interpreted. The method described in the document treats an >> ABS_MT_TRACKING_ID value outside of the driver-specified value range as an >> unused slot. > > It's easier for a latecomer to guess a tracking ID since you can just > assign any random value to it, provided the kernel guarantees to only send > updates on the tracking ID for changes. This doesn't quite work for slots. > > But I'm not sure what your last sentence means. Does this mean the kernel > will open a new slot for out-of-range tracking IDs? I'm missing something > here. I am referring to the notion of create-move-destroy from earlier discussions, and the question of how it is implemented using slots. The document is a bit unclear on this point, so I will add a note stating something like this: * Every slot with a tracking id within the value range represents a contact. * Tracking ids not previously present are considered new. * Tracking ids no longer present are considered removed. Cheers, Henrik -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
