[lkml]   [2012]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 4/5] HID: autoload hid-multitouch as needed

    Le 8 mars 2012 à 13:23, Henrik Rydberg a écrit :

    > On Thu, Mar 08, 2012 at 12:48:24PM +0100, Stéphane Chatty wrote:
    >> Le 8 mars 2012 à 12:30, Henrik Rydberg a écrit :
    >>> The device-driver matching is done in the kernel, but driver (aka
    >>> module) loading is done from userland. The crux is to be able to tell
    >>> userland what driver to load for a certain device. In this case, it
    >>> means giving more information to userland via the device/modalias
    >>> construct. Or at least, that is the question. :-)
    >> Oook, I understand. The current solution used by distros is to load
    >> the hid module statically, but then we don't want to do it for every
    >> new kind of device-specific module, right? Is this your point?
    > Yes, half of it. The other half is the observation that the problem of
    > device-driver assignment we face for hid devices seems to originate in
    > the definition of what a hid device is, i.e., the hid device
    > identifier. If the identifier was more detailed and one could
    > construct a new hid device dynamically from the reports, the problem
    > would go away. Consequentually, a more detailed identifier would solve
    > the module-loading problem as well. The major concern I have is if
    > this is feasible from a compatibility point of view.

    Understood. This converges with my concerns about how device classes are handled in the hid core: there is no explicit device class or description of features, and with the new kinds of devices this leads to more and more complex tests in hid-input and in X drivers to reconstruct that information from the evdev axes so as to decide what to do with each device.

    A few people in my group, including Benjamin, are developing an experimental event routing server in user space, to support new patterns of input processing. Given that plugging a device is just a particular kind of input, I'd be interested to see what it could do with hotplug events that contain more details about device types :-) BTW, HID reports constitute a richer language than evdev axes, and MacOS and Windows give a growing role to HID. It would be good if at some point we could define device types based on something with the same kind of expressive power.

    >> I had the feeling that the current hid code was somehow trying to be
    >> universal, thus making the point moot, and figured that we would
    >> need to reintegrate hid-multitouch into hid-core at some
    >> point. You're suggesting another, more distributed option, in which
    >> new categories of HID devices appear from time to time and are
    >> handled in new modules, right? Sounds interesting to me, I'd like to
    >> hear what the original designers of the hid module think of it.
    > Me too. Reading through the module code, it really seems to put
    > userland in charge, only providing sufficient information to be able
    > to load the right modules. If this was fully possible in hid, at least
    > one of the special blacklists would disappear. One would also be able
    > to split the current hid-input into several different drivers, for
    > instance, gaining some clarity in addition to memory savings.

    This would be a radical change from the current hid code that tends to restrict "true hid" to a limited range of HID usages and to reject the rest (cf the IS_INPUT_APPLICATION that caused us some difficulties three years ago). But this definitely would make sense to me. Jiri, Dmitry, what do you think?


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2012-03-08 23:51    [W:0.034 / U:4.564 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site