Arch Linux

Somehow the bug report was sent to early during editing the subject.
It should say something like "Device names in /dev/input and /dev/input/by-path are inconsistent (mouse and IR remote control don't work anymore).
Maybe someone can change this.

the text is too long for Summary anyway, it will not be shown in bug list, so I just remove everything between ()

Are there any options of these devices' modules that allow to set their order, similar to http://wiki.archlinux.org/index.php/ALSA#Set_the_default_sound_card ?

The method mentioned in http://wiki.archlinux.org/index.php/ALSA#Set_the_default_sound_card doesn't work. The sound cards are still ordered randomly.

Edited the wiki article, so that a consistent sound card order is possible. See also  FS#15829 .

I'm a little curious as to why the path is changing. That shouldn't happen... I wonder if it's an issue with the driver for that card... what's the card's module?

The card's modules are cx8800 and cx88-dvb. And the module, which is automatically loaded for the IR RC, is ir-common.

The device names in /dev/input/by-path are changing accordingly to the device names in /dev/input.

In the thread http://osdir.com/ml/linux.drivers.wacom/2008-05/msg00057.html there's a udev rule:
KERNEL=="event*", SYSFS{idVendor}=="XXXX", NAME="input/%k",SYMLINK="input/<name of the device>"

I haven't tested it yet, but I think, that this can only be a workaround. At least /dev/input/by-path should be consistent.

I don't think, that this is driver related. I assume, that this is udev related.

Right but considering by-path is generated based on the path of the device, that means your IR device is alternating between pci/0000:03:06.0 and pci/0000:03:06.2, which shouldn't happen. It looks like the module itself might not be too clear on what that number after the decimal should be

I don't agree with this, because this - at least the /dev/input/eventX device - was consistent before the updates of initscripts, filesystem, udev and syslog-ng. Probably an  FS#12706  issue?

This is the lspci output for the DVB-T card, on which the IR device is located:
03:06.0 Multimedia video controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder (rev 05)
03:06.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05)

And this is lspci -v:
03:06.0 Multimedia video controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder (rev 05)
Subsystem: TERRATEC Electronic GmbH Cinergy 1400 DVB-T
Flags: bus master, medium devsel, latency 32, IRQ 20
Memory at fb000000 (32-bit, non-prefetchable) [size=16M]
Capabilities: <access denied>
Kernel driver in use: cx8800
Kernel modules: cx8800

03:06.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05)
Subsystem: TERRATEC Electronic GmbH Device 1166
Flags: bus master, medium devsel, latency 32, IRQ 20
Memory at fa000000 (32-bit, non-prefetchable) [size=16M]
Capabilities: <access denied>
Kernel driver in use: cx88-mpeg driver manager
Kernel modules: cx8802

These pci addresses are absolutely consistent, even if the devices in /dev/input and /dev/input/by-path are alternating.
But these addresses are the addresses, which are alternately shown in /dev/input/by-path.

The module ir-common, which is the actual module for the IR device, depends on cx8800 and on cx8802.

So I guess, that the order, in which cx8800 and cx8802 are loaded at boot time, is randomly. And depending on which of both modules is loaded first, ir-common is assigned to the one or the other pci address, which leads to the inconsistencies at least in /dev/input/by-path.

The inconsistencies in /dev/input/eventX can be caused by a randomly loading order between the modules ir-common (cx8800/cx8802) and evdev, which I think is responsible for the mouse events.

Found out, that there's no index option for the modules cx8800, cx8802 and ir-common.
See the parm lines.

$ modinfo cx8800
filename: /lib/modules/2.6.30-fbcondecor/kernel/drivers/media/video/cx88/cx8800.ko
license: GPL
author: Gerd Knorr <kraxel@bytesex.org> [SuSE Labs]
description: v4l2 driver module for cx2388x based TV cards
alias: pci:v000014F1d00008800sv*sd*bc*sc*i*
depends: videobuf-core,videobuf-dma-sg,cx88xx,v4l2-common,videodev,btcx-risc,i2c-core
vermagic: 2.6.30-fbcondecor SMP preempt mod_unload
parm: vbibufs:number of vbi buffers, range 2-32 (int)
parm: vbi_debug:enable debug messages [vbi] (int)
parm: video_nr:video device numbers (array of int)
parm: vbi_nr:vbi device numbers (array of int)
parm: radio_nr:radio device numbers (array of int)
parm: video_debug:enable debug messages [video] (int)
parm: irq_debug:enable debug messages [IRQ handler] (int)
parm: vid_limit:capture memory limit in megabytes (int)

$ modinfo cx8802
filename: /lib/modules/2.6.30-fbcondecor/kernel/drivers/media/video/cx88/cx8802.ko
license: GPL
author: Gerd Knorr <kraxel@bytesex.org> [SuSE Labs]
author: Chris Pascoe <c.pascoe@itee.uq.edu.au>
author: Jelle Foks <jelle@foks.us>
description: mpeg driver for cx2388x based TV cards
alias: pci:v000014F1d00008802sv*sd*bc*sc*i*
depends: videobuf-dma-sg,cx88xx,videobuf-core,btcx-risc
vermagic: 2.6.30-fbcondecor SMP preempt mod_unload
parm: debug:enable debug messages [mpeg] (int)

$ modinfo ir-common
filename: /lib/modules/2.6.30-fbcondecor/kernel/drivers/media/common/ir-common.ko
license: GPL
author: Gerd Knorr <kraxel@bytesex.org> [SuSE Labs]
depends:
vermagic: 2.6.30-fbcondecor SMP preempt mod_unload
parm: repeat:auto-repeat for IR keys (default: on) (int)
parm: debug:int

I'm using kernel26-fbcondecor, but it's the same as kernel26 only with the additional fbcondecor patch, which doesn't influence this issue.

If the devices are completely 100% consistent and the by-path alternates (and is therefore wrong), then we have an issue with the by-path udev rule.

Yes this is related to  FS#12706 , but these things were expected and SHOULD be fixable. It is a shame, though, that it illustrates bugs like this (the bug here is with the by-path udev rule, or whatever generates the by-path links that are wrong)

Is this still an issue with udev-145?

"A shame" is too much. ;-)

With udev-145 the devices in /dev/input and /dev/input/by-path seem to be consistent again. But there are no device files for PCI devices like the IR device in /dev/input/by-path anymore. But these devices are consistently accessible by their /dev/input devices again.

My mouse has consistently the device /dev/input/event5 and my IR device has consistently the device /dev/input/event4.

So for me it works again with udev-145.

Weird. tpowa, do you know how and why that happened with udev 145?

Hrm many things changed between 141 and 145 lot's of rule cleanup and movement, guess something in there fixed it.

All is well? Close the report?

It seems to be fixed now. For me it seems to be consistent now.
So I guess this bug can be closed.