On Mon, Feb 25, 2013 at 4:44 PM, Nuno Santos <nsantos@xxxxxxxxxxx> wrote: > Hi Benjamin, > > From my understanding, with upstreamed you mean, putting the source on the > kernel tree. Yeah. > > In fact, I would love to have the driver on the kernel source but right now > we still rely on a internal lib for data processing and touch tracking which > we wont make it public. If it is ok to make an the upstream of this driver > accompanied with a static lib, we might consider that case. Definitively not ok. I don't think this kind of things are allowed. For the tracking, either forwards your events by following the multitouch protocol A, or use the already in-kernel tracker (see https://patchwork.kernel.org/patch/1395721/ ) > > We are working on complete standalone device that will make touch data > processing in place communicating via HID to the host. By that time that > driver will be on kernel source. If you are relying on HID for the communication, please use the standard Microsoft wrote: your device will be handled for free through hid-multitouch. I can give you some help with the protocol if you need. > > Regarding the questions arised, i'm happy and sad at the same time. Happy to > know that this is not a bug from the driver. Sad to know that this is an > Ubuntu problem due to their decisions. > > Thanks for the quick reply. You're welcome, Benjamin > On 02/25/2013 03:31 PM, Benjamin Tissoires wrote: >> >> Hi Nuno, >> >> On Mon, Feb 25, 2013 at 4:00 PM, Nuno Santos <nsantos@xxxxxxxxxxx> wrote: >>> >>> Hi, >>> >>> I have been experiencing an issue with a Linux driver for multitouch >>> input >>> that i'm responsible for maintaining. >> >> Side note. Your driver does not seems to be upstreamed (or I missed >> it). You should really consider put it upstream. If we make changes in >> the multitouch API, we can change your driver too, whereas here, you >> will have to maintain several releases of your driver, one per kernel >> version. >> >>> The issue is basically the following: >>> >>> - I load the driver and the mouse works just fine >>> - I touch the screen and the first touch input is delivered to the system >>> - On that very same moment I can't use mouse left button down to click on >>> folders on nautilus. I can only selected them using drag select. I also >>> can't get a folder to get selected with a single touch input. >>> - The user experience with the mouse gets inconsistent. >>> - Unloading the module doesn't return the good experience >>> - Restarting X fixes the problem until I report a touch input again with >>> this driver >>> - If I only use common pointer input, the issue doesn't occur. >>> >>> My questions resides in if the problem is due to bad touch reporting, or >>> due >>> to a bug in X/nautilus. >> >> Definitively X and nautilus problems. The very same kind of problems >> were observed in Fedora 17 and fixed in the X.org shipped in Fedora >> 18. >> >> Ubuntu is relying on an older X.org release, which contains several >> bugs related to multitouch. >> >>> I have been analyzing a lot of examples under kernel tree for multitouch >>> input under Linux an it seems I'm doing what is necessary. >>> >>> I'm using Ubuntu 12.04 but this happened with Ubuntu 11.XX already >> >> And in 12.10 also IIRC. I really hope that they will rebase X.org in >> 13.04. >> >>> This what I do in order to declare device capabilities: >>> >>> input_set_abs_params(input_dev, ABS_X, 0, 6300, 0, 0); >>> input_set_abs_params(input_dev, ABS_Y, 0, 6300, 0, 0); >>> >>> input_mt_init_slots(input_dev, DPX_TOUCH_MAX_COUNT); >> >> input_mt_init_slots has been changed recently, it takes an extra arg: >> 'flags'. >> >>> input_set_abs_params(input_dev, ABS_MT_POSITION_X, 0, 6300, 0, 0); >>> input_set_abs_params(input_dev, ABS_MT_POSITION_Y, 0, 6300, 0, 0); >> >> Not required IIRC. The params are copied from their single-touch >> equivalent. >> >>> This is what I do in order to report touches: >>> >>> for (currentTouch=0;currentTouch<DPX_TOUCH_MAX_COUNT && >>> touchCount<priv->context->State.Acquisition.TouchPoints;++currentTouch) >>> { >>> Touch = priv->context->State.Touches + currentTouch; >>> >>> x = Touch->CalibratedPoint.Position.X; >>> y = Touch->CalibratedPoint.Position.Y; >>> >>> input_mt_slot(usbtouch->input, currentTouch); >>> >>> // touch down >>> if(Touch->CurrentState==DPX_TOUCH_STATE_ACTIVE && >>> Touch->ReportedState==DPX_TOUCH_STATE_INACTIVE) >>> { >>> Touch->ReportedState = DPX_TOUCH_STATE_ACTIVE; >>> >>> input_mt_report_slot_state(usbtouch->input, MT_TOOL_FINGER, >>> 1); >>> >>> input_report_abs(usbtouch->input, ABS_MT_POSITION_X, x); >>> input_report_abs(usbtouch->input, ABS_MT_POSITION_Y, y); >>> >>> touchCount++; >>> } >>> // touch move >>> else if (Touch->CurrentState==DPX_TOUCH_STATE_ACTIVE && >>> Touch->ReportedState==DPX_TOUCH_STATE_ACTIVE) >>> { >>> Touch->ReportedState = DPX_TOUCH_STATE_ACTIVE; >>> >>> input_mt_report_slot_state(usbtouch->input, MT_TOOL_FINGER, >>> 1); >>> >>> input_report_abs(usbtouch->input, ABS_MT_POSITION_X, x); >>> input_report_abs(usbtouch->input, ABS_MT_POSITION_Y, y); >>> >>> touchCount++; >>> } >>> // touch up >>> else >>> { >>> Touch->ReportedState = DPX_TOUCH_STATE_INACTIVE; >>> >>> input_mt_report_slot_state(usbtouch->input, MT_TOOL_FINGER, >>> 0); >>> >>> input_report_abs(usbtouch->input, ABS_MT_POSITION_X, x); >>> input_report_abs(usbtouch->input, ABS_MT_POSITION_Y, y); >> >> No need to update ABS_MT_POSITION_X/Y in this case: they should not be >> sent to the user space according to the multitouch protocol. >> >>> touchCount++; >>> } >>> } >>> >>> if (touchCount>0) >> >> Looks like this test is always true. >> >>> { >>> input_mt_report_pointer_emulation(usbtouch->input, true); >> >> In the latest version of the kernel tree, you should rely on the >> input_mt_sync_frame() now. It will call >> input_mt_report_pointer_emulation() plus other things depending of the >> flags you passed to input_mt_init_slots(). >> >>> input_sync(usbtouch->input); >>> } >>> >>> >> Cheers, >> Benjamin >> -- >> 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 > > -- 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
