On Thu, Nov 27, 2014 at 12:39:08PM +0100, David Herrmann wrote:
> Hi
>
> On Thu, Nov 27, 2014 at 7:06 AM, Peter Hutterer
> <peter.hutte...@who-t.net> wrote:
> > On Wed, Nov 26, 2014 at 01:10:10AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> >> On Wed, Nov 26, 2014 at 01:01:30AM +0100, Zbigniew Jędrzejewski-Szmek
> >> wrote:
> >> > On Wed, Nov 26, 2014 at 07:30:51AM +1000, Peter Hutterer wrote:
> [snip]
> >> > > I had that at first but 60-mouse sorts before
> >> > > 60-persistent-input.rules and
> >> > > we partially rely on that, specifically the line
> >> > > SUBSYSTEMS=="usb", ENV{ID_BUS}=="", IMPORT{builtin}="usb_id"
> >> > >
> >> > > Want me to add that line to this ruleset here, or should we leave the
> >> > > sorting as-is?
> >> > I think you should *move* it to 60-mouse.rules.
> >> > It seems better for something specific like persistent-input to depend
> >> > on something generic like mouse.
> >> >
> >> > 60-persistent-input.rules has SUBSYSTEMS=="bluetooth",
> >> > GOTO="persistent_input_end".
> >> > That'd skip bluetooth which you need.
> >> Scratch that. I don't think you need to move anything, because you
> >> don't rely on anything from 60-persistent-input.rules. ID_INPUT_MOUSE
> >> is provided by IMPORT{builtin}="input_id" which is run in
> >> 50-udev-default.rules.
> >
> > yeah, what we need is the usb_id builtin though. That is run by the defaults
> > but only for devtype usb_device. The event nodes don't have that devtype
> > set. And moving the above line from 60-persistent-input would break things
> > since over there they get run for SUBSYSTEM=input, not the event nodes.
>
> I went ahead and applied the original patch. I amended few fixes:
thanks, much appreciated.
> 1) move rules/70-mouse.hwdb into hwdb/ (no idea why you placed it in
> rules/, I guess a typo?)
yeah, a last minute fix after testing. mea culpa.
> 2) fix "60-mouse.hwdb/rule" to "70-mouse.hwdb/rule" in your comments
>
> 3) fix "/etc/udev/hwdb.d/60-mouse.hwdb" to
> "/etc/udev/hwdb.d/71-mouse-local.hwdb"
>
> 4) dropped that extra whitespace in hwdb
>
> I hope no-one minds that I applied it. We can easily move things
> around afterwards. It's much easier for someone with -git access to
> rename files than for Peter to send patches to fix trivial renames.
> And the externally visible stuff is all fine, it's just internal
> ordering we don't agree on.
>
> Now, to address the remaining issues: I dislike depending on previous
> rule-files to run built-ins, however, we also want to avoid running
> built-ins multiple times. We could make builtins no-ops if they're run
> more than once, but that will break if they are explicitly run
> multiple times. And it adds state that we want to avoid..
> So my idea is to add 10-input.rule which runs common builtins for
> input devices, which later rules can rely on. persistent-input.rule,
> keyboard.rule and mouse.rule can then safely rely on 10-input.rule. Or
> we just accept the fact that 70-mouse.rule depends on
> 60-persistent-input.rule.
fwiw, I think the 10-input rule would be a good idea.
as for running builtins multiple times: that depends on the condition. in
this particular case the builtin would've run only once per device,
since ID_BUS is set once the builtin finished and thus the condition for the
second run won't trigger*. I think that's generally how you should get around
running builtins multiple times: if you expect them to set something, so you
only run them if the stuff isn't set already.
Cheers,
Peter
* well, unless ID_BUS isn't set by the builtin, which is a separate problem.
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
