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?
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.
Is it possible to fall back to /class/input/inputX/eventY if SYSFS_DEPRECATED is set?