Hi Benjamin,

quoted

I can think of two mechanisms that might be useful in finding a
way to achieve this cleanly: a) Let a driver return a value telling
whether to change input device, and b) Let a second driver have a go
at the same device report. Some return value or state could determine
logic in the hid core saying "we are not done with this device, try
another driver". Or something. Just not this way, please.

Hi Henrik,

ok for the implementation of this patch series, it has to be reworked.

As for your proposals:

a) We can not rely on input_mapping because there is a temporal issue:
we already want to have the new input when we are in input_mapping.
So, this implies to create a new callback.

b) This would implies just too much work in hid-core for taking into
account a special case of one type of devices.

I may look like a special case, but perhaps it is not. Routing
different sensors to different drivers is what we do all the time, but
we call that the device-driver bus model. To fit into that concept, we
would need to split the sensors into separate devices first, then
apply the driver logic onto those devices. Thus, the problem is not
really a driver issue at all, but a bus driver one.

Imagine a partition function that is called before device add, and
which distributes the sensors of a usb device onto a set of hid
devices. We already started small in this direction by introducing
device groups, and this particular problem seems to be one of the
issues that would be resolved by such a construct.

Here, we have in the same usb interface 2 different type of reports
coming from different sensors. It's far too different from the usual
configuration we have with legacy devices: when we have several hid
drivers handling the same usb device, it was when hardware makers
split the different sensors in different interfaces. This situation is
correctly handled in the usb subsystem and the hid layer has only to
deal with one driver at a time for a specific interface.

So, in the next series, I propose a new callback ("new_report" -- the
name is awful, but I can not manage to find another one ATM) which
will be called before we call input_mapping for a whole report.
The driver will then have the possibility to:
- continue normally (default behavior)
- ask for a new input device
- skip the entire report

This sounds like a better solution, yes, but the root problem still
remains: do we really want to handle both pen and touch in the same
driver? And do we _have_ to?

Anyway, Henrik , could you also have a look at patches 7 to 11, they

have nothing to do with pen support, and I'm sure that you want to say
something on them too.

Indeed, I will just comment here, saying I do not see why you change
the name of the default. I would prefer it if you resend that set
cleaned up, with the default name unchanged.

Thanks,
Henrik