Hi Jiri, Benjamin,
> > So the solution consists in relying inconditionaly to the quirk MULTI_INPUT
> > for
> > hid-multitouch. Before registering the input device in hid-input, we can
> > test if
> > it has been populated, and if not, then we simply don't register it. In
> > order to
> >
Hi Jiri, Benjamin,
So the solution consists in relying inconditionaly to the quirk MULTI_INPUT
for
hid-multitouch. Before registering the input device in hid-input, we can
test if
it has been populated, and if not, then we simply don't register it. In
order to
prevent a
On Wed, 27 Feb 2013, Benjamin Tissoires wrote:
> So the solution consists in relying inconditionaly to the quirk MULTI_INPUT
> for
> hid-multitouch. Before registering the input device in hid-input, we can test
> if
> it has been populated, and if not, then we simply don't register it. In order
On Wed, 27 Feb 2013, Benjamin Tissoires wrote:
So the solution consists in relying inconditionaly to the quirk MULTI_INPUT
for
hid-multitouch. Before registering the input device in hid-input, we can test
if
it has been populated, and if not, then we simply don't register it. In order
to
Hi guys,
Here is the support of hybrid devices presenting pen and touch at the same time.
I don't think it's possible to split the handling of the different reports by
several hid drivers unless deepest changes in the HID core subsystem.
The main problem is the control of the underlaying
Hi guys,
Here is the support of hybrid devices presenting pen and touch at the same time.
I don't think it's possible to split the handling of the different reports by
several hid drivers unless deepest changes in the HID core subsystem.
The main problem is the control of the underlaying
6 matches
Mail list logo
