On Fri, Mar 26, 2010 at 02:15:53PM -0700, Alan Coopersmith wrote:
> Edward Pilatowicz wrote:
> > well presumably select() isn't telling X that there's data to read since
> > theres no underlying device to produce data.
> >
> > so when you tested the fix for 6844148, how did the X server get
> > notified? did select() return and indicate there was data?
>
> As noted in 6914848 (which was closed as dup of 6844148, but is where the
> explanation of my testing was put):
>
> truss & pfiles shows it's in a loop getting signaled by poll
> that there's something to read on the fd that had opened
> /devices/pci at 0,0/pci108e,5354 at 1d,1/hub at 1/mouse at 2:mouse but
> reads
> from that just return ENODEV, which causes it to just go on and
> try again later, infinitely.
>
hm. i wonder why that's not happening in this case?
i just tried to reproduce this problem on my desktop by plugging in a
new mouse, but X is not configuring that mouse... the second mouse is
visible in the device tree and the hal device tree:
---8<---
edp at mcescher$ find /devices -name \*mouse\*
/devices/pci at 0,0/pci108e,5354 at 1d,1/device at 2/mouse at 1
/devices/pci at 0,0/pci108e,5354 at 1d,1/device at 2/mouse at 1:mouse
/devices/pci at 0,0/pci108e,5354 at 1d,2/mouse at 1
/devices/pci at 0,0/pci108e,5354 at 1d,2/mouse at 1:mouse
/devices/pseudo/consms at 0:mouse
edp at mcescher$ lshal | grep ^udi | grep mouse | nawk '{print $3}' | sed
"s:'::g"
/org/freedesktop/Hal/devices/pci_0_0/pci108e_5354_1d_2/mouse_1_10
/org/freedesktop/Hal/devices/pci_0_0/pci108e_5354_1d_2/mouse_1_if0_10
/org/freedesktop/Hal/devices/pci_0_0/pci108e_5354_1d_2/mouse_1_if0_10_logicaldev_input
/org/freedesktop/Hal/devices/pci_0_0/pci108e_5354_1d_1/device_2/mouse_1_if1_9
/org/freedesktop/Hal/devices/pci_0_0/pci108e_5354_1d_1/device_2/mouse_1_if1_9_logicaldev_input
---8<---
although the second mouse doesn't doesn't seem to have as many hal
device nodes as the first mouse. any ideas why this mouse isn't being
picked up?
ed
