Hi Benjamin,
> > 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
--
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
