Ben Gamari wrote:
On Thu, 2007-10-04 at 22:40 -0400, Dmitry Torokhov wrote:
4f01a757e75f2a3cab2bab89c4176498963946b9.
The change that Dmitry proposed would still require
CONFIG_SYSFS_DEPRECATED, right?
What proposed change?
The changeset you quote is already applied.
Andrey Borzenkov wrote:
Actually this specific problem was introduced by
4f01a757e75f2a3cab2bab89c4176498963946b9. This commit seems to have
completely disassociated eventX from corresponding inputY
To summarize.
1. Any kernel with SYSFS_DEPRECATED unset
events are sent for /devices/...
/devices/.../eventX is direct child of /devices/.../inputY
HAL checks for parent of eventX, finds inputY and is happy
2. SYSFS_DEPRECATED=y, pre-2.6.23 kernel
events are sent for /class/...
/class/.../eventX is direct child of /class/.../inputY
HAL checks for parent of eventX, finds inputY and works
3. SYSFS_DEPRECATED=y, 2.6.23 before commit
4f01a757e75f2a3cab2bab89c4176498963946b9.
events are sent for /class/...
/class/.../eventX is *not* child of /class/.../inputY
/class/.../eventX/device points to .../inputY
HAL checks for .../device link, finds inputY and works
4. SYSFS_DEPRECATED=y, 2.6.23 after commit
4f01a757e75f2a3cab2bab89c4176498963946b9.
/class/.../eventX is *not* child of /class/.../inputY
/class/.../eventX/device points to some physical device
HAL finds inputY neither as ../inputY nor as device link and breaks
But what is worse, now the only way to find which inputY corresponds to which
eventX is to scan the whole /class/input, check for device link and compare.
I am afraid that we have to bite the bullet and just accept that 2.6.23 breaks
user space this way or that. Frankly fixing path_id seems to be the least
evil.
I'd hate to see such breakage. IMO the sysfs structure of input devices
should be made compatible with both HAL and udev, with both
CONFIG_SYSFS_DEPRECATED and without it, as in 2.6.22 and before.
Is it possible to fall back to /class/input/inputX/eventY if SYSFS_DEPRECATED
is set?
Hopefully.
--
Anssi Hannula
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
