[lkml]   [2008]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: patch driver-core-warn-about-duplicate-driver-names-on-the-same-bus.patch added to gregkh-2.6 tree

    Takashi Iwai wrote:
    >> I was trying this in the past.
    >> This never worked out very well.
    > Why?
    Mainly because I was not able to
    come up with the good hooks for the
    pcspkr driver, and those I tried,
    were not applied.
    There was a lengthy thread about that.
    Now I can't find its beginning and its
    end, but some is here:
    I also think you were CCed, but maybe

    >> I disliked the dependancies.
    >> Either snd-pcsp was loading pcspkr,
    >> or there had to be the global variable
    >> to prevent the concurrent access, and
    >> that hurts modularity.
    > But you anyway enable the input pcspkr feature in your snd-pcsp code.
    > So, basically you depend on (or build on) it.
    If they are separate, then "rmmod pcspkr"
    should disable the beeps. I don't want
    to fuzzy that logic up to something like
    - Check if snd-pcsp is loaded
    - Use alsamixer to disable beeps, if
    it is.
    - Use rmmod pcspkr if it is not.
    I think there should be always a single
    way for the user to disable the beeps.
    Now he can choose it by chosing the driver.

    >>> What we'd need is a hook on
    >>> pcspkr.c that adds a dynamic check whether snd-pcsp (or any ohter)
    >>> is running.
    >> How?
    > What you need is a way to check whether input pcspkr can be usable or
    > not. You can add a function pointer, for example.
    Could you please clarify?
    - Should snd-pcsp then forcibly select
    pcspkr.c to compile?
    - What exactly function pointer, and
    where to add?

    >> And also, with snd-pcsp you have a
    >> mixer control to disable the beeps,
    >> which I find sometimes even more
    >> usefull than the pcm sound itself. :)
    > Yes, that seems useful.
    Yes, but problematic when they are separate.
    I was trying to add an input event to shut
    up pcspkr.c, but that was rejected. Everything
    else will introduce the dependancy. The
    dependancy will block rmmod, obfuscating the
    logic of disabling the beeps.
    Just for the record, what problems do you
    see with the current solution, where only
    one driver drives the device? That looks
    rather logical to me. And I also can remember
    the complains about pcspkr driver being in
    an input drivers section. Some people had
    problems finding it there and were asking
    to move it to sound menu.

     \ /
      Last update: 2008-04-30 19:49    [W:0.024 / U:1.488 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site